Database Integrity Vulnerabilities in Boeing’s Onboard Performance Tool

This post is released in a co-ordinated manner with Boeing.

TL;DR:

Security gaps in older, unprotected Windows desktop versions of Boeing’s Onboard Performance Tool (OPT) could make certain Electronic Flight Bags (EFB) more susceptible to attack. In particular, OPT’s use of plain text configuration files and SQLite databases, means an attacker with physical access to an EFB could modify files directly on the device.

While the likelihood of exploiting such gaps is low given existing regulations governing the use and employment of EFBs and Crew Resource Management procedures, if data modification occurs, and the resulting miscalculations are not detected during the crew’s required cross check or verification process, an aircraft could land on a runway too short or take off at incorrect speeds potentially resulting in a tail strike or runway excursion.

Boeing released OPT version 4.70 and issued a service bulletin to operators to enhance the application’s security features and minimize the potential for manipulating OPT data.  It is important that operators employing EFB solutions, including those that contain OPT, harden their devices and implement physical access controls in accordance with relevant aviation regulations.

OPT Explained

OPT is used by pilots to calculate landing and take-off speeds of certain Boeing aircraft. This is important to avoid running out of runway, optimize braking performance, and correctly calculate V speeds used in take off. You can read about performance calculations in our blog series: https://www.pentestpartners.com/security-blog/efb-tampering-approach-and-landing-performance-part-1/

OPT is deployed to a pilot’s electronic flight bag and receives regular updates to its airport database, typically on the AIRAC cycle. These updates are important because new runways are added, made temporarily unavailable, or obstacles are erected around airports (like cranes).

Details about airfields, their runways, obstacles, and other performance calculation factors (like engine type) are stored in SQLite databases alongside the OPT application. Aircraft operators can take a feed from Boeing directly, or in some cases generate their own databases with custom software.

OPT itself is commonly found on iPad style devices but we have seen OPT in use on ruggedized Windows laptops and tablets as well. Operators significantly increase their own risk by running OPT on non-hardened Windows devices and Boeing does not recommend this configuration. Operating systems that sandbox applications and run with low privileges reduce the potential for exploitability.

Issue 1: Lack of database integrity checks

The SQLite database “airport.sdb” contains information on runway length, slope, NOTAMs and other information on airfields. This database is opened by OPT when selecting the “ARPT” option and is used to show the runway length available for landing and in diagrammatic form for take-off.

The database can be manipulated here showing 27L with a length of 9999m, but more subtle changes (such as transposed numbers) could be overlooked by pilots.

The resulting modifications are then displayed by OPT:

Before:

After:

Ancillary SQLite databases are produced for different aircraft type and engine combinations. Here for example is one for the 747-400 with Pratt and Whitney engines.

This database contains, amongst other things, data relating to configuration deviation lists (CDL). The CDL is used to manage acceptable defects on the aircraft and produce offsets in the V speeds (for example if a piece was missing that increased drag, the take off speed may need to be higher). A successful attack therefore has to wait for a maintenance condition to occur that causes the pilot to select a CDL option, however it is less likely that this modification would be detected by a pilot.

Columns for V speed modifications:

Before:

After:

Incorrect selection of V speeds could lead to rotation at an inappropriate speed leading to potential for tail strike or poor climb out performance.

The database also includes columns for manipulating thrust values for CDL & MEL (minimum equipment list) entries. Although it is not clear if practical in this case, changes to the SEL TEMP (or FLEX) could significantly impact engine lifetime if undetected.

Issue 2: Plaintext configuration files

The 747-400.cfg file is a simple plain text configuration file which drives many aspects of the OPT interface including setting sanity checks around maximum wind speeds, aircraft altimeter settings, as well as the user interface.

As an example, the button for “NOTAMS” was changed to “PTPAMS” but could easily have hidden the yellow flag on the CDL button compounding previous issues.

Conclusion

An attacker with physical access to EFBs, for example cleaning or maintenance crews, or if the EFB is removed and left in a hotel room (“evil maid” attack), may have the ability to modify data which could have potential flight impacts.

Simple checksums or hashes stored alongside these databases would likely be insufficient to mitigate this attack, as an attacker could simply generate their own.

Operators are required to keep in place physical access restrictions and it is accepted that EFB hardening is the responsibility of operators. FAA guidance on the operational authorisation to use an EFB onboard aircraft is available at AC 120-76D and EASA have issued AMC 20-25 [PDF].

Exploitability

This issue requires files to be overwritten on the EFB. If the EFB were an iPad type device (which many are) then exploitation would be difficult by a remote attacker targeting a specific device due to the sandboxing in place around the application itself. If operators lock down devices using an MDM and disable USB access, this also makes physical tampering more difficult. Installed EFBs, historically referred to as Class 3 EFBs, are also protected physically and through airplane network segregation, making exploitation much more difficult.

Calculations should also be made by both pilots, so targeting a single device would make errors visible.

Where EFBs are traditional Windows devices, the opportunity for physical tampering or malware to change files is much higher. In one case PTP have seen two EFBs in a flight deck networked together so captain and first officer can share data. This means an attacker could modify both sets of data, making it less likely for a discrepancy to be noticed.

Although an attacker with opportunity could modify the values in OPT, there are several security and safety measure in place that should prevent a successful attack from happening. Regulatory guidance also states that EFBs are considered to have no, or minor, safety impacts. If two EFBs give different values, flight crews should perform cross checks using the FMS and other charting applications. Operator procedures rarely require independent calculations and usually only a cross check of data inputs.

Tampering with data sources upstream, at suppliers or operators, has the potential to impact entire fleets. Although much harder to achieve, these changes would not be visible as they affect all devices at once. Systems that generate and distribute performance databases should be treated as critical to flight safety and protected accordingly.

Remediation

Boeing released OPT version 4.70 and issued a service bulletin to operators to reduce the potential for manipulating OPT data as part of its defense-in-depth approach to airplane safety and security.  It is also important that operators employing third-party EFBs take steps to harden their systems and prevent unauthorized access to EFB software, and adhere to applicable regulations (including Mobile Device Management (MDM) programs as outlined in AC 120-76B and associated international standards).

Disclosure timeline

The issue was disclosed to Boeing via their Vulnerability Disclosure Program (VDP) in September 2020. Boeing kept PTP regularly informed by email and voice conferences to discuss the issues, possible mitigations, and remediation progress. Boeing were a joy to work with during this time.

Other researchers should be aware that addressing vulnerabilities in aerospace systems is non-trivial and extended remediation times are normal and should be expected. The priority for all concerned is flight safety.

Collaboration statement

Boeing would like to thank Pen Test Partners for their research, professionalism and collaboration. Boeing welcomes future engagement by PTP and other security researchers, and is committed to evaluating any original findings when disclosures are conducted and shared in a responsible and coordinated manner. Boeing encourages security researchers or others in the community who have identified security issues to utilize Boeing’s VDP: https://www.boeing.com/principles/ethics-and-compliance.page#/vulnerability-disclosure