I think you know you are talking chalk and cheese here !

You know very well that particular network was most likely targeted by well funded, well connected entities possibly linked to one or two governments with a vested interest.

I think a well placed, high power ground transmitter could easily overcome a more distant "legitimate" transmitters.

Even though this discussion has been focused on the ground/air links, I would be willing to wager that the back-end ground link portions of these systems are almost as vulnerable. Why spend money on a transmitter when you don't have to.

Never underestimate the power of money or determination. :)

F.OBN;

Again, thank you for engaging the question. I think discussion of this matter is important so that the salient issues can be discerned against a substantial background noise.

The salient issue is, as stated, that there are certain vulnerabilities to ACARS, ADS, (and also to GPS/SatCom, but that too, is old news; we've known about Satellite / GPS jammers for years). To me, the widespread (and growing) use of iPads for critical flight planning, weight-balance, enroute and approach-plate work represent a far, far greater security risk in terms of hackability with clear and safety-related results, than the present matter under discussion, but we'll stay on-topic.

The background noise is the inability of those proposing the notion that this is a serious problem, to articulate the means by which this is more than just an ACARS / ADS vulnerability issue which is, like the issues mentioned above, probably well known.

The presentation works because it implies much but says very little. We'll see where this all is in a week or so.

PJ2

How did this guy supposedly get around the requirements to ACCEPT, LOAD, and EXECUTE a flight plan change; and override the altitude locked in via the MCP?

Sounds like a lot of sensationalism, or some ACARS and ADS/CPDLC implementations are a LOT different than the ones on the 744 and 748...

PJ2,

Thanks for the response. As you have noted, it is a very complicated issue. It isnt about GPS jammers, or high powered signals from the ground, these are at best, an annoyance.
This about getting to some of the core processes.
Like a thief, you check all of the ways into the building, and the first thing you is when you get to the 32 floor, you lock down the elevator behind you.

How are these commands entered?

(in the 744, there are, from what I remember, 4 places where you can command disengage to the autopilot system, and the system can disengage itself?)

edit: this is just f'n great...this made Yahoo news... How a single Android smartphone can crash an airplane)

I think you and PJ2 may be confusing what the FMC/FMS allows the flight-crew to do (often a company decision limiting training requirements) and what the FMC/FMS software can actually do. Just because they have not put the menu items, buttons and switches on the outside doesn't mean that the software capabilities are not there. Indeed, I would be surprised if there were not several undocumented capabilities put into the software and passed through certification, so that they could be 'delivered' rapidly as upgrades just by allowing the function.
Like many control systems (such as power control systems, communication switchgear, flood gates etc) the firmware and software may have been written without any attempt at defensive coding. There are often hidden codes left over from testing that due to certification issues are not taken out - as nobody would send that code over ACARS would they? Well seems that it is possible. I would be more interested in how he accessed the ACARS frequencies and spoofed the log in from a standard Galaxy phone. But once into ACARS I have no doubt this is possible.

I've seen many hacks that simply use amount and repetition to cause a failure in the code somewhere. The basics are:
1. Analyze code in the target computer.
2. Find some code that will break when presented with a contrived data input.
Note this input can be huge and even presented over time with careful timing.
3. Imbed code in your input that does what you want.
4. Hit the target with this input.
5. When the code breaks the computer blithly keeps on running - right into your code.
6. Computer is now running your code with whatever permissions the broken code had or possibly more or even maybe ALL permission (depends on design, cpu etc etc)

Anyway, the quick version. Years ago I remember being amazed at how the memory allocation from repeated calls was tricked into providing unzeroed memory to the process. Guess what? The process assumed the memory would have all zeros. Bham!

One of the basic problems with code written these days is variable range checking. It takes coding time to write the code, CPU time to execute it, and engineering time to validate it. As code becomes increasingly complex, the penalties expand exponentially, so it is often skipped. This, in combination with "vestigial" code, or deliberately added "undocumented function calls" create an enormous opportunity for exploitation.

It looks to me like these systems were designed under the security through obscurity mantra (after all, who would mess with our little corner of the world?). This, of course, never works, especially today's connected world where nothing is "obscure".

I read the following list of "features" that were demonstrated to work against the simulators by Teso's Android AppSeems like the real deal to me. The paranoid in me would speculate that the powers that be have known about this vuln for a while and this is, in part, one of the reasons for the "no electrics" ban on takeoff/landing (the most vulnerable part of any flight). I can only hope things are patched soon to make tampering more difficult. A hardened fix may require a complete change in architecture.

Areobat
Not sure that would be necessary. All that would be required is a communications gate keeper in firmware that security checks the ACARS/ADS or any other inputs in the same way virus scanners work today. The speed of the scan compared to the lethargic ACARS or ADS would mean that it would not slow anything down.

All these issues will be revisited as the aviation world is dragged kicking and screaming into modern communications systems with Aircraft Access to SWIM (System Wide Information Management). Perversely, in the SWIM world things will be far more secure mainly because it is perceived as a less secure environment and therefore there is no false sense of security.

Is hacking into an aircraft's systems actually possible? :eek:

Please tell me no!

Please reread the 29 posts!:}

You're in luck. No.

I would imagine there are security concerns with regards to the ease that information on flights is available. But that is just information.

Actually hacking an aircraft systems, I don't really know what this guy is getting at. ACARS is a character based protocol, it just sends and receives text documents, not commands, just messages. Suggesting otherwise is like saying you can automatically make my phone dial a number by sending me an SMS. Not physically possible.

Fake ADSB targets is possibly a concern, as I think it is just data. I'm not sure, but I don't believe TCAS can be fooled as the range and bearing is internally computed by the interrogating aircraft, therefore only the altitude can be spoofed and the spoofer would need to be overflown by the aircraft to fool the aircraft into an RA.

It is indeed, totally possible! The SMS protocol was adapted so that people could send point to point text messages, but was originally designed into cell phones as a control protocol, a function it still also serves today. Most people don't know that things like your voice mail message indicator status or caller ID are carried as control messages via the same SMS protocol as text messages. They are just processed by the phone so you don't actually see them. Flaws in cell phone firmware have led to some exploits in the past, most notably, the iPhone: How To Hijack 'Every iPhone In The World' - Forbes.com These attacks were carried out by sending maliciously formatted SMS messages which the phone failed to reject (Apple was a bit of Newbie in the phone world at the time). It's the same situation here.

I wondered if that would come back an bite me :ouch:

After a bit of digging, this iPhone hack is not what is seems. It is basically a code injection exploit and requires the user to install an app. The security issue was that Apple allowed the app into the App Store without noticing the app's ability to receive and execute code that could possibly take control of your phone. The main stream news articles seem to be suggesting that it is possible to just send an SMS in the standard way, which is not the case.

Likewise, the reporting of this issue. This code injection isn't physically possible with ACARS and certainly is not the method talked about in that presentation anyway. That bloke is suggesting that you can generate false alerts, steer the aircraft and even turn it into a lawn dart with ACARS as it is, unmodified and using off the shelf gear. It isn't clear exactly how he demonstrated the vulnerabilities. Whatever, suggesting that he can remotely control the aircraft with ACARS or ADS-B is just looney tunes.

If you look at the pdf presentation he is saying that there are multiple ways to access ACARS on an aircraft if you know its address, ARINC and SITA make this a selling point. So getting ACARS messages up to the aircraft is simple.

He then uses standard hacking techniques like malformed messages, for esample an ACARS message that should have a character count instead provides a negative number or a ginormous number, he can do this because he is not trying to send ACARS messages he is trying to break the receiving software and he is not using an ACARS friendly transmission system. The computer that is running the ACARS software is _also_ the one in which a whole pile of other things run including the FMC, display processing, MCDU etc etc. So if he can make it run some exploit code by sending it a broken message that then allows him to upload some more code running at high authority, he has broken into the computer that is running around "80 - 100" of the major control applications of the aircraft.

Its all on the pdf slides.

Re Forbes' article, "How to Hijack 'Every iPhone iIn The World' ", here is Forbes' take on the present issue under discussion: Researcher Says He's Found Hackable Flaws In Airplanes' Navigation Systems (Update: The FAA Disagrees) - Forbes

The claim has been made that the author of this presentation could send radio signals to aircraft such that aircraft so hacked could be commanded to change direction, altitude and speed.

So far, no one has even outlined the steps and process let alone detailed the unbroken chain of technical events which would lead to an Android phone taking control of an aircraft beyond the crew's awareness or ability to counter the hack.

For the reasons I have posted above and in subsequent posts I suggest that the challenges are almost insurmountable when it comes to actually manipulating the flight controls as claimed by Mr. Teso.

That ACARS, ADS and CPDLC are potentially hackable is not in dispute. It is the extent of the threat that requires delineation, and I propose that such threats do not encompass actual control of the aircraft.

Hacking instrument displays such as Primary Flight Displays and Nav Data Displays with examples such as TCAS & GPWS indications still require assessment, resolution and action by crew members, and are not automatic responses by the autoflight systems. The implementation of providing uploaded data to make such a system "think" there is either an intruder (TCAS) or a legitimate EGPWS warning, is a herculian undertaking which would yield very little cockpit effect and zero aircraft effect. The "return" on the "investment" required just isn't there.

Route changes require manual executions using the FMS keyboard interface; no autoflight system changes altitude without manual input by the flight crew; speed changes are an autothrust function but inputs are reasonableness-checked by the FMS.

PJ2

There's a risk that the following quotations were reported in (InformationWeek | Business Technology News, Reviews and Blogs and Information for the World's Business Leaders - Forbes.com) incorrectly or may become superseded, the overall message though is quite clear; Honeywell, Rockwell-Collins, EAS and FAA aren't presently worried.

Honeywell spokesman Scott Sayres via phone
“If we talk very generically -- not just about Honeywell software -- PC FMS software is normally available as an online pilot training aid”
“In other words, what Teso did was hack a PC-based training version of FMS that's used to simulate the flight environment, not the actual certified flight software installed on an aircraft.”

Rockwell Collins
“Today’s certified avionics systems are designed and built with high levels of redundancy and security. The research by Hugo Teso involves testing with virtual aircraft in a lab environment, which is not analogous to certified aircraft and systems operating in regulated airspace.”

EASA spokesman Jeremie Teahan via email
“This presentation was based on a PC training simulator and did not reveal potential vulnerabilities on actual flying systems"
“There are major differences between PC-based training FMS software and embedded FMS software. In particular, the FMS simulation software does not have the same overwriting protection and redundancies that is included in the certified flight software”
“For more than 30 years now, the development of certifiable embedded software has been following strict guidance and best practices that include in particular robustness that is not present on ground-based simulation software”

FAA
“The FAA is aware that a German information technology consultant has alleged he has detected a security issue with the Honeywell NZ-2000 Flight Management System (FMS) using only a desktop computer. The FAA has determined that the hacking technique described during a recent computer security conference does not pose a flight safety concern because it does not work on certified flight hardware. The described technique cannot engage or control the aircraft’s autopilot system using the FMS or prevent a pilot from overriding the autopilot. Therefore, a hacker cannot obtain “full control of an aircraft” as the technology consultant has claimed.”

In my experience, simulations are the basis of extremely powerful techniques towards understanding the normal (expected) and emergent behaviour of any complex system, but it is usual to increase the throughput of test data by removing something. Once a cut-down simulation of a system has been produced, there is the need for extreme care in the usage of test results, as they can produce misleading positive and negative views of the real thing.

IMO PJ2, in particular, has correctly highlighted the irresponsibility of the presentation and subsequent re-broadcast of the work. In other fields, we know that, such presentation would not occur without peer review. It's actually a great shame that further output from the individual and their organisation may be devalued to some extent, as a consequence of this publicity.

I'm happy to fly alongside an Android and I'm happy to participate in a simulation, provided that it stays in the laboratory.

00, 01, 10 n 11

PJ2
If I have exploit code inside the Common Core System, then I put the characters I want into the FMS keyboard buffer storage area in the CCS followed by a return and it executes just as if the crew had entered it. Nothing would appear on the CDU. The slide he shows also indicates that the display outputs come via the CCS - so the displays could be made to show something entirely different to what the aircraft is actually doing. A hacker could reallocate all the crew accessible keys in the translate tables so that the crew would be unable to use the CDU or perhaps even on/off switches if they are actually 'software configured'.

Please forgive my ignorance but I thought aviation systems were among the most protected If not the most protected) on the planet!

Don't national aviation authorities insist on an aircraft's software systems impenetrable when they certify a new aircraft and then require it to continue being impenetrable?

Ian W, thanks for a detailed response. I can appreciate the potential vulnerabilities a bit more clearly. We'll let this "bake" for a while and see what next week brings. - PJ2