The presentation at HITB Amsterdam evinced a remote attack against on-board aircraft systems that allowed partial control of the navigation capabilities of the target. In order to be able to accomplish that, many aviation specific technologies were used. Due to the specific aviation protocols used, mainly unknown to the average IT professional, every phase of the attack will now be explained in detail.
The attack is divided into three main phases that match the ones used during any attack scenario: Discovery, Information Gathering and Exploitation.
Let’s now see each of these phases in deeper detail by learning about the aviation specific technologies employed and studying how to use them on this attack.
During the discovery phase the goal is to be able to collect as many potential targets as possible, in this case aircrafts. In order to gain this information a technology called ADS-B is used and we will try to gather all the possible information about the available targets.
This phase will be performed passively by just listening for ADS-B traffic, and never having to send nothing to interact with the aircrafts; although it has been proved that ADS-B lacks the security mechanisms to prevent that from happening (See References).
Automatic dependent surveillance-broadcast (ADS-B) is a cooperative surveillance technology for tracking aircrafts. The aircraft determines its own position and periodically broadcasts this via a radio frequency. ADS-B can be seen as modern radar used by Air Traffic Control to track aircrafts as was done with the older radar technologies.
ADS-B periodically broadcasts information about the aircraft, such as identification, current position, altitude, and velocity, through an onboard transmitter. ADS-B provides air traffic controllers with real-time position information that is, in most cases, more accurate than the information available with current radar-based systems.
The system relies on two avionics components—a high-integrity GPS navigation source and a datalink (ADS-B unit). There are several types of certified ADS-B data links, but the most common ones operate at 1090 MHz, essentially a modified Mode S transponder, or at 978 MHz.
There are two different approaches to collect this information: Free sources and ADS-B Receivers.
There exist many places where it is possible to see a big amount of flights tracked worldwide in, almost, real time. Web sites like FlightRadar24 offer this data and even have mobile applications that can be used for aircraft tracking. Those sites collect ADS-B traffic worldwide with the help of volunteers that use ADS-B receivers to gather aircraft information on their area.
The complete lack of security of the ADS-B protocol permits to listen for this information, that is unencrypted, and gather aircraft detailed information such as: position, speed, heading, altitude, registration number, etc. This is a big amount of information that allows us to gain deep knowledge on all the potential targets in a huge area.
Also, public databases with historical details for most aircrafts can be consulted in order to gather precise information on the common routes flown by an aircraft.
The major drawback of this approach is the lack of information on some areas that may not be covered by any volunteer. To gather precise information on such areas the best way is to collect our own ADS-B traffic. There exist many cheap ADS-B receivers and open source or free software decoders that may allow us to collect and parse this information on our area.
By using both sources together a good view of the local available aircrafts can be obtained, with great coverage and very detailed for our surrounding area. We had good results by using the “microADSB” receiver with the “Virtual Radar” and “ADSBScope” programs. See References for the links.
It is outside of the scope of this post to explain in detail the Hardware and Software available, as well as to explain how to use them to collect ADS-B information, but on the References at the end we have collected some good resources that explain step by step how to setup everything in order to start gathering ADS-B traffic.
After the Discovery phase we now have a list of most of the available targets and some information on each of them. What we now need is to know which of those targets are vulnerable to our exploits.
In a similar way as in a normal computer attack, the goal of the Information Gathering phase is to collect more detailed information on the systems (“services”) running on-board the aircrafts and select those ones that are vulnerable to our code.
We already collected all the information provided by ADS-B communications sent by the aircrafts, so another source of information must be used in order to try to learn about the on-board systems. The approach we are going to follow is the monitoring of another communications protocol, called ACARS.
Aircraft Communications Addressing and Reporting System (ACARS) is a digital data link system for transmission of short, relatively simple messages between aircraft and ground stations via radio or satellite. It can be seen as the e-mail of the aviation.
One of the initial applications for ACARS was to automatically detect and report changes to the major flight phases, these messages are used to track the status of aircraft and crews. In addition to detecting events on the aircraft and sending messages automatically to the ground, initial systems were expanded to support new interfaces with other on-board avionics.
Lately a datalink interface was introduced between the ACARS management units and flight management systems. This interface enables flight plans and weather information to be sent from the ground to the ACARS management unit, for forwarding to the flight management system. This feature gives the airline the capability to update flight management systems while in flight.
Detailed engine reports can also be transmitted to the ground via ACARS. The airlines use these reports to automate engine trending activities. This capability enables airlines to monitor their engine performance more accurately and identify and plan their repair and maintenance activities more rapidly.
As well as with ADS-B in the Discovery phase, we can use two different approaches to collect ACARS data and try to gather more detailed information on the targets: free sources and SDR. This phase is also passive and we will just sniff for ACARS messages and never send any message ourselves.
Live ACARS feeds can be found on the “acarsd” project web site. Although the coverage is far from complete, live ACARS messages can be monitored either using a browser or the acarsd client software. The latter being better more responsive and available for many platforms.
As happens with ADS-B monitoring, the public feeds offer higher coverage but by gathering our own messages we have better data for a specific area. The best approach to capture and decode ACARS messages is by using Software Defined Radio.
Software Defined Radio
In brief, a Software Radio is a radio system which performs the required signal processing in software instead of using dedicated integrated circuits in hardware. The benefit is that since software can be easily replaced in the radio system, the same hardware can be used to create many kinds of radios for many different transmission standards; thus, one software radio can used for a variety of applications.
Standard ACARS transmits at a frequency of 131.550MHz, which is squarely in the receivable range of most SDR. The SDR software radio can be used as a radio scanner for listening to these digital messages, and with the help of some decoding software, can be used to decode and display the messages. The messages you can receive will be from nearby aircraft and ground stations.
Detailed instructions on how to use SDR to receive and decode ACARS messages will not be explained here, but can be found on the reference material at the end of the post.
As has been seen, ACARS is widely used in order to keep track many systems status and to update some of them even while the aircraft is on flight. By collecting and carefully analyzing this type of messages it is possible to guess some of the on-board systems model. This procedure may take some time but within a few days of monitoring, mainly while the targets are on ground between flights, this information can be gained.
It may require a lot of time, but by passively monitoring the ACARS communications of the potential targets, a lot of detailed information regarding the on-board systems can be gathered.
This information is crucial for the exploitation phase, as we need to know precisely the manufacturer and version of the system to be exploited.
If we recall from the ACARS protocol description, there is a very interesting feature to consider: “(…) gives the airline the capability to update flight management systems while in flight”.
A Flight Management System (FMS) is a specialized computer system that automates a wide variety of in-flight tasks, reducing the workload on the flight crew to the point that modern civilian aircraft no longer carry flight engineers or navigators. Its primary function is in-flight management of the flight plan. Using various sensors (such as GPS and INS often backed up by radio navigation) to determine the aircraft’s position, the FMS can guide the aircraft along the flight plan.
From the cockpit, the FMS is normally controlled through a Control Display Unit (CDU) which incorporates a small screen and keyboard or touchscreen. The FMS sends the flight plan for display to the Electronic Flight Instrument System (EFIS), Navigation Display (ND), or Multifunction Display (MFD).
There are many different types of data that can be sent to the Flight Management System via ACARS while the aircraft is in flight, like the Navigation Data Base or the Flight Plan.
The NDB contains all of the information required for building a flight plan, consisting of:
- Airways (highways in the sky)
- Radio navigation aids including distance measuring equipment (DME), VHF omnidirectional range (VOR), non-directional beacons (NDBs) and instrument landing systems (ILSs).
- Standard instrument departure (SID)
- Standard terminal arrival (STAR)
- Holding patterns (only as part of IAPs-although can be entered by command of ATC or at pilot’s discretion)
- Instrument approach procedure (IAP)
The flight plan is generally determined on the ground, before departure either by the pilot for smaller aircraft or a professional dispatcher for airliners. It is entered into the FMS either by typing it in, selecting it from a saved library of common routes (Company Routes) or via an ACARS data link with the airline dispatch center.
Given the flight plan and the aircraft’s position, the FMS calculates the course to follow. The pilot can follow this course manually or the autopilot can be set to follow the course.
The main idea for the FMS exploitation is to send some malformed data to the FMS, via ACARS, that triggers a vulnerability on the parsing code allowing us to execute arbitrary code. If the vulnerability used is the appropriate, it will be triggered before the pilot has to perform any action and the full attack can be therefore remote and straight forward.
The details on the vulnerability and its exploitation will depend on the manufacturer and model of the targeted FMS, as well as the technologies employed that can range from C to ADA and run over proprietary RTOS on a PPC or x86 architecture, among others.
For the initial research on this attack, as access to a real FMS was difficult to gain, training software from one FMS manufacturer was used. It is important to note that this software uses the same code that the on-board FMS and it has a graphical layer programed in Visual Basic to allow the pilots to use this system on a Windows machine for training purposes.
It is important to completely understand these program inners in order to differentiate between the graphical layer and the core with the real avionics system code, as we want to be sure that the code we are exploiting is the last one.
Although the attack delivers the exploit to the FMS via ACARS, for fuzzing and vulnerability research we will use the “local” data loader of the program to load the malformed data on the FMS as it is easier and faster to setup and automate.
On older FMS there are three databases: Software options (OP PROGRAM), Model/Engine data base (MEDB) and Navigation data base (NDB), all of which are stored on an EEPROM memory card. These databases can all be updated via the data loader.
- The Software options database includes the operational program and its update, plus any company specific differences.
- The MEDB holds all the performance data for V speeds, min & max speeds in climb, cruise & descent, fuel consumptions, altitude capability etc.
- The NDB is comprised of Permanent, Supplemental (SUPP) and Temporary (REF). The Permanent database cannot be modified by crew. There are four types of data: Waypoint, Navaids, Airport and Runway. Runway data is only held in the permanent database.
As seen, there are many different data files we can use to find the vulnerabilities, but the easiest ones to focus are the NDB and the Flight Plans. The NDB for the software we are going to use can be found on the root folder of the program and the flight plans on the folder “AFIS”.
In order to load this data manually we have to study the manual and see the steps necessary, and the FMS has not an easy to understand workflow, even less if you are not familiar with aviation systems and terminology. If we want, for example, to load a new NDB, after starting the FMS we have to follow these steps:
- Press the button pointed by the “Maintenance” option on the main screen.
- Press the “DATA LOAD” button on the left
- Select the Database to load from the available options
- Select the option “FR LOADER” and confirm the operation
Any fuzzing framework or tool can be used in order to modify any of these databases and then feed them to the FMS software. Anyway, by simply manually modifying the files some crashes can be easily found.
After loading this modified Database on the FMS a crash happens with some of the registers modified by our input:
Although this specific crash cannot be used to exploit the appropriate code, the one from the real avionic system, it is a good example of the procedure and helps to highlight the presence of vulnerabilities in the code.
No vulnerability details or exploit code is going to be released affecting the avionics code in order to prevent possible irresponsible usage of this work. Our motivation is to help the affected industry to improve the security of their products. We strongly believe in responsible disclosure and we and act accordingly.
In order to send the exploit to the FMS the manual load of the NDB is not a very good delivery method, it is far better to use ACARS in order to send the NDB update remotely to the aircraft no matter where it is located.
There is no published code to transmit ACARS messages using SDR, although can be developed in a reasonably amount of time, and that would be illegal and very dangerous. Although for testing purposes, a controlled testing environment, similar to the described in the ADS-B attack at the References, can be setup to test de availability of the attack vector.
Ground Service Providers
The Ground Service Providers (GSP) are companies that offer, among others, data link communication services to airlines and any other aviation industry related companies. Companies such as ARINC, SITA or Honeywell sell different data link services that can be accessed via all kind of modern interfaces. Web and mobile applications, desktops clients, servers or even cloud services are offered in order to gain customers and make their daily work easier.
A better and easier delivery method would be to gain access to these datalink service interfaces and use them to deploy the exploit worldwide without having to take care of the radio, coding or delivery. This approach will be explained in high detail in an upcoming post.
This is the work presented at HITB Amsterdam in 2013, and we released enough details to help other researchers to start their own work on this field. Although this attack has some difficulties to setup and does not target the avionics code on the real architecture and RTOS, some of those limitations are going to be overcome in future conferences and publications.