Critical Remote Root Zero-Day In FireEye Appliances


So FireEye doesn’t have a particularly good reputation in the security community, it’s generally not handled responsible disclosure well and it’s even taken a security firm (ERNW) to court over a vulnerability disclosure.

And now there’s another critical remote root zero-day in FireEye appliances – which is scary, as these are high end devices protecting large corporations and governments from zero-days and they don’t even harden their own devices properly?

Critical Remote Root Zero-Day In FireEye Appliances

FireEye ended up making some defensive post about the whole matter here – Bug Bounties, (Non) Lawsuits and Working with the Research Community and it does seems they are at least making an effort. But maybe that’s just because it’s Google this time and not some small security company they can push around.

Simply just sending an email or getting a user to click on a link was enough to exploit a critical remote code execution vulnerability in FireEye appliances and compromise networks protected by the security products.

The flaw was identified earlier this month by Google Project Zero researchers Tavis Ormandy and Natalie Silvanovich. The issue affected FireEye’s Network Security (NX), Email Security (EX), Malware Analysis (AX), and File Content Security (FX) products and it was permanently patched by the vendor within two days with the release of security content version 427.334. Temporary mitigations were rolled out by the company within hours.

The vulnerability, dubbed “666” because of its ID in the Project Zero issue tracker, plagued a module designed to analyze Java Archive (JAR) files. An attacker simply needed to send a specially crafted JAR file across a network protected by FireEye appliances. If the malicious file pretended to use string obfuscation, it would get executed by the FireEye product, Ormandy said in a blog post.

An attacker could have exploited the vulnerability by sending an email containing such a JAR file to the targeted organization — it’s worth noting that the email would not have to be read for the malicious code to get executed — or by getting a user to click on a link pointing to a crafted JAR file.


The vulnerability itself is pretty interesting, and just shows how poorly segmented the malware being scanned is from the actual device OS itself (No VM? No Sandbox? Come on..).

You can trick the ‘security’ appliance into executing a JAR file just by pretending to use string obfuscation – boom it’s owned. And apparently there’s a linked privelege escalation vulnerability too, which gives you complete control of the box.

The post about the vuln in detail is here: FireEye Exploitation: Project Zero’s Vulnerability of the Beast

FireEye appliances are installed on the internal network and they passively monitor traffic. The products monitor FTP, HTTP, SMTP and other traffic and when a file transfer is detected, the file is automatically extracted and scanned for malware. This made it possible for the RCE vulnerability found by Google researchers to be exploited without user interaction.

Project Zero researchers also discovered a privilege escalation vulnerability that could have been exploited to obtain root access to a FireEye device. However, the details of this security hole have not been disclosed because the vendor has yet to release a permanent fix.

A malicious actor could have used these two vulnerabilities to load a persistent rootkit on the affected appliance, intercept traffic, steal sensitive information, insert backdoors, and move laterally across a network.

“Because FireEye devices typically have a secondary internet-connected interface for updates and management, the issue could even be wormable across the internet,” Ormandy explained.

“We are thankful for the opportunity to support the Google team in this process, will continue to support their efforts, and fully support the broader security research community’s efforts to test and improve our products,” FireEye representatives told SecurityWeek last week after the existence of the vulnerability came to light.

The flaws have already been patched by FireEye (they took quick action this time, and not of the legal kind) – but the effectiveness of the patch is totally dependent on everyone using the device applying the update.

Now they are extending an offer to update devices that are out of their service contract, which is nice. But my question generally is, will people even know there’s a serious vulnerability in their appliance?

We shall have to wait and see if this causes any actual mess.

Source: SecurityWeek

Posted in: Countermeasures, Exploits/Vulnerabilities

, ,


Latest Posts:


LibInjection - Detect SQL Injection (SQLi) and Cross-Site Scripting (XSS) LibInjection – Detect SQL Injection (SQLi) and Cross-Site Scripting (XSS)
LibInjection is a C library to Detect SQL Injection (SQLi) and Cross-Site Scripting (XSS) through lexical analysis of real-world Attacks.
Grype - Vulnerability Scanner For Container Images & Filesystems Grype – Vulnerability Scanner For Container Images & Filesystems
Grype is a vulnerability scanner for container images and filesystems with an easy to install binary that supports the packages for most major *nix based OS.
APT-Hunter - Threat Hunting Tool via Windows Event Log APT-Hunter – Threat Hunting Tool via Windows Event Log
APT-Hunter is a threat hunting tool for windows event logs made from the perspective of the purple team mindset to provide detection for APT movements hidden in the sea of windows event logs.
GitLab Watchman - Audit Gitlab For Sensitive Data & Credentials GitLab Watchman – Audit Gitlab For Sensitive Data & Credentials
GitLab Watchman is an app that uses the GitLab API to audit GitLab for sensitive data and credentials exposed internally, this includes code, commits, wikis etc
GKE Auditor - Detect Google Kubernetes Engine Misconfigurations GKE Auditor – Detect Google Kubernetes Engine Misconfigurations
GKE Auditor is a Java-based tool to detect Google Kubernetes Engine misconfigurations, it aims to help security & dev teams streamline the configuration process
zANTI - Android Wireless Hacking Tool Free Download zANTI – Android Wireless Hacking Tool Free Download
zANTI is an Android Wireless Hacking Tool that functions as a mobile penetration testing toolkit that lets you assess the risk level of a network using mobile.


2 Responses to Critical Remote Root Zero-Day In FireEye Appliances

  1. Dave Bacher December 17, 2015 at 7:34 am #

    Are you sure that when they say “executes code in the jar,” that they’re not just talking about a standard buffer overrun while deobfuscating the strings?

    Because that seems a lot more likely than shelling and running Java against a random JAR file. That doesn’t change much of the story, but it does make it more understandable why they might not have thought to sandbox it.

    • Darknet December 17, 2015 at 4:58 pm #

      I don’t think it’s a buffer overrun, I think the processing engine mistakenly (JODE in this case) executes the JAR file whilst trying to de-obfuscate the string. That’s what I understood from it anyway. In their words:

      This SimpleRuntimeEnvironment class is used by JODE to deobfuscate strings by dynamically executing some of the bytecode. This code in particular attempts to handle method invocation in static constructors.