We’ve been testing the security of a number of different electronic flight bag, or EFB, applications for a few years now. Here’s the latest on that now it has been remediated, 19 months after our initial disclosure to Airbus.
TL;DR
- Flysmart+ is a suite of apps for pilot EFBs, helping deliver efficient and safe departure and arrival of flights
- One of the iOS appshad ATS (App Transport Security) intentionally disabled, together with any form of certificate validation, exposing the app to interception attacks over Wi-Fi
- This could enable tampering with, for example, the engine performance calculations, potentially resulting in a tailstrike or runway excursion on departure
- Airline EFBs can be exposed to interception on untrusted networks given pilot layover hotels are well known and used consistently each night
- Airline Standard Operating Procedures (SOP) during cross checks would be unlikely to detect any tampering
- Airbus responded quickly to our disclosure and resolved the issue
NAVBLUE are an Airbus owned IT services company. This post is about their EFB management app called Flysmart+ Manager. This how they describe it:
“Flysmart+ for iPad FS+ Manager is an application developed by NAVBLUE enabling the synchronization and the installation of the Airline’s data into the other available Flysmart+ for iPad Apps.”
“The FS+ Manger App is the center of the Apps Suite.”
We found that the Flysmart+ Manager application had an important security control disabled, meaning that it could communicate with servers using insecure methods. With that control disabled an attacker could potentially modify aircraft performance data or adjust airport information e.g. runway lengths.
The details
The app did not have any ATS protection, it had been disabled. We think this was probably done at some point in the past to suit a particular airline client that was struggling to implement Flysmart+. It affected all users of the app though.
ATS is a security mechanism that forces the application to use HTTPS, preventing unencrypted communications. An attacker could use this weakness to intercept and decrypt potentially sensitive information in transit.
With ATS disabled, insecure communication happens. It makes the app susceptible to interception where an attacker could force a victim to use the unencrypted HTTP protocol while forwarding the data to the real server, encrypted.
An entry in the info.plist file alongside the app allows insecure HTTP loads to any domain. In the code excerpt below NSAllowsArbitraryLoads is included with the value set to true, which disables ATS:
Current Apple guidelines state:
“You must supply a justification during App Store review if you set the key’s value to YES (true), as described in Provide Justification for Exceptions. Use this key with caution because it significantly reduces the security of your app. In most cases, it’s better to upgrade your servers to meet the requirements imposed by ATS, or at least to use a narrower exception.”
This requirement is not enforced on applications which were uploaded before this it was introduced.
The issue allowed us to view the data being downloaded from the NAVBLUE Servers:
A lot of these files were SQLite databases containing information on specific aircraft, as well as take-off performance data (PERF). An example of one database contained the following tables names:
Database tables
Many of these database tables are important to the performance, or weight and balance (see ‘WB’ above) of an aircraft
‘MEL’ refers to the Minimum Equipment List, so which systems are permitted to be inoperative for a flight. Changing this risks in-flight issues. The Gimli Glider incident is an example of a MEL misunderstanding contributing to a flight safety problem.
‘SID’ refers to a Standard Instrument Departure, so how an aircraft safely departs from an airport.
Even something as simple as the choice of units has led to safety problems. Confusion between US gallons, imperial gallons, litres, kilograms and pounds caused the Gimli Glider fuel starvation incident.
Further analysis of the database suggested that integrity checks were being performed locally:
That would allow, for example, tampering with all engine performance calculation data, though the checksum issue is mitigated by the fix to the ATS issue.
Practical attack
The application update cycle is in-line with updates to the Aeronautical Information Regulation and Control (AIRAC) database:
“Aeronautical information is constantly changing: airspace structures and routes are revised, navigation aids change, SIDs and STARs are amended, runway and taxiway information changes. It is essential, for both efficiency and safety, that pilots, dispatchers, air traffic controllers, air traffic flow managers, flight management systems and aeronautical charts all have the same information working from the same information base.
This can only be achieved by adhering to the AIRAC schedule.”
This means that pilots would likely update the application once a month.
Given that airlines typically use the same hotel for pilots who are down route / on a layover, an attacker could target the hotel’s Wi-Fi networks with the goal of modifying aircraft performance data.
It’s quite easy to identify pilots in layover hotels. It’s also fairly easy to identify the airline and therefore the suite of EFB apps they are likely to be using.
Disclosure timeline
28th June 2022: vulnerability report sent to [email protected] using the PGP key, as described on the Airbus ‘contact us’ page here: https://www.airbus.com/en/airbus-contact-us
29th June 2022: receipt acknowledged, tracking reference was provided.
25th July 2022: response from Airbus, confirming that they had replicated the issue. A fix would be provided for the next version of Flysmart+, due by the end of 2022.
We understand that aviation software has to be certified to be safe so were not overly surprised by the expected remediation timeline.
22nd Feb 2023: We contacted the Airbus VDP team to ask if the fix had been pushed in the latest version of Flysmart+, given we were well in to the new year.
26th May 2023: Airbus replied, confirming that the ‘mitigation measure’ had been communicated to customers.
We asked if we could blog about the issue, now that it had been fixed. We referenced successful coordinated disclosure of similar EFB issues with Boeing and Lufthansa Systems.
We finally heard back from Airbus on 24th October, declining to comment on the blog or thank us publicly, but asking for one change, which we were happy to agree to.
We presented our findings at the DEF CON 31 Aerospace Village in August, and also at the Aviation ISAC in Dublin .
Since then, we have asked Airbus several times for further updates and for any words or comment they would like included in this post, but we’ve had no response.
Conclusion
We’ve now worked on disclosures with Boeing, Lufthansa, and Airbus. These experiences have shown how different disclosure in aviation is compared with other industries. The biggest difference is in the timescales, from the initial disclosure, to remediation, to publishing.
Given the challenges of aviation cyber we’re sympathetic to long remediation times. For this reason it’s important to understand the nuances of the industry and avoid hasty public disclosure.
We’re really pleased that the vulnerability was successfully closed which is a win for aviation safety and security.
