http://blog.silentsignal.eu/2014/07/28/how-to-got-root-access-on-fireeye-os/
1. Background
A couple of months ago we had the opportunity to take a closer look at a FireEye AX 5400malware analysis appliance. The systems of FireEye are famous for catching targeted attacks that tend to evade traditional security systems, so we were really excited to find out more about the capabilities of this system. However we couldn’t resist taking a look at the management interfaces of the system; these turned out to be at least as exciting as our initial area of interest.
2. Technical part
2.1 Escaping the shell
The FireEye AX 5400 provides management interfaces over HTTPS and SSH. After login, the SSH interface provides a special restricted command shell (similar to the consoles of ordinary network equipment) that allows administrators to configure the device but prevents them interacting with the underlying operating system. Aside from the special shell the service was just an ordinary SSH server that allowed limited use of SCP.
The SCP process could only read and write the home directories and couldn’t create directories. If the user initiated an SSH connection to a remote system, the $HOME/.sshdirectory was created to store the known_hosts file. After this one could upload an SSH public key to log into the system without password, but the default shell of the account was set to the original configuration shell with limited functionality.
How could we escape this shell completely and run arbitrary commands? The answer lies in the slogin command of the SSH console, which was actually an ordinary SSH client that behaved exactly as expected. This SSH client provides configuration options for the users from the $HOME/.ssh/config file. The ProxyCommand option allows operating system command execution if the user initiates an SSH connection:
Proxy Command - Specifies the command to use to connect to the server. The command string extends to the end of the line, and is executed with the user's shell. |
To obtain access to an unlimited command shell, a configuration file was created that added a new user to the shadow file of the system with the home directory of the root user (that contained the previously uploaded SSH public key), 0 UID and an unlimited default shell. The configuration file contained commands similar to the following:
The built-in „slogin” command could trigger this configuration:
The new s2crew user now has an unlimited command shell and can log in with the previously uploaded public key:
2.2 Afterlife
Having successfully demonstrating the issue, we contacted the vendor who responded instantly, acknowledged the vulnerability and notified us on the status of the fix regularly. The official fix was released on 8th July 2014 for FEOS versions older than 7.1.0.
The exploitability of the issue was limited, since attackers would have to authenticate themselves on an administrative interface that should be only exposed to dedicated network segments. Still, this vulnerability gave us a unique insight to the inner workings of the product that inspired us to continue the research of the platform.
