Have you ever thought about who is responsible for the EFB security? - Part 2

Have you ever thought about who is responsible for the EFB security? - Part 2

As promised, this is the 2nd part of our EFB security post. In the 1st part of our post on EFB security we have provided an overview of this topic including who is responsible for the EFB security of the device and the application as well as a practical scenario of compromising the integrity of the information in the EFB.

Let’s see another real-life example of an EFB vulnerability below. Just a few introductory information for the scenario:

• NAVBLUE are an Airbus owned IT services company. This example concerns their EFB management app called Flysmart+ Manager.
• Flysmart+ is a suite of apps for EFBs, facilitating the safe departure and arrival of flights.
• One of the iOS appshad ATS (App Transport Security) was intentionally disabled, together with any kind of certificate validation, exposing the app to interception attacks over Wi-Fi.
• 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.

In short:

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. [..]

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. 

                                                                                - via PenTestPartners

You may find more information in this very interesting article: Hacking Electronic Flight Bags. Airbus NAVBLUE Flysmart+ Manager

But what happens when a vulnerability is discovered? Well, a number of things needs to be taken into account when assessing the relevant risks including first and foremost whether or not a vulnerability is exploitable; if exploitable then what is the window of opportunity since the time the vulnerability was discovered and disclosed up to the time that it is patched or generally treated. If both conditions are satisfied then the vulnerability will have to be reported.

As explained in the Part 1 of our post, a representation of the current status when it comes to the security accountability of the Air operator is stemming from the Air operations rules is the following:

But what will change when Part-IS becomes applicable and what it would be its impact when it comes to reporting lines and obligations in the case where such vulnerabilities are discovered? The following scheme aims to provide a high-level representation of this:

We hope you liked this post. Can you think of other practical examples of vulnerabilities when it comes to EFB security? Let us know in the comments below!