Attacking EFB updates

Software

So who actually develops the software installed on Electronic Flight Bags (EFBs)?  The software can originate from a large range of sources:

• System software developers including the OS, drivers, firmware and utility
• The aircraft manufacturer for Installed & Portable EFB devices
• The airline with their own bespoke software
• Large, well known EFB software companies which have large-scale usage
• Small, lesser known EFB software companies
• Miscellaneous applications (including 3^rd party) installed on the EFB by the pilots for personal use

When considering the ‘installed’ EFB then the chances are software will originate from a combination of the aircraft manufacturer, the device manufacturer, and any specifically approved software. These will have gone through various stages of testing and will likely have been developed by a well-known company with an established and proven security methodology/framework for software development.

This is primarily as an installed EFB is considered to be ‘part’ of the aircraft and subject to the same safety and security regime as the aircraft itself.

But what about the ‘portable’ EFBs, many of which are allocated to specific crew members as personal devices? In this case, the variety of software installed is likely to be much greater than the installed EFBs and thus will have a much greater range of possibilities for the origin of installed software. Many airlines which assign their pilots with EFBs that are classed as portable allow their pilots to install 3rd party applications on their devices without approval from the airline (however they will generally be restricted to only installing applications from an approved application store).

It is common for portable EFBs to contain other applications e.g. games and social media applications, as well as publicly available 3rd party tools for pilots e.g. weather apps and unit conversion apps.
Whose responsibility is it to administer these 3rd party applications? In the US, as far as I’m aware the FAA does not have regulatory powers over cyber security of a portable EFB, though does provide guidance. In Europe, EASA (European Union Aviation Safety Agency) document AMC 20-25A states:

…in the cases where it is demonstrated that miscellaneous software applications run in a fully segregated and partitioned way compared to EFB or avionics applications (e.g. on a separate Operating System on a distinct ‘personal’ hard drive partition that is selected at the boot), the administration of these miscellaneous applications can be exercised by the flight crew and not by the EFB administrator.

So in the case of many EFB devices which have drives that cannot be partitioned, the administration of the miscellaneous applications is exercised by the EFB administrator.  As one could imagine, the task of monitoring every device/EFB and all the installed software is not easy, hence Mobile Device Management (MDM) applications are frequently used.  There are a wide variety of MDM software available on the market today and in essence they enable companies to manage devices and users in a consistent and scaleable way.

With the combination of MDM and the security features enabled on most reputable modern tablets used as EFBs (sandboxing applications being one of them), the chances of remotely compromising an EFB to cause it to fail is unlikely albeit not impossible.  However, something that may not be picked up by MDM software is the sharing of sensitive data by unsuspecting users.  In fact, in some airlines this is already a common issue and few of the users (i.e. the pilots) are aware.  This is one item that will always be difficult for MDM to control: the human factor.  Device users won’t all have the same levels of security awareness nor the same technical ability with their devices.

If employees of a business feel pressure to complete a task within a prescribed amount of time but struggle to do so, it isn’t uncommon for them to look for alternative ways of completing the task more efficiently.  In some cases this results in users breaking company policy and sharing data (even if unintended).  Due to the nature and sensitivity of data which is present on EFBs, the security in place needs to take into account users with the least security awareness and technical ability on their EFB devices.  It could even be argued that security awareness training is equally as important as pen testing.

Updates

As with computers at home/work, EFBs require updating from time to time.  There are updates for the operating system itself, system software, and also for applications installed on the EFB.  Updating the software helps to repair security holes that have been discovered, fix or remove computer bugs, and can also enable the addition of new features to EFBs (or remove outdated ones).

This poses a few questions.  Where has the update come from, who approved it and how well has it been tested?  Given the amount of software now available for EFBs, the range of companies involved in EFB software development has expanded significantly since EFBs were first introduced.

As with the origin of application software, updates can originate from:

• System software developers including the OS, drivers, firmware and utility
• The aircraft manufacturer for Installed & Portable EFB devices
• The airline with their own bespoke software
• Large, well known EFB software companies which have large-scale usage
• Small, lesser known EFB software companies
• Miscellaneous applications (including 3^rd party) installed on the EFB by the pilots for personal use

Why is this a concern for aviation and in particular EFBs?  Well, have you ever updated software to find either it or another application on your device no longer works (or no longer works as expected)?  Updates from large software companies are generally very well tested.  However, inevitably there is a limit to how much time can be spent testing compatibility with applications prior to release of the update.  And of course even in large companies, mistakes are made.

On February 11^th 2020, Microsoft released the Windows 10 KB4524244 security update.  The update was designed to ‘address an issue in which third-party Unified Extensible Firmware Interface (UEFI) boot manager might expose UEFI-enabled computers to a security vulnerability.’  Many users reported that the update either failed to install, caused their device to freeze, or caused issues when trying to boot up the operating system – these users were predominantly using HP devices.

It is alarming to consider that Microsoft did not check with HP (one of the largest PC manufacturers in the world) that the update would work with their software.  It took four days before Microsoft finally withdrew the update, in that period a large number of HP users had experienced significant disruption.  Other well-known problematic updates:

• ASUS update which installed a malicious backdoor through its trusted automatic software update tool after attackers compromised the company’s server
• Radeon drivers which having been updated caused certain applications (e.g. Chrome) to black-out or crash

Considering the available range of devices and software for use as EFBs, there is significant potential for updates to cause disruption – and indeed a misconfigured update has already had a significant effect.  In April 2015, American Airlines was forced to ground a significant number of flights due to an issue with their pilots’ EFBs.  An American Airlines spokesperson stated “We experienced technical issues with an application installed on some pilot iPads.  This issue was with the third-party application, not the iPad (itself).”  This resulted in flights being cancelled and a not insignificant number of flights having to return to their gates having taxied to the runway for departure.  Some flights managed to subsequently depart but required printed paper charts.

Jeppesen is the EFB software provider for American Airlines.  According to them, a single chart at the Reagan National Airport was the cause of the issue.  This chart (a single Instrument Landing System chart) was duplicated in American’s database.  This resulted in the app being unable to reconcile the two charts with the same title and index number (one of which was a current chart and a second that was set to become effective the next day).  Mike Pound of Jeppesen stated “It wasn’t a software issue, it wasn’t an app issue; it was an issue of one chart being duplicated in their database.  The app wasn’t able to reconcile the duplication and that caused it to become unresponsive and shut down.”

Application update required

The American Airlines example goes to show how just one misconfigured chart/document/app update can cause widespread disruption to an airline.  Pound stated “This is the first time we’ve ever encountered this problem. The version of the software is unique to American, so no we don’t anticipate anybody else having the issue.”  This is a good thing as other airlines did not experience the same problem.

However, it shows the significance and difficulty of applying updates to software in the modern world and the knock-on effect this can have; just one misconfigured file (whether intentional or not) can render an application (or on occasions a device) useless.  We know most app stores have high levels of security with rigorous checks in place to prevent malware being uploaded, it is therefore likely going to be a difficult task for a hacker to upload something which would instantly cause EFBs to fail.  But could they create software which is designed to function as described – with no malware, but with the ultimate aim of causing an outage of EFBs once a large number of pilots have installed their “useful pilot tool” (or even a timebomb)?

Consider a pilot who has a portable EFB issued by his airline.  Said pilot is instructed for security reasons to ensure all applications installed on the device must be updated prior to the first flight on any given day (which is not uncommon when it comes to EFBs and creates an argument for central management of applications and updates).  He is also given the right to install other applications on his device for personal use.  Could a compromised software update affect the EFB?  The points discussed above suggest the answer is yes.

To prevent this from happening some airlines insist that system software updates are not applied when they become available but instead once all required applications have been checked for compatibility with the new system update.  In some cases this can take several weeks.  It is not inconceivable that a security flaw remains open to misuse for a considerable amount of time whilst different airlines check compatibility with each required EFB application.

There’s some guidance on hardening EFBs here.