The great Boeing Dreamliner false-positive hack of 2019
IOActive security researcher Ruben Santamarta dropped a bombshell at Black Hat 2019 that the Boeing Dreamliner is susceptible to hacking. Cause for concern or false alarm.
Introduction
It’s only August, and 2019 is undoubtedly a terrible year for Boeing. The problems with the 737 MAX are perhaps the biggest crisis the legendary firm has ever faced. Add to that several major airlines, including Etihad and KLM, have complained to Boeing about poor quality control in new deliveries of the 787–10 Dreamliner, and claim the airplanes were delivered well below acceptable standards. Also, just last week, Boeing pushed back the entry into service of an ultra-long-range version of its forthcoming 777X widebody.
As misery loves company, Boeing is again finding itself in the crosshairs of yet another crisis with the recently released report of serious software flaws within their flagship airplane — the 787 Dreamliner. On August 7, well-respected information security researcher Ruben Santamarta of IOActive released his report Arm IDA and Cross Check: Reversing the 787’s Core Network. The report details supposed software security flaws within some of the systems on the Boeing 787 Dreamliner.
In describing the findings, the report states that the researchers have found the first plausible, detailed public attack paths to effectively reach the avionics network on a commercial airplane from either non-critical domains such as passenger information and entertainment services, or even external systems.
Neil Rubenking and Max Eddy write in Black Hat 2019: The Craziest, Most Terrifying Things We Saw, of The Great Boeing 787 Hack Fight of 2019. They note that Santamarta unveiled his potential attacks on the Boeing 787 network and believes it’s possible to reach sensitive systems through a variety of entry points, to which Boeing says it’s all bogus.
A nerdy joke says that “there are two types of people in this world — those that can extrapolate from incomplete data sets.” As I’d like to show — Santamarta has an incomplete data set. His initial findings are indeed cause for very, very serious concern. However, when the reality of airplane networks and underlying security controls are understood in their full context, and the data set is completed — we’ll see that his work, while impressive, is a false positive.
While the fix for the 737 MAX is limited to a single system, this security issue if real, would be much more significant. The 737 MAX fix is taking many months. If the Dreamliner is as bad as described, a full repair will take years to fix entirely.
However, the underlying question is this — are the findings and full implications from IOActive cause for concern or something less? First, let’s dig a little deeper.
Before we even get there, that Santamarta found this code on an unprotected server is cause for concern. The fact that Boeing had a server with source code publicly available indicated significant security issues. The challenge Boeing faces, like other firms of similar size and complexity, is that they must secure a vast set of networks, often with hundreds of thousands of servers and endpoints. While they must ensure that every aspect of their perimeter is secure, researchers like Santamarta have the advantage in that they only must find a single vulnerable endpoint.
Also, Santamarta is quite transparent and notes that his findings don’t indicate any immediate threat. But that message has not fully trickled down to the media, who are reporting on this story as if it was a real vulnerability and risk to the immediate safety of the Dreamliner fleet.
Aviation security is a highly complex topic, and the media often misses essential nuances. As I wrote last year in Where Chicken Little meets information security Outside of a movie theater, your plane won’t be hacked out of the sky; the media was reporting that aircraft could be hacked out of the air. However, that was not the case.
As to Santamarta, he is an extraordinarily talented and tenacious security researcher working for a firm that is not prone to histrionic security publicity stunts. With that, his report is something that should be taken seriously. However, if there is a flaw in the report, it’s that the researchers don’t have internal aviation, primary and secondary avionics experience, in addition to not being able to test the issues in a real-world setting. This however is of no surprise, as every aircraft platform is unique and the OEMs go to great lengths to make sure their intellectual property is protected, since these programs have a decades-long ROI, therefore external access to these aircraft platforms is highly restricted and limited.
What’s undeniable is that both Boeing and Honeywell confirmed that these vulnerabilities are present in the Dreamliner Core Network codebase. The question is — are there additional worries?
Playing nicely in the Boeing sandbox
The researchers reached out to Boeing with the hope of getting access to a plane to perform real-world testing of the vulnerability. In the end, Boeing didn’t invite them to do that. Anyone who has worked in the defense or aviation industry is not surprised by that. While other sectors may have been more inviting and had the very talented IOActive researchers come onsite; anyone who knows Boeing would not be at all surprised by their reticence in having them come onsite. There are myriad legitimate reasons to explain this; from legal, regulatory, and more.
It should be noted that Boeing has long used the services of independent security firms to perform on-board security and penetration tests. The IOActive researchers were understandably disappointed that Boeing did not invite them to do further testing. However, Boeing’s response, for a firm in a highly regulated and highly competitive sector is to be expected.
While Boeing and Honeywell confirmed to the researchers that these vulnerabilities are present in the 787 Core Network codebase, Boeing stated that they have mitigations in place that prevent the vulnerabilities from being exploited. The researchers were not happy with the fact that Boeing was unwilling to share additional details with them.
They understandably found that response to be deeply disappointing as it prevented them from independently validating the exploitability of the identified vulnerabilities. Without a 787, or a Dreamliner lab environment, or an explanation of the controls, they were unable to confirm Boeing’s claims of compensating controls or mitigations for these software vulnerabilities.
It’s in the best interest of firms to play nicely with legitimate security researchers. But it should be recognized that Boeing and Honeywell are in no way obligated to prove to, or even reply to any security researcher why their mitigating controls are operative.
The airline sector is sui generis, and external parties need to understand that what is de rigueur in other industries, merely is foreign in the aviation sector.
A related example is Rolls-Royce, who have had many years of embarrassing durability problems with a series of their Trent 1000 aviation engines, including problems with other engines. Rolls-Royce is notoriously close-lipped, much to the chagrin of the press.
Be it Boeing, Honeywell or the countless other OEM in the aviation sector — they all are extremely security conscious and have dedicated teams for each aircraft platform. Security is seen as not being any different than any other design criteria. The difference between aviation and some other sectors is that we don’t see the OEMs publicly discussing their engineering design, testing, and certification activities. Also, they treat security activities in the same manner.
While Boeing’s response to Santamarta didn’t leave him with a good feeling; there’s no real correlation between poor PR and ineffective security. In defense to Boeing, they are under tremendous pressures now, and their PR teams are likely stretched to the max.
Ultimately though, one should not infer anything from Boeing’s PR responses. These responses have included the term theoretical, which in the information security world has long meant that it’s just a matter of time until they become real-world vulnerabilities.
For example, Microsoft long used that term when responding to and dealing with the Cult of the Dead Cow. The result of these theoretical vulnerabilities was later made quite real exploits in hacking tools such as Back Orifice and Back Orifice 2000.
While Santamarta and the media could take the Boeing PR response as stalling and failure to admit a significant vulnerability, the reality is that the world of aviation security is sui generis. The controls in place as I’ll show indicate that the PR response, while lacking, can infer nothing.
Avionics
Everyone is in agreement that IOActive found legitimate vulnerabilities. However, do these vulnerabilities mean the Dreamliner is not airworthy? This is where I turn to my friend Jayson Agagnier. He is an aviation security specialist and spends a good part of his week inside of airplanes and cockpits dealing with avionic systems — both primary and secondary.
Agagnier has designed aircraft security architectures, performed certification testing and contributed to numerous ARINC and RTCA technical standards and guidance material documents related to aviation systems and security. Put mildly, Agagnier knows his stuff.
To that, Agagnier feels that it appears that the researchers have a lack of fully comprehending just how the A429 avionics data bus & A664P7 avionics full-duplex switched Ethernet (AFDX) networks operate and how these systems interface with each other using those networks.
Other assumptions appear to be incorrectly made about the network architecture of the aircraft. Besides, it seems that the researchers had an incomplete understanding of the integrated modular avionics (IMA) architecture used in the 787 by trying to draw a parallel to consumer-level COTS network technology that they extremely familiar with. That comparison led them to draw inaccurate conclusions based on those misconceptions.
Agagnier notes that it appears that the researchers dedicated a great deal of time to perform Internet research on the topic, but the majority of the citations used in the presentation yields only a partial and incomplete picture of aircraft architecture, avionics, and data networks.
The core problem with the report is that the researchers make several assumptions regarding aircraft system design and integration. This is not the place for a complete point by point rebuttal, but some of the more significant issues are:
Systems architecture — All modern (from the 777 onwards) aircraft platforms use multiple redundant systems and networks for their critical flight control functions. In addition to the redundancy, some systems use a different processor and architecture, this explicitly done to help mitigate the risk of a hardware or software vulnerability in one system affecting the critical flight function provided by the system.
For example, hypothetically, one system would use a real-time operating system and applications compiled for, say an AMD processor architecture, while the other redundant systems would use a PowerPC processor architecture and a third redundant system would use a Motorola 680x0 processor architecture.
Network architecture — In addition to redundant systems, modern aircraft platforms use redundant networks and in cases of critical systems, timed networks. If any single system (System A) receives data that is mistimed, not of the right data type or coming from a system (System B) that is not supposed to be communicating with that system (System A), then the data are simply ignored.
The data networks are also comprised of individual transmit and receive (Tx/Rx) interfaces. Many systems only have a Tx interface connecting to a corresponding Rx interface on another system. The in-flight entertainment (IFE) system, for example, has no Tx interface to an Rx interface to any flight control system. All of these interface controls and definitions are managed and controlled by the switching fabric. So, if an attacker was somehow able to compromise one system (IFE for example), that does in no way mean that there is a path to anything deeper and meaningful on the aircraft network.
System isolation — aircraft systems are designed in part to be isolated. As to the 787, there is no cabin access to the secondary avionics and maintenance systems, which is where the Honeywell crew information system/maintenance system (CIS/MS) is. It is also important to note that the CIS/MS is not a critical system for flight.
While there may be a vulnerability in the IFE, that does not mean it can travel to other systems. As detailed, due to network isolation and difference in data types, one can’t jump from the IFE, to the CIS/MS and then to other systems.
System updates — it’s essential to understand that aircraft systems can’t be updated in-flight or on the fly. This means that if an attacker is seated on the airplane, there’s no way they could modify systems. There are only three ways to update a system on a modern aircraft:
1. Take the hardware off the aircraft and return it to the manufacturer for a factory performed update.
2. Some larger airlines have their own maintenance organizations with the required specialized equipment to perform a bench update of a particular system using a portable data loader (PDL) or some other type of specialized data-loader.
3. On-wing update — newer aircraft (A380, A350, A220, B787, B747–8) use what is called LSAP (Loadable Software Aircraft Part). An LSAP update is possible; however, this update can only be performed while the aircraft is on the ground. Specialized hardware (physical switch(es)) must be set, to place the IMA and relevant systems in maintenance mode. Once the aircraft systems are in maintenance mode, a maintenance engineer needs to follow a sequence of steps to push the update to the target system. The concept of an automatic update does not exist for any safety-critical system. Regarding LSAP, the data sets are at a minimum digitally signed, and in some cases are encrypted when leaving the factory and decrypted when being delivered to the aircraft. More details about this can be found in various ARINC reports.
I’ve a feeling we’re not in Kansas anymore
IOActive seems to have a somewhat misunderstanding of how the aviation industry works and the timelines under which the industry operates. The consumer technology industry, for example, works on a product lifecycle of anywhere from a few quarters to a few years.
Contrast that with the aviation industry which operates with a product lifecycle that is measured in decades. The lack of providing version numbers is typical for this industry, as disclosing a version number can yield great insight and provide a significant advantage to a competitor. The same applies for test plans, test methodologies, etc.
While other industries would be more forthcoming with their responses, the researchers were chagrined that Boeing provided no evidence to back up their claims. As noted, the aviation sector is highly unique, and the reaction of Boeing and Honeywell was as expected, to those that know and work in the industry.
IOActive said they offered assistance to Boeing, but they refused. It’s important to understand that the refusal is likely due to the fact that IOActive may not have a cleared status. Also, since they lack the deep aviation sector experience, bringing them onsite to perform testing may not have been conclusive, given that lack of understanding.
Did we learn anything from this issue?
While the IOActive report was a false positive, there is a lot that can be learned from this incident. Some of them include:
· 99% security is 100% insecurity — Boeing had an exposed server on the Internet. The fact that 99% of their servers might have secured, did little to mitigate the available server.
· Responsible disclosure — as the report detailed, IOActive alerted Boeing and Honeywell, and each of them responded promptly. This is a textbook example of responsible disclosure. Both Boeing and Honeywell had processes in place to deal with security issues such as this one. There’s no shortage of security researchers who send vulnerability information to a firm, only to find it entering a black hole, with no response.
· Ensure PR teams know how to effectively respond to security incidents — the responses from Boeing PR didn’t exude confidence. PR needs need to understand the specific manner to respond to respected security researchers.
So, should one fly on the Dreamliner? The report says that there’s no imminent danger and there’s no direct threat. While the researchers found legitimate vulnerabilities, it is highly speculative that these could ever be used as a launching pad to future, more significant threats. Just because those same vulnerabilities have played out in other sectors, does in no way mean that it could work in the aviation sector.
Enjoy your next flight.
