Airbus Navblue Flysmart LPC-NG issues

LPC-NG or Less Paper Cockpit – Next Generation is an electronic flight bag (EFB) application offered by Navblue, a part of Airbus. It’s used for calculating engine thrust requirements (perf) on takeoff and braking action on landing, among many features that help make flight safer and more efficient.

Software tested was Airbus FlySmart LPC-NG L5.2.3 for Windows, Electronic Flight Bag  version 17.03.

TL;DR

• The data files used to calculate perf and braking action were plain text, without any form of integrity check.
• This means that an attacker could modify files directly on EFBs, or by intercepting the supply chain of updates.
• This would allow takeoff performance and landing roll calculations to be tampered with, raising potential of runway excursions and or tailstrikes.
• The attack requires local access to the EFB. This significantly mitigates the risk, unlike this flaw in another Airbus EFB app which could be carried out over Wi-Fi.
• However, EFB lockdowns by operators (airlines) are very variable, meaning that an attack could be carried out with only a few seconds of access, perhaps in a layover hotel.
• Airbus refused to fix the issue, framing any such fix as a product improvement. This is at odds with similar vulnerabilities found in a Lufthansa Systems and Boeing EFB app, both of which were responsibly fixed.
• Airbus suggested that the responsibility sat solely with operators, to harden their EFBs
• We believe that the bug found results in the EFB app failing compliance with the relevant EASA safety regulation for electronic flight bags, AMC 20-25/A.
• Finally, 3 years after reporting the vulnerability and arguing with Airbus, it was suggested to us by aviation industry friends that we try the regulator, EASA. The EASA agreed with us and approached Airbus on our behalf.
• The vulnerability was fixed less than two weeks after EASA got involved.

Takeoff Performance

Files can be modified resulting in incorrect takeoff performance data being produced by the application. Examples of modifications possible (but not limited to) include:

• Runway data e.g. TORA (Takeoff Run Available) / TODA / ASDA, slope, entry angle
• Obstacle position and height
• Factors applied to acceleration profiles (effect of runway degradation, engine anti-ice etc.)
• Application of Minimum Equipment List (MEL) / Configuration Deviation List (CDL) factors

A runway overrun becomes possible with these modifications as does Controlled Flight Into Terrain (CFIT) due to inability to outclimb obstacles or terrain as a result of insufficient thrust. Changes which affect V speeds may be highlighted when pilots compare the calculation with FMGC calculated V speeds. Changes which don’t affect V speeds but instead affect the stop margin or climb performance would not be highlighted by comparison with the FMGC Takeoff Performance page.

Whilst modifications of runway information may be detected by pilots if they compare the TORA / TODA / ASDA to their charts, the modification of obstacles would be unlikely to be noticed. Additionally the changing of acceleration profiles, runway degradation (slush / snow etc) effect on performance, or any other factor which is applied “behind the scenes” are all more difficult to notice. The following example has the potential to result in a runway overrun on takeoff.

Example: Runway length and obstacle modification

Runway and obstacle data can be modified. TORA, TODA, ASDA, and other details can easily be changed. These may or may not be noticed by pilots on the day. Obstacle height and distance can also be changed, these are less likely to be noticed as they do not display automatically.

London Heathrow Runway 27L correct data with obstacles:

Obstacles prior to being deleted:

File path: /fwdir/bs/Database/jar0/hsqldb/data/

Runway distances change from 3658.0m to 4658.0m

Modified London Heathrow data – no obstacles and runway lengths changed:

Calculated takeoff performance based on correct data:

Calculation using identical data entries in the application for the same conditions (weather / aircraft weight etc.) with modified runway and obstacle data (CONF 2 selected to match perf above):

The stopping margin using the correct data with a FLEX of 42.0 is 38m. The modified stopping margin at 42.0 becomes 1649m. In this scenario, pilots would likely choose the best FLEX TEMP possible hence would opt for 45.0. Based on the figures above this would result in a runway overrun of 666m in the event of a rejected takeoff from V1.

In the event the takeoff was not rejected then based on the figures above the aircraft would not reach VR until after the end of the runway: 4658m –983m (V1 STP MRG) = 3675m required to reach V1, plus distance to VR. Correct runway distance = 3658m.

Landing performance

As with the Takeoff Performance case, for Landing Performance files can be modified resulting in incorrect landing distances being calculated.

Examples of modifications possible (but not limited to) include:

• Runway data (LDA, slope)
• CDL / MEL effect on Vapp
• Factors applied to deceleration profiles (effect of runway degradation, autobrake settings etc.)

Whilst some modifications would be visible to the pilots (e.g. changing the landing distance factor or the runway length), other changes such as the effect of runway contamination would not be visible.

A runway overrun becomes possible with these modifications, as does a ground collision in the event the aircraft is landing on a Land And Hold Short runway.

Example: Changing effect of Braking Action

The following example simulates a warm summers afternoon at TNCM (St Martin / Princes Juliana Airport), a heavy shower having passed through has resulted in medium braking action on the runway.

Braking action “Medium” is switched with “Good”. When “Medium” is selected as the Braking Action in the application, the calculation is based on “Good” instead.

File path: /fwdir/bs/cmnlsp-data/jar0/engineLS/perfo/

Original calculation (correct) showing that the landing distance is greater than the LDA:

Using identical entries (weather / aircraft conditions etc.) in the application, the following was the calculation after the changes made above:

The calculated landing distance is 1878m, 338m shorter than when calculated correctly.

Conclusion and recommendations

Physical access to EFBs, for example cleaning or maintenance crews, or if the EFB is removed and left in a hotel room (hotel staff etc.) would likely enable an attacker to modify important data which potentially has flight safety impacts.

It is accepted that in reality EFB hardening is the responsibility of other vendors and that flight crews may perform cross checks using the FMGC or other EFB applications. However, reliance on cross checks could be perceived as bad practice and there are many scenarios in which cross checks don’t apply.

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

There are two potential options in managing the integrity of data in this way:

1) PKI – this would use a chain of trust and public / private keypairs to sign data. The LPC-NG application would have to store a root certificate and not depend on the Windows root store, and potentially incorporate pinning checks.

2) HMAC – a message authentication code is generated using a shared secret key and hash. This would require thought as to how this shared secret key is stored within the LPC-NG binary however.

Solving this problem is difficult – an attacker might potentially be able to replace the root certificate read in for [1] however this shifts the problem to being an attack against that single endpoint only. If a HMAC’s secret key were to be compromised this affects all endpoints.

A challenging disclosure process

Summary

Airbus refused to fix the database integrity issue we discovered. It was declared that a fix would be a product improvement.

This is despite an integrity check being a required component of the relevant EASA regulation.

This is at odds with both Lufthansa Systems who have a cryptographic integrity check on their EFB apps, but had a weak key that was fixed as a result of our report.

Also at odds with the Boeing OPT EFB performance package which had no integrity check, but was also fixed once we reported it.

Instead of addressing the issue, Airbus argued that it was the responsibility of their customer airlines (‘operators’).

You decide…

Disclosure timeline

14/4/21 we send our findings to the Airbus VDP contact email address

6/5/21 we receive a holding response from the Airbus VDP

11/5/21 we receive this response from Airbus VDP. We’ve removed unnecessary content from the below email exchanges for brevity:

“The report has been analyzed through the Safety, and Security Management System put in place by NAVBLUE. This process consists of analyzing and assessing all the coming reports through a safety and security standpoint, and we are pleased to share with you the output of this analysis.

First of all, National Aviation Authorities require Air Operators to identify hazards related to EFB and mitigations through a standard risk management process. AIRBUS and NAVBLUE provide within its “Flysmart+ User and Compliance Manual” a generic risk assessment to support Airlines in this Risk management process. The latter should be used as a basis by the Air Operators to develop their own risk assessment for the use of the Flysmart application based on its operational specifics and mitigation means.

Second of all, the case you reported to us is already listed as a threat in this generic risk assessment and a mitigation strategy is proposed to the Air Operators. We want to mention that the Air Operator remains responsible for implementing and validating the mitigation means under its National Aviation Authority oversight. Even if this threat was already known and mitigated, we would like to thank you again for the effort you put into this technical analysis.”

25/5/21 we challenged this response, referencing the EASA ‘additional means of compliance’ documents that apply to EFBs; AMC 20-25/A

“The EASA report you referenced in your response 11/05/2021 are the “EASA requirements and recommendations applicable to operators seeking Operational Approval to use the FlySmart with Airbus for Windows applications”. It has to be noted that operators may decide to use additional applications, databases on their EFB, similar compliance dossiers are to be established to support the overall EFB operational approval.

As stated in the EASA report in § 1.1, Compliance EFB to the AMC is to be demonstrated by operators towards their national authorities. In that respect, Operators are generally supported by the EFB or EFB application vendors to establish the overall compliance dossier. The EASA report on “flysmart+ for windows” should be understood as a support from NAVBLUE/Airbus to EFB overall compliance to AMC 20.25. As quoted in §1.2, the “report assumes that the parts not covered by this report regarding the evaluation of the compliance of the EFB will be performed by the operator and evaluated by its competent authority. Chapter 6 summarises which parts are covered by this report and which are not”. Typically for security aspects, the full showing of compliance to the AMC 20.25 for security is to be complemented by additional measures.

Generally an EFB operational approval is not solely granted through the EFB and its application compliance to AMC 20.25, it encompasses other aspects such as human factors interface, crew training and procedures,… that are required to be in place and demonstrated by operators.

With regards to the integrity – this part is addressed in §5.8 / §5.10 of the EASA report for FlySmart with Airbus for Windows applications. It clearly identifies the role and responsibility of the EFB administrator (the operator). Your reading of the situation is correct and is supported by the EASA report chapter 6 figure, the EASA report for FlySmart with Airbus for Windows applications is an evaluation that contributes but does not constitute the full compliance of an EFB and its application to EASA AMC20-25A.”

This response is totally wrong in our opinion: responsibility for integrity of the application database can only sit with Airbus. It can’t be delegated to the operator, as they didn’t write, provide or support the software!

18/6/21 we had a call with Airbus

We had a call with a member of the Airbus VDP team and someone from the Navblue product team. I’m sad I didn’t record the call as it was quite eventful. A colleague who was also on the call debriefed with me after, to ensure we had heard the same responses from Airbus.

Short version: Airbus deemed it as a product improvement, not a security issue.

Longer version: the product team representative stated that a cross check would highlight the problem, as the calculation would be done on two EFBs concurrently. This simply isn’t the case and shows a lack of understanding of many operators standard operating procedures by the Navblue team.

Indeed, the MEL allows many planes to be flown with only one EFB!

We got the feeling that the person from the Airbus VDP team was on our side. They understood our concerns and we got the feeling that they felt the bug should be fixed. However, the representative from the product team just argued with us, trying to find reasons why the vulnerability shouldn’t be remediated.

This felt quite familiar from our work in the ICS environment in previous years! Product people are sometimes resistant to challenge from external parties. There is sometimes a focus on safety at the expense of security, which can lead to safety consequences, ironically.

23/6/21 from Airbus VDP

“Thanks for the call Friday 18.06.2021 and the interesting exchange around the subject.

On this occasion we would like to remind that PTP’s (LPC-NG) report is limited to technical aspects of the Flysmart+ application but is not analysing an end to end threat scenarios including an EFB compromise in its operational environment. Particularly the report does not evaluate all the mitigating measures in place within different capacity, either operational, safety or security as required by AMC 20-25A and others.

To shed some light on a few aspects, not exhaustive, additional conditions that would be needed for successful exploitation in threat scenarios:

– Compromise of the EFB protection measures required by AMC 20-25A to successfully access the hosted applications

– Non respect of the Airbus Standard operating procedures where the use of 2 different EFBs is required for performance calculations.

– Coherent corruption / compromise of 2 EFBs is required.

– In the case of pilot attached EFBs, the threat scenarios would also require having knowledge of the crew scheduling (pairing, rostering, assignment…).

– For persistence it is required to have repetitive compromises as EFB databases are regularly updated.

We are glad and thankful for all the inputs and proposed corrective technical solutions by PTP, nonetheless AIRBUS considers it, given the rationales above, as product improvement.

We concur with the statement from PTP that there is no “One size fits for all solution” as it depends on the variety factors e.g. device use, airline policies therefore AIRBUS will evaluate the benefit of implementing PTP recommendations at the opportunity of product updates / upgrades or a new products. The next release date is not yet frozen.

As per our exchange, PTP indicated having already contacted the UK CAA and the FAA. To get everyone’s view, AIRBUS is interested in being provided with the answers from those 2 regulators. Contact names are also of interest if a discussion is deemed necessary.”

Our notes

EASA AMC 20-25 and its later version AMC 20-25A are important here.

Here’s an extract from, AMC20-25 Appendix F section 1.1

“To protect against intentional and unintentional modifications, the database files related to performance and mass & balance (performance database, airport database, etc.) integrity should be checked by the program before performing calculation. This check can be run once at the start-up of the application.”

This looks very much like a requirement for a data integrity check, which is exactly what we found was missing. We passed this back to Airbus, given it was part of the EASA regulation, and received this reply:

31/5/22 email from Airbus VDP

The point you raised to Airbus has been evaluated and we consider it as a product improvement.

23/6/22 email to Airbus VDP from us

“I’m afraid that we strongly disagree with the assessment that the security vulnerability is a product improvement. We also disagree with your points about mitigation, as they don’t take account of real-world operations. Even putting aside all other points, the response from Airbus indicates a lack of a ‘defence in depth’ approach, which should underpin the cyber security of all products and services.

At this point I believe there are the following options:

1: Airbus acknowledge the vulnerability and provide a timeline for remediation. This matter is then closed

2: Airbus continue to treat the vulnerability as a product improvement. We will therefore approach various regulators to ask for their opinion on this matter.

Further, we have found similar security issues in two other EFB vendors apps. When approached by us, they acknowledged the security issues and provided a remediation plan. The response from Airbus is notably different.”

7/5/22 email from Airbus VDP

“The message conveyed might be misinterpreted at your side.

Overall just fixing this technical vulnerability that has been brought to our attention, we are really grateful for, is not enough and does not scale with AIRBUS expectations to address current and (future) security issues as well as future regulation.

Instead of fixing one technical security issue, the decision has been made to improve the whole platform, particularly to anticipate upcoming regulation and have more room to address confidentiality, integrity and availability aspects beyond average responses that researchers are about to deal with. We apologize if we have not been clear enough on that.

The answer of AIRBUS is reasonably different, because we cannot address solely today’s security issues – therefore the answer was not only meant to acknowledge your report and the vulnerability, it was also a clear statement towards 2022 to encompass PTPs recommendations, future regulation as well as overall security improvements.

Once we know the exact release date in 2022 we will revert to you, and even if PTP is not a customer of AIRBUS products, we would be delighted if PTP would accept being notified about the release in 2022. Moreover, talking to regulators, for the security of the aeronautical environment is important, even more if people with the right competence approach them, therefore we recommend acquiring their opinion in regard and regardless of this exchange and the vulnerability report.

We are more on the same page then you might have expected when AIRBUS answer was read the first time, nonetheless the reasons in not being as fast in fixing this individual vulnerability as you may expect, simply results in the fact that there is difference in perception when it comes to the timeline in addressing the issue brought to our attention by PTP.

This will be AIRBUS position in front of authorities and its customers.”

Finally the bug is fixed

At this point, we gave up. We had no further relevant discussions with Airbus on the subject of LPC-NG.

We tried several times to illicit a response from Airbus subsequently, as we felt that the above exchanges did not reflect well on the organisation. We also felt that the exchanges did not represent the wider position of Airbus in relation to their approach to cyber security.

Finally, we approached EASA, the European aviation safety regulator. We asked them what they thought of our finding. They said they would speak to Airbus on our behalf.

The vulnerability / product improvement was then swiftly addressed.

Security is everyone’s responsibility in the supply chain. It is important for software vendors, OEMs, operators and more to ensure they all play their part in removing vulnerabilities. One cannot and should not rely on another control completely mitigating a vulnerability.

Wrapping up with Swiss cheese

In aviation safety we often talk about the holes in a Swiss cheese that need to line up in order for a safety incident to occur.

This finding is one such hole. It is very unlikely to lead by to an incident by itself, but combined with a couple of other holes, a safety incident could occur.