Remotely Hijacking an Aircraft

There is a lot of buzz on the Internet about a talk at the Hack-in-the Box conference by Hugo Teso, who claims he can hack in to remotely control an airplane’s avionics. He even wrote an Android app to do it.

I honestly can’t tell how real this is, and how much of it is the unique configuration of simulators he tested this on. On the one hand, it can’t possibly be true that an aircraft avionics computer accepts outside commands. On the other hand, we’ve seen lots of security vulnerabilities that seem impossible to be true. Right now, I’m skeptical.

EDITED TO ADD (4/12): Three good refutations.

Tags: , , , , ,

Posted on April 12, 2013 at 10:50 AM • 40 Comments

Comments

guillem • April 12, 2013 11:08 AM

Maybe it’s just a case of implicit security by obscurity. You know… “oh, come on, who’s going to mess with this?” 🙂

Dilbert • April 12, 2013 11:14 AM

I read one review that said he’d built some custom equipment to interface with the aircraft systems and was controlling it with his phone. He didn’t have this from an android phone.

He’s also, obviously, not controlling any actual aircraft systems. He’s controlling a simulation.

Basically it doesn’t look like a feasible real-world exploit.

Chris W • April 12, 2013 11:23 AM

From what I understand, the system that processes received flight information, for example weather reports, has security bugs that allow an outsider to inject malicious code into that system.
After that it is rather easy to get to the autopilot.
The display panel that displays weather information is also used for control over the auto pilot (on certain planes). So those two have to come together somewhere.

Christopher • April 12, 2013 11:30 AM

You missed what I thought was the most obvious question: How long until the TSA bans Android phones from being carried on?

Nick Foster • April 12, 2013 11:37 AM

There’s not enough information in his presentation to tell one way or the other. I said the same thing — if he is able to inject arbitrary data into an FMC via CPDLC, that’s a huge break. I strongly suspect this isn’t the case. It’s hard to do buffer overflow attacks (for instance) on a system whose buffers aren’t actually exposed to the bus you’re attacking. In this case, the receiver and the FMC are separated by an ARINC bus, to which an attacker presumably doesn’t have direct access.

That said, it’s been possible for a long time to craft spurious flight plans and uplink them to the FMC interface — they require acceptance by the pilot, which likely limits the utility of the attack to subtly altering an approach, but the increasing use of controller-customized approaches such as Oceanic Tailored Arrival necessarily means more opportunities for such attacks.

His paper also mentioned the use of a USRP and Gnuradio, but the lack of specifics makes me think that he hasn’t yet negotiated the intricacies of hijacking an active CPDLC connection. Not that it’s in any way impossible, but it’s going to be a PITA to develop.

The use of unencrypted, unauthenticated datalinks for aircraft communication has long been defended as “safe” due to pilots being in the loop. As air traffic density increases, though, there must be more reliance on automation. Without at least some thought to system security these trends are bound to collide. Given the 30-year timeline of new technology introduction into ATC systems, vulnerabilities like this are all but inevitable.

Scott • April 12, 2013 11:55 AM

If they can “hijack” military drones, I don’t see why they can’t use the same techniques against commercial aircraft, theoretically.

Tim • April 12, 2013 11:57 AM

Hacking ADS-B has become a regular feature of Defcon and Blackhat, but this is something new. The person who made the app claims he is exploiting the Flight Managment System directly, which is tied in to the autopilot. Luckily, pilots don’t generally trust the autopilots because they don’t work all that well, and any manual input from the pilot will disengage the autopilot. Still, though, if someone were to find a way to rewrite these safeguards while it was running, this could potentially allow someone to hijack the aircraft. He wrote this app specifically so it could not directly be used on real aircraft, but the fact that someone can arbitrarily upload false data to the FMS is in itself extremely severe.

Keith • April 12, 2013 11:59 AM

I’m not so sure about really issuing commands to the onboard systems (I haven’t found / read a great write up yet, hoping some of your links are better than what I’ve found)

However it would seem that some of the parameters transmitted do have safety implications even if they aren’t commands directly executed.

Some of the data transmitted seems to be things like cargo load and balance which one could imagine just spoofing enough to cause an accident.

AlanS • April 12, 2013 12:04 PM

@Deeter

The Ask the Pilot ‘refutation’ is only a refutation of the impact of inputting commands, not the ability to input commands into the flight management system. His conclusion:

“None of this is to suggest that beaming uninvited data into the electronic architecture of the cockpit is a good or safe idea. Of course it is not. That it might be possible is, to be sure, a cause for alarm, and I’m more than a little dismayed that Mr. Teso is cavalier enough to openly share how such a thing might be done. But, even so, this is not by any stretch the sort of imminent threat people are being led to think it is. Scary words like “hijack” and “takeover” have no place in this conversation.”

Shawn Baker • April 12, 2013 12:12 PM

From the linked article and the slide deck, I’ve determined that the only thing exploited was the simulator software, which was running on a machine that the group already had full access on. There’s no avionics being used in this. They’re ‘simulating’ a set up with commercial PCs and training software. They’re using the two communications standards, ADS-B and ACARS to communicate to a ‘box’ that they already had control over and already hooked into.

There is no exploit here.

If you want more detail about why this would never land, I’ve wrote about it here: http://zapistan.net/blog/2013/4/11/fear-mongering-the-friend…

Nick P • April 12, 2013 12:31 PM

I’d be suspicious too. The safety-critical RTOSs I often post about are mainly targeted for this space. Their aerospace versions usually include support for the ARINC standard Nick Foster mentioned and others. The thing about them is that the highest criticality tasks run on very deterministic, heavily analysed software. Input to processes on those kinds of kernels results in more a “please do this” than “im forcing this” situation. The time and space partitioning alone can limit many traditional types of attack.

Of course, older airliners might not have great certified products. I also knew a guy a few years ago who worked for Boeing and said one of their “resilience” strategies was running the same software on a Windows PC and Linux PC. Unfortunatly, he wouldn’t name the airliners involved so that I could avoid flying in them.

The next layer of defense is much like what Deeter posted. One of the main reasons we keep pilots in the loop is b/c we dont totally trust electronics. At some point, however fault tolerant, the systems might start screwing up. The systems themselves have some resistance to deadly commands and then the pilots will ignore crazy stuff. The pilots can also radio ATC to ask “you really want us to land on that swamp? No? We didn’t think so…”

All of this seems to be FUD for practical purposes. Regardless, we have the technology to implement safe electronic controls and comms links on airliners. If FAA and manufacturers so choose to use it and use it right…

Brian W • April 12, 2013 12:47 PM

The core vulnerability here seems to be the lack of authentication in the ADS-B and ACARS protocols. If that’s true, then it’s only a matter of time before a real exploit is developed.

stuke • April 12, 2013 12:50 PM

It scares me to think that someone even MIGHT be stupid enough to make an aircraft’s controls available to the outside world.

Frisbee • April 12, 2013 12:52 PM

The question for me is how hard would it be for someone with physical access to install a small wireless network device that would allow remote access to critical systems? Could a maintenance tech add a $50 raspberry pi deep in the plumbing that with the right code could make the plane a drone? I see a plot for Bruce’s Movie challenge:

Hacker compromises 100 planes and uses them to play space invaders over NYC.

NobodySpecial • April 12, 2013 12:52 PM

Scary words like “hijack” and “takeover” have no place in this conversation.”

You can already take over the normal VHF comms to from the tower – it’s just a primitive un-encrypted radio transmission, if you know the aircraft’s call sign, speak English and a have a knowledge of aviation language. There have even been some accidents when the tower and the aircraft transmit at the same time and a message was lost.

The high tech backup to this victorian technology is a data link to send text messages to the aircraft. This is also un-encrypted and un-authenticated.

Yes both the radio and message data go to human pilots not the avionics. But it’s not hard to see how, if you have a crew with a legal and moral duty to obey ATC, and you have control over the data from ATC – you can effectively hijack an aircraft.
You can’t order them to fly into the pentagon but you can certainly cause an accident in the crowded skies above most international airports.

name.withheld.for.obvious.reasons • April 12, 2013 12:53 PM

For the most part the robust component of the aircraft avionics and control systems are managed underneath a DO-178B RTOS layer. Much like virtualizaion in user applicaqtion land, this layer provides system call and services to I/O without allowing the application to wreak havoc on the primary operating layer.
Since we all know application programmers are crap, the need to isolate the upper layer abstraction code (some of this thing have JVM’s running on top of them) that this makes a lot of sense. What is obvious though in most implemnetations is that the parallel plane (abstract geometric analogy) of redundancy is invariant. This means that if the DO-178B layer did have a bug in it, the other parallel nodes could possible suffer the same fate. So, in conclusion it is quite possible to attach to the JVM layer for example and have your way with the user space components but the lower layer components are a little more out of reach.
That reminds me, has anyone seen an APT that uses UEFI to manage its persistence. I may have run into such a bug…

Shawn Baker • April 12, 2013 12:59 PM

ACARS does authentication based on ARINC 823 standard.

ADS-B is basically an adhoc network to communicate your location as a threat to everyone else. Everyone else is listening to your location. If anyone else is transmitting their location, it appears as a threat to them. If someone was to be malicious and transmit ADS-B squitters, every aircraft and ground station in the area will know of this new target. That’s it.

Brian Weeden • April 12, 2013 1:23 PM

I think what’s fueling this fire is the lack of open security research on flight safety protocols. There may be a whole lot of work going on to secure them, but it’s outside the public eye from what I can tell. So the broader hacker community is taking an interest and publishing their work publicly. It’s hard to tell if they are right or wrong because it’s just a one-sided conversation.

I’ve seen the same thing happen with GPS. I forwarded some open research on vulnerabilities in GPS software to some govt types I know and they said “this isn’t a big deal, we’ve known about this for years in the classified world”. Well maybe, but the vuln still exits.

Ultimately I think what’s behind this is the culture of these various communities and their article towards security research (open vs closed).

ns • April 12, 2013 4:32 PM

It scares me to think that someone even MIGHT be stupid enough to make an aircraft’s controls available to the outside world.

The guy who did it was US crypto export policy a couple of decades ago.

Jan Schejbal • April 12, 2013 4:47 PM

If you have an idea where a security issue could lurk, and you think “no way, noone can be that stupid”: check.

I have seen cryptographic keys generated from the default rand() PRNG seeded with the current time. I have seen the online update function for a nationwide security system (German electronic ID card) ignore the host name in SSL certificates (totally breaking security), then allow directory traversal when unpacking the update (making the additional signature check they put in there worthless).

Since then, I only use “noone can be that stupid” to mean “let’s check”.

Jason • April 12, 2013 5:04 PM

Frisbee: It is possible that a mechanic or flight deck employee could install foreign hardware into the plane, but this is a movie plot threat.

A mechanic would know a hundred less sophisticated ways to cripple an aircraft. All you’d have to do is use the wrong torque on the wrong bolts and it would vibrate loose at 30k feet. So while I think the airplane manufacturers acknowledge this scenario, I doubt any of them care about it.

Carpe_Noctem • April 12, 2013 5:04 PM

While I’m not sure what exactly he is targeting (didn’t rtfa), I can tell you I remember there being some fairly lengthy debate in conspiracy circles about the ability to do just this. If I recall correctly, the postulation was that there had been some sort of military/DoD/NSA involvement in the design of some parts which are required by the FAA in all aircraft (?of a certain type?) for “emergency purposes” of an undisclosed nature. Some said the entire design was to be able to control a plane from the ground (there is some evidence for tests of this from places like NORAD I believe).

Basically it boils down to the chinese hardware trust issue. (except the claim is that it’s us doing the hardware backdoors when it comes to planes) I’ll try to avoid where the conspiracies go from there, but you can imagine the potential incidents suddenly explained by such a thing. After all, every enemy of the state should know to avoid aircraft (especially small ones…though generally physical security pre-flight is the issue with those “incidents”)

a • April 12, 2013 5:40 PM

@Brian The regulations which mandate practically physical separation of the systems targeted here are available to the public.

Thinking terrorism I suppose the worst case scenario here is that you trick the pilot into approving a flight plan that gradually descends to whatever is the altitude autopilot refuses to go below, and then radio in shouts about lowering the altitude. Or having the flight plan guide the plane into hostile territory could get it shot down without warning.

There’s not necessarily a “hard” exploit needed to trick a pilot, the uploading is unecrypted and you might well be able to craft a flight plan that renders in a way that obscures some parts of it, though you can’t put in rash maneuvers and what about text so I dunno.

But poor visibility and complacent pilots are required. If in range the ATC would try to alert the plane early on so you’d have to block/MITM communications and not raise suspicion. Maybe if you create some distraction on the plane that could help, but it could easily have the opposite effect.

Clive Robinson • April 13, 2013 6:55 AM

Hmm, am I the only one who remembers the outcry after 9/11 and the calls by some for the authorities to have the ability to remotely take over aircraft?

There are a number of other issues that people need to think about.

Firstly for the sake of argument let us assume that there are one or more plaintext unauthenticated routes into an aircrafts control systems what would it take to crash an aircraft, or more importantly cause the pilots to crash the aircraft. The latter of which has happened frequently enough in the past and appears to have happened again in the past few hours. That is misleading information on displays cause pilots to come to wrong conclusions and then take inappropriate action with results that can or do have significant impact on airworthness of the aircraft.

However in the past pilots have also put to much reliance on what they are being told from the ground and have as a result endangerd or actualy crashed their aircraft (flying into mountains etc).

So it can be seen that having a human in charge of the aircraft can be as much if not more than automatic systems.

Thus simply tampering with a system that gives overly reliant pilots information can cause the pilots to endanger or crassh an aircraft even if the system it’s self has no control directly or indirectly (through other automatic systems) on the aircraft.

So how do you stop incorect information reaching a pilots eyes and ears?

The simple answer is you cannot currently because it’s fallible humans that put the information in at the other end of the communications channel…

So is it possible to automate the input and secure it? simple answer is no for both technical and practical reasons. That is from the technical viewpoint if components start to produce erroneous input to the system you need to remove them from the system and add in other supposadly more reliable components and this obviously opens a security hole. Likewise from the practical point there are a whole multitude of “end run attacks” that can be performed, for instance the actuall sensor measuring heads of the instruments can be enveloped in some way and have a false environment presented to them (this has happened for real accidently after a cleaner blocked a sensor hole on the aircraft surface and the result was the aircraft crashed after the pilots became confused).

Even if you could up the real security of the sensors and head end equipment how are you going to authenticate the readings to the pilot so they know it’s reliable?

Simple answer you can not. This is due in part to the number of units involved you are going to have at best a system (Public Key) that we know to be insecure to a number of types of attack…

So currently there are not any reliable (or sufficiently reliable) systems out there to achive any real level of trust that I would be prepared to put my life on, and nor should you… Even though we do currently have the technology to compleatly replace the pilot (yes we’ve had this conversation before and views are wide spread and very conservative in some cases and now is not the time to re-boil the mess because. it’s actually not relevant).

So how to solve the problem?

Well the solution has to be done in the aircraft obviously, and without going into the details it means making the pilots more reliable, and this means two things,

1, Firstly teaching them to in effect distrust the systems they use, because they are fallible and can give false readings or readings that are not valid for various reasons.
2, Secondly providing the pilots with better failure mode training, which involves complex problems where instruments do present false or subtally incorrect readings.

Neither of these are going to popular to those who watch the bottom line of the airline or who open their purses to pay to get from A to B due to the significant increase in cost involved.

As security practitioners we have to accept we cannot make the world safe against random acts of nature let alone the calculated acts of mankind. All we can do is find ways to mitigate without steping into the very dangerous area of dependancy.

Alex • April 13, 2013 11:39 AM

I can’t give great detail on this, but here’s a fun one:

So a friend of mine was doing R&D for an aircraft manufacturer for a future aircraft. On a modern plane, there are miles of copper wire. In the desire to reduce weight and improve reliability, they chose to run fiber optics & small RF transceivers. Seemed like a good idea on paper. I remember him showing it off a workbench version of the system and how proud he was. I noticed the antennas and had a hunch. I set my mobile phone down on the table and tried to use the system. Nothing wireless worked. They were stumped. I was laughing. They were trying to use the 2.4GHz ISM band for in-plane signalling. Sadly, they had never considered that there might be other 2.4Ghz devices on the plane….like passengers’ phones. True story.

Wesley Parish • April 14, 2013 4:50 AM

Firstly, a comment on ADS-B – it’s been developed with the previous system in mind, a radar subsystem that interrogated the local airspace to find out if there was anyone in the vicinity, which in turn was a development of the WWII IFF transceivers they fitted military aircraft with.

I once considered developing a TCAS after reading about the havoc that was happening in the real world with aircraft that didn’t have even the rudimentary radar collision avoidance subsystem – a problem primarily with Russian aircraft, I believe.

My network-based TCAS would have been based on several well-known TCP/IP protocols, including the fping variant of ping, to establish who else was on the network, and a variant of finger for transferring data on location, direction, speed, callsign, etc. It was call-and-response, of course – you only replied if you got a request for location and heading, and the request came from another aircraft or airport on the network. (In case of uncertainty, I think I would’ve had the TCAS send an identity query to the nearest airport.)

I gave it up once I realized it was not something that I could develop on my own, and at the time I could not call on the expertise of likeminded people around the world as then I had no access to the Internet. But it gave me a fair idea of the problems.

Frankly, ADS-B worries me. It’s based on the plaintext promiscuous transmission of such-and-such an aircraft’s location en route. What I worry about is that it provides targetting information free to anyone malicious with a Stinger retrofitted with ADS-B.

Finally, it’s not impossible for a plane to get the wrong location data and fly straight into the side of a mountain. Air New Zealand managed that without the help of anyone else on the 28th November 1979, slap bang into the side of Erebus.

And if it’s possible to spoof GPS, then by all means it’s possible to mislead an FMS reliant on said GPS. The question is, are there reliable backup location systems being used?

nobodyspecial • April 14, 2013 5:22 PM

@wesley Parish – in theory WAAS prevents, or at least alerts you to the presence of, GPS spoofing.

That’s the main reason the FAA introduced it – the enhanced accuracy is just a by-product

Northern Realist • April 15, 2013 11:03 AM

I’m guessing he would have to be ON the plane to do the hacking – given that cell signals are by nature line-of-sight and the power levels are so low…

Coyne Tibbets • April 15, 2013 4:25 PM

If there is any common thread of the security weaknesses seen on this site (and on others; TheDailyWTF comes to mind) it is that of, “Blissful disregard.”

When building products, security is usually the last thing considered, regardless of how important security is. Why would we expect any different in the design of airplane avionics?

And then there is a second common thread: “Defensive denial.” When an accusation of weak security is made, empty refutations are offered. (“We’re secure, you idiot! Go away, so we can get back to blissful disregard.”) The denial stage is often combined with SLAPP-type attacks, designed to silence detractors.

The so-called refutations look to me to meet this stage just fine (paraphrasing broadly). The FAA says, “It’s simulation. The real plane would never have exposures like this. Go away.” EASA: “We do things right. Go away.” Rockwell Collins: “Our real airplanes are secure; he’s working on virtual ones. Go away.” Honeywell is talking to Teso’s employer (mostly about terminating him for making a ruckus, I bet) and says, “Teso’s work doesn’t prove anything. Go away.” Fizz57: “ACARS/ADSB normally have no connection with the flight controls. Go away.” PJ2, in item #1, says there’s no connection between ACARS/ADS and the FMS; then in #3 tacitly admits there is a connection: “But it can’t be used that way. Go away.” The last link seems to focus on the idea that planes today can be hand-flown; which is maybe right, though I’ve heard most plane functions these days are via computer. Mostly, again, it sounds like, “Go away.”

Then we get to stage 3, which is, “Someone hacked it. We never could have expected such a thing…”

paul • April 15, 2013 8:25 PM

The “ask a pilot” refutation troubles me, because it’s essentially “We’re all highly competent and very careful, and would never click OK on any change without having thoroughly considered every possible ramification of doing so.”

The NTSB’s files are littered with stories of pilots who didn’t check things when they should have, who used outdated navigational or approach data, who didn’t notice that flight paths that were just fine at way and endpoints intersected terrain at various spots in between…

If an attacker were going to use something like this, they would either take a spearphishing approach to find which flight crews tended to accept deviations most readily, and then attack at a few points. Or else a spamming approach, with resultant chaos.

Add the possibility of hiding your Android hacking in a malicious app that might become wildly popular before it’s thoroughly analyzed, and you have a great movie plot.

h • April 16, 2013 3:04 AM

@Coyne That could just as well be turned against computer security sensationalism. They are happy to tout hot air, and then proceed to whistle innocently. “News” are picked up solely by keywords.

Wesley Parish • April 17, 2013 4:36 AM

@paul I invite you to read the Mahon Report, internationally famed for Justice Mahon’s sentence:
“I am forced reluctantly to say that I had to listen to an orchestrated litany of lies.”
http://www.erebus.co.nz/Investigation/MahonReport.aspx

As avionics becomes more connected, and more open to external connections, it becomes a more intriguing target. Only someone with a radar transponder could spoof a TCAS call in the 90s. When ATN gets up and running, and if they don’t build it properly, it’s going to look like the Internet c. 1990s, with Win95 being the majority platform.

Peter A. • April 17, 2013 6:37 AM

@Nick P.: I strongly hope the various airborne software is hardened enough that “rooting” it is very, very hard, and therefore hopping from one microcontroller to another, to another, … to the fly-by-wire one finally, end executing your code there, is extremely difficult.

Other than that, unauthenticated messages mean that providing false information may mislead the pilots, or some social engineering may be possible, or spamming the system may create some nuisance or even chaos. But it’s no news. Pilots are trained not to accept blindly whatever instructions they receive. On the other hand I have seen so many cases of “computer said so, so it must be true” attitude in other areas, to doubt that even the best training would be 100% effective.

Nick P • April 17, 2013 3:19 PM

@ Peter A

“@Nick P.: I strongly hope the various airborne software is hardened enough that “rooting” it is very, very hard, and therefore hopping from one microcontroller to another, to another, … to the fly-by-wire one finally, end executing your code there, is extremely difficult.”

I would hope so too. I can’t speak to the older trends. The newer one over the past decade is the MILS architecture as a compromise between totally separate computers and totally shared computers. It’s basically a safer virtualization scheme that uses tight control of CPU and memory resources to reduce chance of one process from affecting another. They also use filesystems and networking stacks designed for partitioned operation. Examples include INTEGRITY-178B, LynxOS-178B, PikeOS, and VXworks MILS and airline products.

My concern remains that SOC’s are architecturally designed for sharing, not separation. I’d also prefer that the difference between code and data, along with privileges to modify execution control, be more tightly enforced at hardware level. Then, building secure software would be much easier. Closest thing to that in past were tagged, capability and managed (eg. Ada) machines. There’s current products and projects underway for this kind of thing. Not to the degree I’d prefer…

Dimitri • April 21, 2013 6:55 PM

There are generic frameworks for these, mostly running on ARM SoC platforms. Some do accept commands and meta data through asymmetric signed protocols that are outsourced and shared..

Source: Former government aerospace engineer.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.