FAA: 'No, you can't hijack a plane with an Android app'
theregister.co.uk
theregister.co.uk
Based on their responses it sounds like "Yes, these systems are vulnerable but a good pilot will ignore the bad data so the plane is not vulnerable." which does not exactly give me the warm fuzzies.
(Good point here at the bottom: http://arstechnica.com/security/2013/04/hacking-commercial-a... )
All his hack needs to be able to do is cause problems for the pilot (bad information etc.) for this to be a problem.
I mean, if there is no issue then surely he is now justified in publishing his work and them publishing in detail why it is not a risk.
Right, like on Air France Flight 447.
Obligatory Dilbert: http://search.dilbert.com/search?w=Flight++laptop&view=l...
Any pilot will tell you the very last thing you want is to be at war with your own aircraft (or its instruments), but incorrect readings should not solely cause an incident. This is also the case with AF447. I'm more likely after reading the CVR to put the incident down to poor communication between the crew (in the industry known as CRM or Crew / Cockpit Resource Management) [1].
The crew failed to effectively communicate what each other were doing, to the extent where they were inputting opposite commands to the flight controls and had a misunderstanding of what conditions triggered certain flight control modes [2] of the Airbus' autopilot.
Coming back to the original point around culture and training, it was evident that the more junior pilots were relying on certain "protections" the autopilot has against conditions like a stall. It's this reliance upon a computer (commanding a full nose-up during a stall) and lack of understanding of how the aircraft's flight computer acts under certain conditions that ultimately ended 228 people's lives. The French investigation concluded that the inconsistency of speed measurements was only one of seven factors that caused the accident.
[1] http://en.wikipedia.org/wiki/Crew_Resource_Management [2] http://en.wikipedia.org/wiki/Flight_control_modes_%28electro...
EDIT: Having said that, I would not want to be the pilot flying an aircraft where I can't trust my own instruments, however there are numerous cases (QF72 [3] comes to mind) where pilots have had to disregard most if not all digital instrument readings and stick to the bare minimum to safely land.
The "attack" consists of the following steps:
1) Modify the desktop simulator FMS code to support commands in the data protocols (e.g. ADS-B). 2) Send commands through data link to utilize the newly created control channel.
What FAA is saying that
1) It is hard if not impossible to actually inject un-authorized code into an embedded airplane system (FMS, GPS, ...) due to strict quality controls in place. 2) Even if one succeeds with 1) then you still have limits of what FMS can actually do with the plane because it is a separate unit from other systems with well defined protocols (e.g. FMS doesn't control the lights in the plane).
IMHO, the whole "hack" sounds like a BS/PR action. Yes, you can "fake" GPS, ADS-B, and other communication protocols. However, there are other sources of information for pilots (e.g. the old and true magnetic compass) that can and should be used to validate and cross-reference the data. From a pilot's perspective, a "fake" GPS is no different from a "failed" GPS (yes, this happens). One should be ready to deal with this to qualify as a pilot.
Thing is, if you're able to inject un-authorised code into the FMS, chances are you have bigger concerns than a single aircraft getting hijacked.
It's the equivalent of saying "If I had access to a bank's mainframe and network infrastructure, I could steal millions of dollars with an Android App." Sure you could, but is the problem the fact you can do it with an Android App, or the fact you were able to inject the code in the first place?
1. Get root on one of the plane's systems somehow.
2. After completing step (1), use this Android app to abuse this to display some messages which the pilot will identify as bogus.
Fake and failed are completely different things.
Take for example AF447, it had UNRELIABLE instrument readings which pilots still trusted. Much more dangerous then an instrument giving up it's ghost and it telling you so.
Modifying data subtly enough for it to not trip BS-detector is a valid attack vector.
Of course the rest of the story is theoretical, but so have been many emerging attacks.
I consider this a tool that can in theory be used in combination with other tricks to do something bad. To have it in the open means that the vendors have to put more safeguards in place and make the system safer.
AF447 crash was caused by not following the procedures for the loss of airspeed reading followed by lack of basic manual flying skills (e.g. complete inability to fly the plane at high altitude w/o autopilot). Read the final report, it's not about instruments, it's about pilots.
The pilots where inexperienced being in a violent thunderstorm with computers giving intermittent false information. There were no outside visual references. It was a complex set of circumstances that converged.
I have a pilots license and I agree that sitting on a couch, reading the report in retrospective there were cues that could have been interpreted differently, there were procedures that should have been followed more directly and other things that could have been done to prevent oneself to get into this kind of mess in the first place.
BUT. Would I have performed better in the same position? I don't know. Reading crash reports is for educating oneself so you can perform better in the next sticky situation or spot problems a mile away.
Can this attack in the original article crash airplanes alone today? Definite no.
Can it be evolved to play a part in some other foul play sometime in the future? I would not underestimate the inventiveness of people.
Things fail all the time. This is why there is redundancy built into the system. A pilot just need to know how to detect the problem and how to use secondary systems.
If he did that then that is a colossally huge caveat to his claims.
I have strong suspicions... I saw a fascinating presentation a couple of years back* by the guy who built this: http://maps.spench.net/aviation/ (requires the Google Earth browser plugin). He's using the Universal SDR (software defined radio) to listen to various bits of telemetry coming down from commercial airliners (including, amusingly, automated reports from toilet failures!) and plotting in real time all the planes he's detecting data from. He's using ~$800 worth of radio hardware to recieve those transmissions, but you can listen in on those bands for a lot less using something like this: http://www.funcubedongle.com/ - and I've heard talk about re-purposed USB cableTV dongles being useable down in the ~$30 price range.
What the USDR can do that the cheaper receivers can't though, is _transmit_ on those bands. Hearing how readily Balint decoded the ModeS data, I'm 100% sure that a technically competent but not-very-sophisticated attacker could very easily transmit their own data on those channels using a USDR with the appropriate TX daughterboard (and, in the context of the original article, could easily control the USDR transmitter with an Android app).
(I do vaguely wonder whether any of the radio hardware in a typical Android device is "universal" enough to be convinced to transmit on the bands required here - I'm not quite enough of a radio-geek to know and/or go looking right now. I _strongly_ suspect not, and that if the original article has kernels of truth in it, it's referring to external transmitters controlled by an Android app)
As to the question about the radios in cell phones the answer is yes and no. Yes a lot of modern baseband are nothing more than an SDR, but that's only part if the issue. The other issue is getting appropriate signal levels into and out of that device. For that you need specific filters and antennas for the frequencies you want to receive and transmit. For example, an LTE baseband can work on any of the LTE frequencies (and then some) but specific handsets will have filters for the appropriate region the handset is sold in. While you can change these it's just easier and cheaper to use something like a USRP.
If your interested in radio at all I suggest you start liking into ameture radio. There's still a ton of interning tinkering with everything from Morse code to data communications from 3MHz all the way into the hundreds of GHz frequencies.
That may be true, but this does not not seem to address the other claim that an attacker could inject false information into the FMS or cause it in some way to give misleading information to the flight deck, which could be nearly as bad.
The pilot will probably maneuver a bit to make room, and then will A) tell ATC about this, get a "what other aircraft" response, and B) look out the window, see there isn't another aircraft, and C) decide something's buggy with the system that's displaying the message.
Before this all went public, it would have been followed with D) maintenance crew looks into it after the plane lands.
Now that it's public, it will be followed with D) the plane lands ASAP and everyone on board has a nice chat with guys who have uniforms, guns and absolutely no sense of humor.
I saw this talk at Blackhat on vulnerabilities in ADS-B, which scared the shit out of me. The paper is a good read http://media.blackhat.com/bh-us-12/Briefings/Costin/BH_US_12...
tl;dr: once a second every commercial plane transmits its location, heading, and speed over an unencrypted unauthenticated protocol, and other planes and air traffic control take it for truth.
a) is transmitting an AIS identifier that matches the paperwork already received
b) has been transmitting AIS track data that aligns with the paperwork already received since leaving the source port
Furthermore, ships have to allow a pilot on their vessel for pilotage into a port berth. Once they have pulled aside, the area surrounding the berth is, at least for most developed countries, a maritime security zone with barbed wire fences, security patrols and surveillance cameras.
The aviation sector has all of the above controls in place with even greater rigour. Encryption of track data, when factoring in the complexity of key exchange mechanisms and the expense of swapping out old hardware, would therefore have limited effect on either maritime or aviation security.
[1] https://en.wikipedia.org/wiki/Automatic_Identification_Syste...
And there are some _really_ obvious reasons why you wouldn't just go and do that so you can present the results at a conference. If the claims _are_ true, you'll need to get someone with the authority to grant you the privilege to demonstrate your attack against their aircraft - and so far as I can see, the most likely way to get to do that is probably to present a plausible and perhaps overblown paper at a well publicised conference.
https://en.wikipedia.org/wiki/Automatic_Packet_Reporting_Sys...
You could spoof Mode C altitude, of course. You could spoof a distance from the radar that's more than what your actual distance is by delaying your response to the interrogation. But that's about it. You can't spoof direction, and you can't pretend to be closer than you really are. I'm sure you could still make a minor nuisance of yourself, but it's not going to be a very big deal, I'd think.
I think you'd have to either be very close to the radar or airborne to pull any of this off, too, which means that you likely get to play games only once, then the large men in black suits will come ask you to please stop.
The simple fact that no one has been able to accomplish it yet should not mean in the slightest 'No, you can\'t'.
The dude solved the halting problem? I really don't trust in people that think they control complex computers running turbofan engines through sticks and displays.