Blog: Aviation Security
A Pen Tester’s First Solo: Aviation Security 101
My colleague Ken and I are both private pilots with a keen interest in avionics and security.
We were fortunate to have access to some end of life, functioning airframes so had the opportunity to start investigating the security of airplane and avionics.
Here’s a primer for anyone interested in investigating airplane security. It’s what we’ve learned over the last year
DO NOT TRY TO HACK AIRPLANES WITHOUT EXPLICIT PERMISSION
It is NOT cool to attempt to tamper with in-flight entertainment systems or any other plane system for which you do not have permission:
- It is dangerous
- It is illegal
If you do find issues, engage in responsible disclosure and expect LONG remediation times. Why? Because code changes have to be rigorously tested & certified. Deploying updated code on older airframes can be very time consuming too.
For a long time, the primary security model for airplanes has been physical. Airside security controls are there to prevent access by unauthorised personnel.
This shouldn’t be possible without permission:
Yes, there is potential for someone to socially engineer an airport or for a rogue employee to access an avionics bay unauthorised.
However, it would take a very, very detailed knowledge of avionics systems to effect any serious security issues. Airplanes have multiple redundant systems: if systems disagree (perhaps due to tampering) then this is flagged to the pilot and other systems.
Plus there is always a human in the loop, they can fall back to flying the aircraft manually even if other systems fail.
For example, in the case of a Cat 3B landing (zero visibility, autoland) there are three separate autopilots that must agree. If one autopilot disagrees with the other two, its input is disregarded. Aircraft are used to handling oddness.
It isn’t as if one can simply connect some ‘hacking stuff’ inside an avionics bay and compromise the aircraft. It doesn’t work like that.
In older airframes there is no “bus” across the entirety of the avionics bay to plug into even; line replaceable units (LRUs) are generally connected directly to each other where required, and to head-end units in the cockpit.
Probably the simplest way to ground a plane would be to steal some avionics!! But then it’s no longer a safety issue, as the plane won’t be capable of flying.
Airborne Connectivity: The changing security model
Airborne connectivity has been around for a lot longer than you might think:
The Aircraft Communications Addressing and Reporting System or ACARS was developed by ARINC and introduced in 1978. It uses Telex over VHF or HF.
It was originally introduced to report take off and landing times and used to calculate flight/cabin crew salaries; much more accurate and less time consuming than doing the same via voice over the radio.
Of most interest from a security perspective would be the ability for ACARS to send updated flight plans to the flight management computer on board.
A critical safety control is that the pilot has to manually accept the updated flight plan. However, discussions with current commercial pilots suggest that most plans are blindly accepted. Why would a pilot suspect that a plan was rogue?
Even then, a pilot would question a flight plan that took them towards dangerous terrain or hostile airspace. Ground stations would also question the routing that the plane then took. TCAS (Traffic alert and Collision Avoidance System) would also detect and help prevent two aircraft colliding.
There are too many controls in place for an ACARS flight plan hack to be usefully effective. That said, confusion could be introduced in the cockpit which could start a cascade of events that might lead to trouble
Developments around ACARS include encapsulation over IP and sending of data over satcoms. This is primarily for cost reasons – data charges for ACARS over VHF are significant. This gives rise to interesting security questions – are the ACARS/ARINC systems completely segregated from IFE and other data services in the satcom terminal and infrastructure?
In the days of purely primary and secondary surveillance radar, the controller worked on the data presented from reflected RF energy returns from the aircraft. SSR included a digital return from the aircraft too.
Now, we have Mode-S for transponders and ADS-B.
It doesn’t take much to build an ADS-B receiver – a Raspberry Pi is enough.
It requires that aircraft ID, altitude, lat/long, position, bearing and speed are broadcast. It works with GPS to give extremely accurate position reporting, so much so that planes may be allowed to fly closer together.
The biggest concern is that ghost flights can be inserted in front of aircraft, as ADS-B is neither authenticated or encrypted.
A similar attack is possible with TCAS – creating swarms of ghost planes that will confuse the collision avoidance systems.
Several researchers have reported tinkering with in flight entertainment systems in flight. This is irresponsible. Some have reported the ability to control flight surfaces. I am confident that these reports are misleading.
The IFE has been segregated from the FMS through a one way data diode for many years, if not totally physically isolated.
Connecting in to the IFE seat box (AVU) is probably the route that these individuals took.
We have a few of these, I guess that they unhooked the ethernet cable and middled the traffic, or found data access over the USB charging port. This will show lots of streaming protocols – the AVU is essentially a PC (earlier) or Android tablet (later) in a box. It’s also common to see some encapsulated ARINC traffic floating around on this network.
We suspect that the researchers saw the ARINC traffic and made an assumption that this was flight / engine control data. It isn’t. It’s usually status messages involving the IFE.
Here’s the insides of one of our AVUs. Unsurprisingly it’s from one of the largest suppliers: MAS is Matsushita Avionics Systems, who were then acquired by Panasonic
The above is pretty much a 386 PC
Electronic Flight Bag
The electronic flight bag is typically a tablet or laptop. It connects over Wi-Fi and hugely reduces the paperwork that must be carried on board.
We’ve seen occasions when the EFB is accidentally connected to the wrong network on board – to the pax network rather than the crew network for example.
We’ve been involved in pen tests of EFB applications which had… let’s say varying… levels of security
I’m sure you’ve heard stories of flights delayed because the crew couldn’t access the data on the EFB. Whilst these aren’t strictly safety issues, they are very irritating.
Weight and balance of the plane is often recorded on the EFB, as is the passenger and crew roster, among many other important data sets.
Issues in the past have included crew connecting the EFB tablet to the wrong Wi-Fi network. We’ve also tested a few EFBs over the years: Their security improved on the back of our recommendations…
EFBs are becoming more functional and more integrated with aircraft systems. Some of the offerings from UTC and other suppliers are really quite cool, certainly from our pilots perspective:
There’s a nice EFB explainer on Wired too
Gatelink is a system designed to pass plane and passenger aircraft to ground systems, saving time compared to exchanging physical documents. The IFE, EFB and QA/maintenance systems all need updates
Indeed, later aircraft need to pass so much data in order to achieve efficiency gains; bandwidth that satcom and VHF datacomms cannot offer. Consider the bandwidth requirements for updating the movies on the IFE alone!
Once the undercarriage microswitches are depressed, an 802.11 client is enabled, seeking out certain SSIDs at the airport to connect to and exchange data
Gatelink systems should feature PKI, making a PSK keycrack pointless, but it’s important to validate this.
Whilst we haven’t located any Gatelink hardware to investigate yet, the FCC web site is a useful source of PCB photographs during the RF approvals process, allowing for component identification:
The Quick Access Recorder is a much more capable device than the black box / flight data recorder. It is designed for use in maintenance and fault diagnosis.
Recent developments have included the wireless QAR which, much like Gatelink systems, starts probing for suitable APs on landing.
And can use 3G/4G modems when Wi-Fi isn’t available at remote airfields.
It can then quickly upload relevant flight data to improve performance monitoring and spot early issues that allow maintenance to be planned far better.
Again, PKI should be present to secure the Wi-Fi connection
On board domains
There are three broad domains on an aircraft: the Aircraft Control Domain (ACD) for the cockpit crew, the Airline Information Services Domain (AISD) for cabin crew, and the Passenger Information and Entertainment Services Domain (PIESD) for passengers.
Segregation of the three domains is critical, although certain traffic is legitimately routed between them. DO-326A, 355 & 326A specifically deal with security architecture and review of these networks.
You may remember that FAA approval of the 787 was delayed for a while whilst concerns about insufficient segregation were addressed.
You might be surprised to learn that most ‘satellite communications’ on an airplane have nothing to do with satellites: over land, connectivity is provided using 4G LTE networks with specialised downward-facing beam-forming antennae
Over oceans, satcoms are more conventional, with upward facing uplinks. The satcom terminal is another point where connections may be aggregated in a single physical device. This gives rise to the potential for unintentionally bridging the three domains. Whilst we haven’t yet got hold of aviation satcom terminals to investigate, we have worked on related terminals from shipping. We found a number of concerning security issues, particularly allowing for bridging between the business IT and ship’s engine management OT systems. That’s not to say that there are issues in aviation satcom terminals though.
It’s also worth remembering that revenue from customers paying for in-flight connectivity can be lost if the payment page ‘walled garden’ can be broken out of or bypassed through (for example) DNS tunelling.
This is one of the largest challenges and biggest obstacles to security. Navigational databases need to be updated each month to account for waypoints and beacons changing.
Broader software updates are also required from time to time, covering the usual bugfixes and feature upgrades that you would expect.
Here’s an Aircraft Data Loader (ADL) that is used on a 737 to update the DFDAU, FMC, ACMS, CDU, APU and DEU. There’s a glossary further down this blog 😊
Yes, that’s a 3.5 inch floppy drive. Yes, it’s from an older aircraft, but the process of applying updates is still manual and time consuming on many aircraft out there on the ramp/apron today
Signing of updates on older systems is rare. Remember, we’re going back up to 20 years since these systems were developed, so the security controls we would expect from today’s embedded systems simply aren’t there. The ARINC 615 protocol is used for high speed updates for data loaders, layered over ARINC 429
Huge steps forward have been made in recent years with software updates. It’s since become possible to update from hard disc, from USB, over the air (whilst on the ground!) in some specific cases. Update security has advanced significantly, but we do need to be aware of the legacy drag for older airframes.
Reflashing components over the avionics network will be a challenge, but it’s one of the objectives that we researching currently.
Later aircraft can accept LSAPs (loadable aircraft software parts) which are generated by a web application and uploaded via a maintenance laptop. LSAPs can update a limited set of areas in the aircraft such as airline-specific checklists.
Later aircraft may have ethernet and/or USB ports for Portable Data Loaders, plus a Portable Maintenance Access Terminal which typically gathers engine/vibration data and allows for updates to EICAS/ECAM checklists etc
We’ve been acquiring and reverse engineering various avionics components for our own interest. Through RE we can better understand how the various components interface with each other.
Our skillset is in embedded systems security (and broader pen testing), so it’s fascinating to look at some of the older chipsets present.
One of my favourite findings at Defcon was discovering an 8085 (Z80 based) chipset inside this 20-year old MCDU. One to run a text based adventure, or perhaps Snake on?
Avionics Data Busses
We will blog separately about the various network busses found on aircraft, as they are one of the keys to security and are incredibly complex. Here’s a basic primer though:
This is by far the most popular avionics data bus on commercial aircraft. Here’s the word format, credit to Wikipedia:
It’s been around for a long time and has some quite special vagaries, including some components on the bus that switch the endianness around!
Fortunately, 429 decoders are built in to the Picoscope. That’s what Alex and I are up to here in the cockpit of an A320, early on in our exploration in to flight surface control protocols, particularly in fly-by-wire aircraft:
We are testing the pinout on the data loader.
There is another loader for the FMC on the pedestal, bottom left
Introduced for the Boeing 777, this was supposed to reduce the wiring requirements, as pretty much the whole plane operated on an inductively coupled network.
In the end, it wasn’t used outside the 777, probably because AFDX was on the way. It is multi-source, multi-sink & full duplex, operating at 2Mbps with Manchester encoding.
The decoders needed to read and inject ARINC 629 are frighteningly expensive for the average researcher.
Here’s one of the inductive couplers from a 777 we were working on:
ARINC 664.7 or AFDX
This is the latest evolution, moving towards a more conventional ethernet based network. AFDX is found in the 787, 350, 380 and a few other planes.
We will discuss this separately, but one of the issues is that it uses ethernet at the MAC layer, which means that off-the-shelf network switches can be used in place of a true AFDX switch.
Obviously the cost of a regular ethernet switch will be way lower than an AFDX certified switch, so there may be an incentive for repair and maintenance orgs to cut corners.
Expect to find familiar transports and protocols in AFDX, such as UCP, TCP, TFTP and SNMP!
AFDX has implications for security, notably as time-to-market & cost may be reduced through using familiar and off-the-shelf components. It also allows conventional, well-known & tested security controls to be implemented. However, it also reduces barriers to entry for security researchers and hackers as the protocols will be much more familiar to them.
Again, to reduce wiring and weight, the overhead panel in several aircraft uses CAN. It’s present in the overhead cockpit panels in the A380 for example.
Power challenges. Don’t die!
Airplanes run 115V AC at 400Hz. Yes, that’s unusual and really quite dangerous to be around when powered up.
We’ve worked on fully functioning airframes (minus engines!) with ground power in place. You do NOT want to be dismantling avionics when powered up, unless extensive safety precautions are in place. Expect to be thrown across a cockpit and/or dead if you accidentally short powered components .
CRTs are still found in some older MCDUs / PFDs together with some almighty capacitors. Take care!
Power is a real issue. Even vacuum cleaners have to be specially designed for airplanes:
You may also find 28V DC on certain systems.
Powering avionics on a bench when testing is also challenging. Expect to pay >$10,000 for a new bench PSU, although used versions come up on eBay from time to time.
That said, if you’re working on the components themselves, powering with 5V may be fine for some chips.
eBay is a good source, but you’ll need to be alert and know exactly what you want. Older, uncertified, untested equipment is available for $500-$2000, ideal for reverse engineering.
For newer equipment, find a friendly boneyard, but be prepared for some odd conversations. Yards work by part number, not ‘have you got any used avionics I can purchase’
I’ve been hunting for a particular Teledyne Quick Access Recorder for some time, so knowing that it’s p/n 224xx00-360/362/364 makes for a much simpler conversation.
Expect to be shocked by the cost of even 10 year old equipment. If it’s certified and still used by airplanes that are still flying it has significant value
We have access to an of end-of-life Airbus A340 airframe coming up soon, so will be spending more time capturing, decoding and attempting to inject 429 payloads.
We will also be investigating ARINC 615 as a route to update certain components with our own code
We don’t expect either of the above to be easy – it may even be impossible. As we’ve said before, you don’t just rock up and hack aircraft
Finally, we’ll be working on more avionics, hopefully of a newer vintage, if we can justify the cost of more current kit!
DFDAU – Digital Flight Data Acquisition Unit
FMC – Flight Management Computer
ACMS – Aircraft Condition Management System
PFD – Primary Flight Display
CDU – Cockpit Display Unit
APU – Auxiliary Power Unit
DEU – Display Electronic Unit
ARINC – Aeronautical Radio, Incorporated
MCDU – Multipurpose/Multifunction Cockpit Display Unit
ADS-B – Automatic Dependent Surveillance – Broadcast
ECAM – Electronic Centralised Aircraft Monitor