Webcast Registration
Join members of the Rapid7 research team from 2 p.m. to 3 p.m. EST on Tuesday,
Aug. 27, to learn more about the findings of this research report and the safety implications for modern aircrafts.
Introduction
Modern aircraft systems are becoming increasingly reliant on networked communications systems to display information to the pilot as well as control various systems aboard aircraft. Small aircraft typically maintain the direct mechanical linkage between the flight controls and the flight surface. However, electronic controls for flaps, trim, engine controls, and autopilot systems are becoming more common. This is similar to how most modern automobiles no longer have a physical connection between the throttle and the actuator that causes the engine to accelerate.
Before digital systems became common within aircraft instrumentation, the gauges and flight instruments would rely on mechanical and simple electrical controls that were directly connected to the source of the data they were displaying to the pilot. For example, the altitude and airspeed indicators would be connected to devices that measure the speed of airflow through a tube as well as the pressure outside the aircraft. In addition, the attitude and directional indicators would be powered by a vacuum source that drove a mechanical gyroscope. The flight surfaces would be directly connected to the pilot’s control stick or yoke—on larger aircraft, this connection would be via a hydraulic interface. Some flight surfaces, such as flaps and trim tabs, would have simple electrical connections that would directly turn motors on and off.
Modern aircraft use a network of electronics to translate signals from the various sensors and place this data onto a network to be interpreted by the appropriate instruments and displayed to the pilot. Together, the physical network, called a “vehicle bus,” and a common communications method called Controller Area Network (CAN) create the “CAN bus,” which serves as the central nervous system of a vehicle using this method. In avionics, these systems provide the foundation of control systems and sensor systems and collect data such as altitude, airspeed, and engine parameters such as fuel level and oil pressure, then display them to the pilot.
After performing a thorough investigation on two commercially available avionics systems, Rapid7 demonstrated that it was possible for a malicious individual to send false data to these systems, given some level of physical access to a small aircraft’s wiring. Such an attacker could attach a device—or co-opt an existing attached device—to an avionics CAN bus in order to inject false measurements and communicate them to the pilot. These false measurements may include the following:
-
Incorrect engine telemetry readings
-
Incorrect compass and attitude data
-
Incorrect altitude, airspeed, and angle of attack (AoA) data
In some cases, unauthenticated commands could also be injected into the CAN bus to enable or disable autopilot or inject false measurements to manipulate the autopilot’s responses. A pilot relying on these instrument readings would not be able to tell the difference between false data and legitimate readings, so this could result in an emergency landing or a catastrophic loss of control of an affected aircraft.
While the impact of such an attack could be dire, we want to emphasize that this attack requires physical access, something that is highly regulated and controlled in the aviation sector. While we believe that relying wholly on physical access controls is unwise, such controls do make it much more difficult for an attacker to access the CAN bus and take control of the avionics systems.
CAN Bus Primer
CAN bus is a vehicular standard created to allow separate devices and systems within a vehicle to communicate using a standard protocol. It is used in many transportation scenarios, such as automotive, maritime, avionics, and even spacecraft.[1] In a modern automobile, for example, there is no physical connection between the steering column and the wheels, nor the brake pedal and the actual brakes. Instead, control is mediated through electronic systems that all speak the same CAN bus protocol on the same physical wiring. This is true for aircraft as well—the signals that affect electrically controlled items such as flaps, trim tabs, and autopilot servos can be directly connected to the CAN bus, and the switches and controls that automate these items are also connected to the CAN bus. On both of the systems tested, the entire engine telemetry system was only connected to the CAN bus and had no direct connections to the pilot’s instruments. The same was true for the instruments that indicated the pilot’s altitude, airspeed, heading, and orientation. The devices that measured these conditions were only connected to the CAN bus, and the pilot’s display relied solely on the data received from the CAN bus.
CAN bus is a packet-based protocol that uses a single twisted pair of wires to communicate on a shared bus. This small amount of electrical wiring is what makes this system particularly attractive to manufacturers, as it reduces cost, weight, and complexity. Furthermore, the bus uses differential signaling, which makes it robust against electromagnetic (EM) interference and allows it to be used in the noisy EM environments typical of vehicular networking. The two wires within CAN are identified as “CAN Low” and “CAN High.” Normally, these wires run a common voltage, typically around 2.5 volts, which represents a binary 1. When driven to a 0, CAN High becomes approximately 4 volts, and Can Low becomes 1 volt. Different implementations can vary the voltages, but the overall principles remain the same. This type of signaling allows for simplified wiring and makes the creation of CAN bus transceivers both easy and inexpensive.
A single CAN bus network uses a shared medium, which means that all nodes on the network see all individual messages on the network. The network uses arbitration IDs to identify the message type and the message priority; a lower arbitration ID always has a greater priority on the bus. In the case of a packet transmission collision, the lower arbitration ID will always be the dominant message and be processed first.
Unfortunately, from a security perspective, CAN bus nodes do not natively enforce the trust models and authentication schemes common in other networking applications. CAN messages do not typically involve any sort of cryptographic protections or assurances of authenticity. Therefore, any device placed onto a CAN bus that manipulates the voltages of the High and Low wires can send any message using any arbitration ID and expect it to be acted upon by the device on the bus expecting a message from that particular arbitration ID. Furthermore, in the case of multiple conflicting messages on a bus, most implementations accept the last message with a given arbitration ID as the most valid.
Due to these architectural limitations of CAN bus messaging, an attacker can flood the network with forged messages and not worry about beating legitimate messages in a race to the targeted component.
For a more thorough introduction to CAN bus applications and their history, National Instruments maintains an excellent and accessible CAN bus introduction, “Controller Area Network (CAN) Overview,” that is appropriate for readers with basic networking and electronics experience.[2]
[2] http://www.ni.com/white-paper/2732/en/
Testing Scope and Assumptions
CAN bus is used widely across the avionics sector, so to understand the current state of avionics networking security, Rapid7 set out to test two commercially available CAN bus implementations popular with small-aircraft pilots. The systems are typical of what could be used in an amateur build or small certified aircraft. While we tested only two avionics products, we believe the findings will be consistent across the field in any system leveraging CAN bus without appropriate technical mitigations. To highlight that this is not a product-specific issue, the names of the manufacturers of the systems we tested have been redacted.
In the first implementation, which we will call Vendor X, the system included the following components:
- 10-Inch Glass Panel display, combine Primary Flight Display (PFD), and MultiFunction Display (MFD)
- Avionics Concentrator
- Engine Instrumentation controller
- Electronic magnetometer (compass)
- Attitude and heading reference system (AHRS)
The second implementation, which we will call Vendor Y, consisted of a system made up of the following components:
- 10-inch combined PFD and MFD
- AHRS sensor
- Electronic magnetometer (compass)
- Autopilot servo
- Engine Instrumentation controller
- Flap/trim electronics controller
The tests covered in this report were performed with the assumption that an attacker would have at least brief unsupervised physical access to the wiring of the targeted aircraft. As mentioned above, physical access is highly regulated and controlled in the aviation sector, particularly with regard to commercial or military aircraft.
Rapid7 recognizes that gaining direct physical access to an unsupervised aircraft is very difficult given current industry practices and regulations.[3] However, we also believe that relying solely on physical security controls is insufficient to protect aircraft against a sophisticated and highly motivated cyber-attacker.
[3] While each airport and airfield is unique and each has unique security requirements, access to aircraft in the United States is controlled by Section 49 of the Code of Federal Regulations, part 1542: https://www.ecfr.gov/cgi-bin/text-idx?SID=d9bd9626b5be189b84ec90135e7b33a4&mc=true&node=pt49.9.1542&rgn=div5
The following section documents the procedure Rapid7 used to send false CAN data onto both the Vendor X and Vendor Y avionics buses.[4] All testing was conducted in a lab environment, and we focused solely on the core technical systems. We did not test the efficacy of physical access controls, nor the feasibility of hopping from one system to another inside a plane.
The avionics CAN bus was connected according to manufacturer specifications. A USB2CAN[5] device was also connected to the CAN bus, along with the other avionics components. The CAN bus messages from the avionics were recorded using a Linux operating system running CAN-utils.[6] The system was reverse engineered by sending individual recorded CAN packets back onto the avionics bus and observing what effects they had with the various nodes. This reversing technique is particularly effective in CAN bus explorations compared to other networking environments, since CAN bus implementations are often susceptible to replay attacks. In addition, Rapid7 modified various CAN messages to observe any interesting effects.
Rapid7 was able to reliably recreate the following findings multiple times on each system tested. Rapid7 did not attempt to use any of the other exposed interfaces to connect to the CAN bus—however, several interesting vectors such as SDCard, WiFi, and Bluetooth existed on one or both of these systems. In addition, some of the devices accepted external connections from ADS-B sources, ARINC 429, and serial devices.
Findings: Vendor X
Rapid7 identified that CAN ID 0x205 was responsible for the oil pressure, oil temperature, and two cylinder head temperature readings. By sending crafted messages using this CAN ID, we were able to send false oil pressure, oil temperature, and cylinder head readings to the display.
Figure 1 shows an example crafted packet:
We also identified that the CAN ID responsible for the compass was ID 0x241, and the attitude and heading reference system (AHRS) IDs were 281-284, with the AHRS acting as node 1. Nodes 2, 3, and 4 were IDs 0x291-294, 0x2A1-2A4, and 0x2B1-2B4, respectively.
10 The AHRS messages were reverse engineered by spoofing messages from nonexistent AHRS units until the displayed aircraft attitude was changed, indicating an incorrect aircraft orientation. Figure 2 shows examples of spoofed CAN bus messages from AHRS Nodes 2 and 3:
As described earlier in this report, the nature of CAN bus allows any device with physical access to the CAN High and CAN Low wires to send spoofed messages onto the bus. The only message arbitration exists in the ID values themselves, with lower IDs having priority to access the bus over higher ID values. CAN packets also do not have recipient addresses or any kind of built-in authentication mechanism. This is what makes the bus easy to implement, but it also removes any assurance that the sending device was the actual originator of the message. CAN bus is difficult to secure because it relies on a shared medium and there is no authentication of new devices that are placed onto the bus.
[4] Note, the vendors and products involved have been redacted from this report in order to maintain focus on the CAN bus architecture fundamental to modern avionics, rather than imply that specific vendors or products are particularly vulnerable to these sorts of attacks.
[5] https://www.8devices.com/products/usb2can
[6] https://github.com/linux-can/can-utils
Findings: Vendor Y
Rapid7 identified that CAN ID 0x10342200 was responsible for the oil pressure. By sending crafted messages using this CAN ID, Rapid7 was able to send false oil pressure readings to the display.
Figure 3 shows a set of crafted packets using this ID:
We also identified that the CAN IDs responsible for attitude and heading were part of a more complicated, non-standard CAN message format. The electronic compass used CAN IDs 0x10A8200 and 0x10A82100 for these messages. 0x10A8200 acted as a header packet, with third byte acting as a length indicator. The magnetic heading, time, and magnetic field strength fields were reverse engineered by fairly standard protocol analysis techniques. An example message with the decoded portions is shown in Figure 4:
The Air Data, Attitude, and Heading Reference Systems (AHRS) messages were also reverse engineered and turned out to be very similar to the messages described above. The AHRS sent 52- and 60-byte messages with CAN IDs 0x10242000–0x10242200. Figure 5 shows an example message with the message size and “Outside Air Temp” identified:
Rapid7 was able to both replay messages as well as craft messages that would then indicate on the Primary Flight Display (PFD) an incorrect altitude, attitude heading, or airspeed. This attack could then be combined with one against the autopilot system. Rapid7 identified that the following messages engaged and disengaged the autopilot:
An attack against the autopilot and attitude indicator could lead to an unusual attitude and potentially loss of control of the aircraft, given that forged CAN bus messages can create disastrous scenarios very quickly.
The aviation industry is not new to discussions of security and safety; in fact, these are top priorities in the industry, to the extent that even competing manufacturers collaborate on an ongoing basis to advance safety and security measures. As mentioned previously, many of these measures relate to physical security—limiting access to critical systems reduces the opportunity for those systems to be abused. Unfortunately, applying such a heavy emphasis on physical controls creates the potential for a single point of failure, with no redundancy behind it to protect these critical systems.
In traditional network security, it is well understood that relying on a single dimension of security for protection is precarious, hence the concept of “defense in depth”.[7] In particular, in cybersecurity, it is generally frowned upon to rely on only securing the environment of the systems, rather than addressing vulnerability of the system itself. For example, while the most correct solution to a given database software vulnerability may be to apply a patch from a vendor, a better solution would involve patching as well as limiting network access to that software through an operating system firewall and a local network firewall, and limiting physical on-keyboard access to authorized personnel. That way, if one of these systems happens to fail—a patch is skipped, a firewall rule is mistyped, or a physical door to a data center is left ajar—other defensive measures are in place to help prevent disaster.
[7] https://www.us-cert.gov/bsi/articles/knowledge/principles/defense-in-depth
Standard CAN bus implementations are popular for vehicular networking due to their electromagnetic properties, simple design, and well-understood, off-the-shelf hardware and software components. However, CAN bus lacks modern network security design considerations, such as cryptographic assurances of message sources or authenticity.
More critically, CAN bus implementations often do not consider the threat model of an attacker with physical access to the shared wiring of the system. While the physical security of airplanes is both well regulated and well tested, this reliance on physical controls may, in fact, be a leading cause as to why aviation CAN bus security has not matured at a pace similar to more traditional security or even automotive CAN bus security.
In automotive networking, there have been significant efforts to mitigate against malicious CAN bus networking, as described in papers such as “Cyber security enhancing CAN transceivers” by Elend and Adamson of NXP Semiconductors and many others.[8] However, the proposed solutions described in the automotive literature, such as CAN bus-specific filtering, whitelisting, and firewalling, do not appear to have gotten much traction in avionics networking, at least in the avionics systems favored by pilots of small aircraft.
This is due, in part, to the emphasis on physical security in aircraft; after all, even small, personal aircraft are rarely parked in unmonitored, open areas like open parking lots or public streets.
With that said, automotive networking is occasionally intermingled with, and compromised by, in-vehicle infotainment (IVI) systems, which dramatically extend the potential attack surface of such networks. Small-aircraft networks are also increasingly seeing similar enhancements with consumer technologies such as Bluetooth and Wi-Fi. The Vendor Y system that Rapid7 tested for this research is capable of connecting an Apple iPad via a mobile application. The application displays many of the same items as the primary flight display and/or multifunction display. There is a capability to load flight plans from an iPad to the avionics system via the Vendor Y application, though Rapid7 did not test this interface as a part of this research.
Given these realities, we offer two suggestions to reduce the risk of avionics CAN bus attacks based on false messages:
- Segment the CAN bus network from these other networks; and
- Encourage secure designs for CAN bus itself.
The common technique used by automotive manufacturers to separate the CAN bus from other components on the vehicle is to use a CAN gateway. This device acts like a firewall, separating trusted components from untrusted connections. Untrusted connections include interfaces such as those used by OBD device scanners, infotainment systems that accept connections via WiFi and Bluetooth, and telematics units that provide remote connectivity for control and diagnostics. These gateways authenticate trusted connections before granting access to critical components. In an automotive system, critical components would include the braking, SRS systems, engine controls, and steering. Broader use of this technique in avionics can help prevent attackers from gaining access to CAN bus through other exposed interfaces, as it does in the context of automotive. Though Rapid7 did not use other interfaces to access CAN bus over the course of this research, our investigation suggested other interfaces may be exposed in the systems we researched.
As for CAN bus itself, we posit that as CAN bus continues to be the preferred solution for in-vehicle networking, effort must be taken to apply the lessons learned from traditional network security. Given the state of today’s avionics technology, cyber-attacks on aircraft can be significantly more subtle than traditional kinetic attacks—and much more difficult to detect after the fact.
The open-ended nature of CAN bus should be seen as an invitation for security innovation. In particular, our research indicates that a message authentication protocol would strengthen defenses against attacks that leverage forged CAN bus messages. CAN with Flexible Data-Rate (CAN FD) represented a significant leap forward for CAN technology in 2012, increasing the maximum frame size from 8 bytes to 64 bytes. Some of that extra space can now be used for security-critical features such as replay protection and cryptographic hashing.[9]
Early internet protocols such as telnet, ICMP, and even TCP/IP were once considered both critical to the normal functioning of inter-networks and ultimately unsecurable. Of course, we’ve made massive strides forward in securing the global internet in response to the demands of security and privacy from all quarters, both in segmenting sensitive networks and building security in to modern protocols such as Secure Shell (SSH) and Transport Layer Security (TLS).
There is no reason to think that CAN bus could not enjoy a similar leveling-up of secure design if manufacturers, framers, regulators, and users demand it. Such advances are quite likely to be incremental at first, but given the collective engineering and scientific talent of the aviation community, we’re confident that secure solutions that implement sensible segmentation and a security-minded approach to inter-device communication will one day be as commonplace in airplanes as they are in automobiles.
[8] https://www.can-cia.org/fileadmin/resources/documents/conferences/2017_elend.pdf
After extensive lab testing of Vendor X’s equipment, Rapid7 reached out to notify the vendor of its findings in January 2018. Given the potential safety implications of aviation technologies, and that the findings in this paper highlight a more systemic, architectural issue than a traditional set of information security vulnerabilities, Rapid7 deviated from its usual 60 day timeline for coordinated disclosure.
Once the findings were communicated to Vendor X, Rapid7 acquired a similar collection of CAN bus enabled components from Vendor Y in order to validate the findings were general to CAN bus avionics implementations, and not an artefact of merely one vendor. This follow-on study was completed in May of 2018, and those findings were communicated to Vendor Y in the same month.
After the vendors were informed of these findings, Rapid7 set out to coordinate disclosure among several government and aviation industry organizations, from September of 2018 through July of 2019. Those coordinated disclosure efforts included representatives from:
-
Cybersecurity and Infrastructure Security Agency (CISA) of the U.S. Department of Homeland Security
-
Idaho National Labs (INL)
-
The U.S. Federal Aviation Agency (FAA)
-
The Aviation Information Sharing and Analysis Center (A-ISAC)
Rapid7 would like to thank all of these organizations and the original equipment manufacturers for their time and valuable input for this project.
Rapid7 (Nasdaq: RPD) is advancing security with visibility, analytics, and automation delivered through our Insight cloud. Our solutions simplify the complex, allowing security teams to work more effectively with IT and development to reduce vulnerabilities, monitor for malicious behavior, investigate and shut down attacks, and automate routine tasks. Over 7,200 customers rely on Rapid7 technology, services, and research to improve security outcomes and securely advance their organisations. For more information, visit our website, check out our blog, or follow us on Twitter.