Insecurity Appliance | TechSNAP 245

Insecurity Appliance | TechSNAP 245

Meet BOOTTRASH the Malware that executes before your OS does, the hard questions you need to ask when buying a security appliance, Project Zero finds flaws in Fireeye hardware.

Plus some great audience questions, a big round up & much, much more!

Thanks to:




Direct Download:

HD Video | Mobile Video | MP3 Audio | OGG Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feed | Torrent Feed

Become a supporter on Patreon:


— Show Notes: —

BOOTRASH malware executes before your OS does

  • “Researchers at FireEye spotted the financial threat group FIN1 targeting payment card data using sophisticated malware dubbed “BOOTRASH” that executes before the operating system boots.”
  • The malware only works against MBR formatted disks, if it detects GPT it just exists
  • It backs up the original VBR (Volume Boot Record, the boot code at the start of the partition, which is calls from the boot code installed in the MBR) to a different location on the disk
  • It finds some free space between partitions or at the end of the disk, and uses that to create its own tiny virtual file system, to store the actual malware files
  • Additional files and resources are encoded into a registry hive, so they do not leave any files on the regular file system. Only the invisible virtual file system (not listed in the partition table, hiding in unused space), and some random strings on encoded binary in the registry
  • “As previously discussed, during a normal boot process the MBR loads the VBR, which loads the operating system code. However, during the hijacked boot process, the compromised system’s MBR will attempt to load the boot partition’s VBR, which has been overwritten with the malicious BOOTRASH bootstrap code. This code loads the Nemesis bootkit components from the custom virtual file system. The bootkit then passes control to the original boot sector, which was saved to a different location on disk during the installation process. From this point the boot process continues with the loading and executing of the operating system software.”
  • “The bootkit intercepts several system interrupts to assist with the injection of the primary Nemesis components during the boot process. The bootkit hijacks the BIOS interrupt responsible for miscellaneous system services and patches the associated Interrupt Vector Table entry so it can intercept memory queries once the operating system loader gains control. The bootkit then passes control to the original VBR to allow the boot process to continue. While the operating system is being loaded, the bootkit also intercepts the interrupt and scans the operating system loader memory for a specific instruction that transfers the CPU from real mode to protected mode. This allows the bootkit to patch the Interrupt Descriptor Table each time the CPU changes from real mode to protected mode. This patch involves a modified interrupt handler that redirects control to the bootkit every time a specific address is executed. This is what allows the bootkit to detect and intercept specific points of the operating system loader execution and inject Nemesis components as part of the normal kernel loading.”
  • So it dynamically replaces bits of kernel code with its own code, making it a very hard to detect rootkit, since it is actually injected before the kernel is loaded (hence the name, bootkit)
  • Researcher Blog

“A decisionmaker’s guide to buying security appliances and gateways”

  • “With the prevalence of targeted “APT-style” attacks and the business risks of data breaches reaching the board level, the market for “security appliances” is as hot as it has ever been. Many organisations feel the need to beef up their security – and vendors of security appliances offer a plethora of content-inspection / email-security / anti-APT appliances, along with glossy marketing brochures full of impressive-sounding claims.”
  • This article provides a bit of a guide to help you shop for an appliance that might actually be worth the number of zeros on the price tag
  • “Most security appliances are Linux-based, and use a rather large number of open-source libraries to parse the untrusted data stream which they are inspecting. These libraries, along with the proprietary code by the vendor, form the “attack surface” of the appliance, e.g. the code that is exposed to an outside attacker looking to attack the appliance. All security appliances require a privileged position on the network – a position where all or most incoming and outgoing traffic can be seen. This means that vulnerabilities within security appliances give an attacker a particularly privileged position – and implies that the security of the appliance itself is rather important.”
  • Five questions to ask the vendor of a security appliance
    • What third-party libraries interact directly with the incoming data, and what are the processes to react to security issues published in these libraries?
    • Are all these third-party libraries sandboxed in a sandbox that is recognized as industry-standard? The sandbox Google uses in Chrome and Adobe uses in Acrobat Reader is open-source and has undergone a lot of scrutiny, so have the isolation features of KVM and qemu. Are any third-party libraries running outside of a sandbox or an internal virtualization environment? If so, why, and what is the timeline to address this?
    • How much of the proprietary code which directly interacts with the incoming data runs outside of a sandbox? To what extent has this code been security-reviewed?
    • Is the vendor willing to provide a hard disk image for a basic assessment by a third-party security consultancy? Misconfigured permissions that allow privilege escalation happen all-too often, so basic permissions lockdown should have happened on the appliance.
    • In the case of a breach in your company, what is the process through which your forensics team can acquire memory images and hard disk images from the appliance?
  • Not to mention, in the case of a breach at the vendor, what information could the attacker get about your appliance, your network, or your security? How are the trusted keys protected on the vendor’s network?
    • Bonus Question: Does the vendor publish hashes of the packages they install on the appliance so in case of a forensic investigation it is easy to verify that the attacker has not replaced some?
  • “A vendor that takes their product quality (and hence your data security) seriously will be able to answer these questions, and will be able to confidently state that all third-party parsers and a large fraction of their proprietary code runs sandboxed or virtualized, and that the configuration of the machine has been reasonably locked down – and will be willing to provide evidence for this (for example a disk image or virtual appliance along with permission to inspect).”
  • All of these are very good questions, and I happen to know one vendor who answered these questions in their recent BSDNow interview.

Project Zero finds flaws in FireEye security appliance

  • “FireEye sell security appliances to enterprise and government customers. FireEye’s flagship products are monitoring devices designed to be installed at egress points of large networks”
  • The device is connected to a SPAN, MONITOR, or MIRROR port. A feature of high end switches that allows all traffic from a port or set of ports to be copied to another port
  • “The FireEye device then watches all network traffic passively, monitoring common protocols like HTTP, FTP, SMTP, etc, for any transferred files. If a file transfer is detected (for example, an email attachment or a HTTP download) the FireEye extracts the file and scans it for malware.”
  • If the device detects malware, it alerts the security team
  • The device can also be configured in a IPS (Intrusion Prevention System) mode, where it would block such traffic
  • “For networks with deployed FireEye devices, a vulnerability that can be exploited via the passive monitoring interface would be a nightmare scenario. This would mean an attacker would only have to send an email to a user to gain access to a persistent network tap – the recipient wouldn’t even have to read the email, just receiving it would be enough”
  • If you compromise one of these devices, you are basically sitting on a wiretap of the entire network. These devices are sometimes even installed behind devices that decrypt encrypted traffic, giving you even more access
  • “A network tap is one of the most privileged machines on the network, with access to employee’s email, passwords, downloads, browsing history, confidential attachments, everything. In some deployment configurations an attacker could tamper with traffic, inserting backdoors or worse. Because FireEye devices typically have a secondary internet-connected interface for updates and management, the issue could even be wormable across the internet.”
  • “FireEye have issued a patch for this vulnerability, and customers who have not updated should do so immediately to protect their infrastructure.” Devices with security content release 427.334 and higher have this issue resolved
  • Q. How long did FireEye take to resolve this issue after it was reported?
  • A. FireEye responded very quickly, pushed out temporary mitigations to customers within hours of our report and resolved the issue completely within 2 days.
    • Q. Have FireEye supported your security research?
  • A. Yes, FireEye have been very cooperative. They worked with us closely, provided test equipment, support, and have responded very quickly to any issues we reported.
  • “Project Zero have been evaluating a FireEye NX 7500 appliance, and created a lab to generate sample traffic. The test environment consisted of a workstation with four network interfaces. Two interfaces were connected to a hub, which were used for simulating network traffic. The FireEye passive monitoring interface (called pether3) was connected to a third port on the hub (acting like a mirror port) so that it could observe traffic being exchanged between the two interfaces on the test machine. This simulates an intranet user receiving email or downloading files from the internet.”
  • “The main analyses performed by the FireEye appliance are monitoring for known malicious traffic (blacklisted netblocks, malware domains, snort rules, etc), static analysis of transferred files (antivirus, yara rules, and analysis scripts), and finally tracing the execution of transferred files in instrumented virtual machines. Once an execution trace has been generated, pattern matching against known-bad behaviour is performed.”
  • “The MIP (Malware Input Processor) subsystem is responsible for the static analysis of files, invoking helper programs and plugins to decode various file types. For example, the swf helper invokes flasm to disassemble flash files, the dmg helper invokes p7zip to extract the contents of Mac OS Disk Images and the png helper invokes pngcheck to check for malformed images. The jar helper is used to analyze captured Java Archives, which checks for signatures using jarsigner, then attempts to decompile the contents using an open source Java decompiler called JODE.”
  • The problem is that the JODE decompiler, actually executes small bits of the java code, to try to deobfuscate it
  • “With some trial and error, we were eventually able to construct a class that JODE would execute, and used it to invoke java.lang.Runtime.getRuntime().exec(), which allows us to execute arbitrary shell commands. This worked during our testing, and we were able to execute commands just by transferring JAR files across the passive monitoring interfaces.”
  • So, just by emailing someone behind this device a .jar file, it would end up getting executed on the security device, running arbitrary shell commands
  • “As FireEye is shipped with ncat installed by default, creating a connect-back shell is as simple as specifying the command we want and the address of our control server.”
  • “We now have code execution as user mip, the Malware Input Processor. The mip user is already quite privileged, capable of accessing sensitive network data. However, , there is a very simple privilege escalation to root”
  • “FireEye have requested additional time to prepare a fix for the privilege escalation component of this attack”
  • “This allows exfiltration of confidential data, tampering with traffic, lateral movement around networks and even self-propagating internet worms.”
  • “If you would like to read more from our series on attacks against security products, we have also published research into ESET, Kaspersky, Sophos, Avast and more, with further research scheduled for release soon.”


Round Up:

Question? Comments? Contact us here!