Getting a persistent shell on a 747 IFE

TL:DR

• The Coronavirus pandemic has hit the airline industry hard. One sad consequence was early retirement of most of the 747 passenger fleet. This does however create opportunities for aviation security research, as airframes are parked up before parting out in breakers yards.
• This 747 was flying for a large airline until the middle of last year, but hadn’t had its in-flight entertainment system updated since it first flew in 1996. All instances of that IFE have now been retired, so it seems safe to disclose publicly now.
• The attack is local, so you have to be on the plane. Physical airside security controls make this very challenging. That said, the system was in a galley area; so whilst the attack would need only a few seconds of physical access, anyone interfering with plane systems is going to get immediate attention from crew and other passengers. It’s not as if the system has access to the Aircraft Control Domain. At worst, you could offend or scare passengers by streaming unpleasant content to the display screens.
• Pwning it was more of a challenge than we expected, mostly because the IFE was 25 years old and was missing many features we take for granted on more recent systems, but we did succeed. Take a trip down memory lane with us.

Before anyone gets too excited about wild stories of ‘hacking planes’, this IFE isn’t in use any more. It’s also important to note that, as powering the 747 from the APU takes about 400kg per hour of expensive JetA1 fuel, most of this exercise was done on a replica environment in our lab.

Introduction

The pandemic has hit airlines hard. Restricted travel and huge drops in passenger numbers have forced the industry to cut costs. One early measure last year was to retire all passenger Boeing 747s, the workhorse of airline fleets dominating the skies in the 1990s.

With so many planes being retired we were able to finally get physical access to one. My colleague Alex did an excellent video tour of the 747 which highlighted the use of floppy disk for updates.

It also showed Windows NT4 being used to run the in-flight entertainment (IFE) system’s management server.

Plugging into the network was possible via an ethernet port next to the main IFE system. It clearly hadn’t been used in a long time, as there was fluff in it!

The key thing is that the NT4 instance was running Service Pack 3 with the additional Option Pack which upgraded the IIS version to v4.0.

While preparing for a future visit we encountered some frustrations, mainly a lack of familiar testing tools that we could use, due to the age of the OS. This included everyday items such as “whoami”, remote desktops, and scripting engines.

Join me for a trip down memory lane and do some NT4 hacking!

Exploits

At this point we moved to our lab and replicated the NT4 IFE environment on our own systems. This meant we were no longer burning 3-400kg per hour of Jet A1, saving about $250 per hour of research!

There are two exploits chosen for our NT4 lab environment, simply because they are proven to work with IIS v4.0.

Setting up our lab, a quick nmap scan shows that the same version is reported as on the IFE.

As with the IFE our lab gave the same default welcome to IIS4 page:

The first exploit was a directory traversal documented by SANS back in 2000, from a posting to the Paketstorm forum. This exploit relies on a basic directory traversal which allows command injection if the cmd.exe binary is used in conjunction.

The only difficulty here is the Unicode characters. NT4 uses UTF16 as opposed to the modern recommendation of UTF8. UTF16 uses 2 bytes of data in which to encode the character, whereas modern day operating systems can do this in a single byte.

These needed to be converted to ensure that the correct encoding is used. The resulting code to call cmd.exe was:

curl http://<ip>/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+’C:\’

We ran exploit in the lab and attempted to ping our own host:

Success. The ICMP traffic can be seen clearly to have originated from our target host back to our attacking box.

There was a flaw though. With every directory traversal attack the target program is required to be on the same drive as the webserver. In our case we needed the system32 folder to be on the same drive as the IIS install.

Best practice states that a separate drive should be used for webservers, so we would expect the see the webserver on D drive which would render the exploit ineffective.

The second exploit was discovered back in 1999, CVE 1999-1011. It uses a package called Microsoft Data Access Components which allows direct access into the database objects through IIS. The shell() command can then be used to execute remote code.

Running the same test in our lab  confirms that this attack is also a success:

The tcpdump shows that the msadc DLL was called and the ICMP packets can clearly be seen. The great thing about this exploit is, because it uses the backend database, the shell() command can access any drives and isn’t reliant on all binaries being on the same drive. It allows full exploitation regardless of setup.

Finding and running the exploits was the easy part. The next steps are where hacking NT4 gets much more interesting.

Persistence

Remote code execution is excellent, but to really dig into the IFE we needed further access.

As we could stand at the computer, in a cramped cupboard underneath the stairs on the 747 all we needed was the username and password to gain full access.

We could at this point add a new user to the machine, however this is a noisy method and we wanted to avoid leaving a trace as much as possible.

It’s also likely that the same IFE login is used throughout the entire fleet of planes, for ease of the host staff, therefore cracking it once may provide global access to all of the IFE for the airline.

This could also mean access to more modern systems depending on the airlines password policies and how often they are changed.

To start off, we turned to the popular framework Metasploit which has various modules for a large range of exploits, including the msadc exploit. This may provide a meterpreter shell which allows additional tools such as hash dumping. However, when we ran the exploit, it failed for unknown reasons.

Different payloads and various iterations led to similar issues, we could see the exploit was working by creating the payload on the machine, however this then would fail to execute. Even running the binary directly on the machine does not work.

As another method of attempting to get a meterpreter shell, a regular shell was obtained, and the post exploit “shell_to_meterpreter” was used, again this resulted in a failure:

This is where we get into the intricacies of NT4. Usually, the payload would be executed using a Windows internal function called “cscript”. Cscript is used through almost all versions of Windows as a tool that runs scripts, so any Visual Basic, C# or other scripts can be created then run with cscript. However, NT4 doesn’t include cscript, the operating system pre-dates the tool, so running any scripts is seemingly impossible.

There is however a tool that pre-dates cscript which is called wscript. This is the Windows Script Host and was run in parallel on many operating systems, but we found out that this is only installed as an optional extra on NT4 and isn’t there by default. What this means is no scripts can be run, which means using the RCE to create a script or a reverse VBA script isn’t possible.

Due to this, alternative thinking needed to be undertaken.

As we aren’t able to get any sort of reverse shell, attempting to grab the hashes externally seemed sensible. SMB attacks on modern operating systems can allow a hash to be captured using a tool called responder. This tool listening on the network and the net use command will allow an authentication attempt resulting in the user hash.

Running this in the NT4 environment doesn’t provide the expected hash. Instead, nothing is returned:

The reason for this is that the IFE machine is a standalone workstation, and the net use responder attack required Kerberos tickets which are only found on a domain.

Instead NTLM needs to be leveraged, which is the local hashing mechanism for passwords. There are a wide range methods available to capture these hashes, initially using MSSQL access that is available it might be possible to use this to steal the credentials. Metasploit has a module for this which we can try to leverage:

Again, unfortunately although an SMB capture is running, the exploit fails to execute properly.

Downloading hashes

Instead of attempting to capture the hash, we turned to the remote code execution to copy the repair SAM and SYSTEM and make them accessible on the root of the webserver, from there it would be possible to download them. NT4 stores back ups of the SAM and SYSTEM file within C:\system32\repair, if theses two files can be obtained, it is possible to extract the NTLM hash and run it through a password cracking tool.

Using the mdac exploit, it was possible to copy these files across:

These files are now accessible on the Webroot so it was possible to download them, at this point we found that the files were cabinet files, which is a Windows filetype that contains other files, similar to a ZIP file. Extracted the cabinet file provided the raw data, however due to the age of the operating system, the latest tooling for this doesn’t work, the tool samdump2 results in an error:

The latest version of impacket-secretsdump also results in an error:

To try to fix this, an old version of BackTrack was downloaded. BackTrack is the predecessor to Kali Linux, the operating system aimed at pentesters. BackTrack 5 was originally released in 2011 and therefore had some older tools that may be able to deal with the age of the NT formats. However, when attempting to process the data to create them into hashes, a different error was received:

This was due to their being a SYSKEY somewhere within the NT operating system. We weren’t able to find where the key was stored and most of the documentation on the web now returned 404 errors, instead of hunting through web archives we moved onto other avenues of attack.

Gaining access

As we couldn’t use that attack vector, we looked at obtaining an interactive shell for extra access. One toolkit that NT4 does have is TFTP, this is trivial file transfer protocol which can be used without authentication. Hosting a TFTP server and using the remote code execution could allow the copying of files across to the machine.

Metasploit contains a TFTP server module, and a standalone Netcat binary was copied across to the target system.

With that running and the netcat binary in the /tmp/ directory, the remote code execution was used to download that binary.

Setting up a listener on the attacking box and starting the binary provided a shell on the target machine.

Full command line access is now granted, allowing easier searching through the directories, looking at files and exfiltration of data.

A common attack vector from here would be to add a new user to allow physical access, however before doing that let’s see if there are other ways to extract the passwords. There is a program called pwdump which has a number of different versions, each version allows the extraction of hashes from memory for different operating systems. We found that pwdump2 worked with the service pack that we had installed.

It was possible to use the TFTP service to copy the pwdump executable across. In addition to the executable the samdump DLL was required, without this the program hangs indefinitely, without any errors or warning on what is happening.

Running the program is simple enough, the hashes are provided which can be put into a file and either copied across by FTP, TFTP or downloaded from the Webroot.

Once those hashes are on the attacker’s laptop, they can be directly run through a cracking program using the NT format and a bespoke wordlist.

Now that we have the Administrator password, we could log directly into the console and it is possible that password reuse happens around the fleet, so we would potentially be able to gain access to the entire fleets IFE systems.

What ifs?

As we play tested this more, more scenarios were raised by the team of things we might face on the plane. One of the questions was: What if the WebServer was being run by a low privilege user?

The start of the attack would be the same, using the remote code execution via the webserver but running pwdump as a low privilege user doesn’t work, as it doesn’t have the permissions to access the Local Security Authority Subsystem Service (LSASS), instead an error message of “5” is returned which is the code for access denied.

A privilege escalation attack was required to gain access to an administrator level user, luckily there is known exploit called SecHole2. This exploit raises the privilege of the current user up to Administrator:

A check of the administrators group now shows that the WebServer user is an Administrator, However, the permission still hadn’t been provided to run pwdump2:

To resolve this issue the user needs to either log off and log back in, or the machine requires a reboot. If this attack is being done remotely, then a reboot is likely to be the better solution, although if all the IFE on the plane shut off due to this, you would be quickly noticed!

Once that reboot is complete, the user can run pwdump to obtain the hashes.

As with before, these can be extracted and run through a cracking program to get the passwords.

There is an additional privilege escalation technique that was found by Jonas Vestberg as part of a competition we did for NT4, this uses the “GetAdmin.exe” binary which works in a similar way to the SecHole we used but instead of escalating the current user, you can specify the user, either existing or new to the system. A walkthrough video was produced by Jonas.

Quick win

Earlier we discussed an additional method which would work if the webserver was being run by an Administrator and we dismissed it due to it adding a new user to the system. Although it is a noisy method it is very quick and therefore useful for when ground power is very expensive!

The remote code execution exploits run at system level, so any user can be added via this method.

Now that a user with the username Phil and the password planes has been added. The user can then be elevated up to a Local Administrator.

Using this account, an attacker could log directly into the terminal if they can get access without being noticed.

Disclosure

We found these issues back in July 2020. Over the last year we’ve spent significant time talking to the original manufacturer of the IFE and also to Boeing.

This system, to the best of our knowledge and also the manufacturer, is no longer in use. It should be noted that the system is so old that the manufacturer had sold off the entire IFE division to a third party. Even finding anyone who knew about the operation of the IFE was a challenge, given it was developed 30 years ago.

Boeing have also been supportive and helpful, enabling discussions.

Conclusion

NT4 does have many different known exploits and vulnerabilities within the Operating System, however this isn’t unexpected with technology that is 15 years out of date. Should this be a concern for airlines? Not really, the IFE system is a separate system, it has no access to any of the systems in the cockpit so the access gained is minimal.

Sure you could make peoples flight super boring by messing with the in-flight entertainment. The real threat is from reputational damage and bad press, rather than any danger to the plane and passengers.