Playing Hide-and-Seek with BIOS Implants

March 12, 2014
Host-based Security: Post by Xeno Kovah

In July 2013, MITRE released Copernicus, a tool to allow users to check on whether their BIOS is writable, and, if so, export a copy for inspection. This was the first tool that made it easy to check the BIOS on Windows machines throughout an enterprise. We even deployed it to over 8,000 internal systems (and we encourage interested organizations to work with us to pilot it in their own enterprises).

However, like many security tools, we were aware that Copernicus had limitations, and a motivated attacker could get around its detection mechanism. Beyond any tool-specific limitations, we eventually realized too that it's possible to defeat all software-based BIOS capture systems. This applies to not only Copernicus but any similar tool: an attacker can exploit the way that software reads the BIOS flash chip off the SPI bus. To see this more clearly, read the deep dive that follows.

The Problem of a Sophisticated BIOS Attack

When dealing with an attacker presumed to control the BIOS, recognize that they could also control System Management Mode (SMM) and use the hardware support for virtualization. Although SMM is supposed to be locked down, my colleague Corey Kallenberg has shown multiple attacks that can allow an attacker to bypass BIOS security mechanisms, like signed BIOS updates, and take control of SMM.

To demonstrate the ability of an SMM-resident attacker to perform a man-in-the-middle (MitM) attack on BIOS reads, my colleague John Butterworth wrote a proof-of-concept attacker, which was given a dragon theme, called "Smite'em the Stealthy" (where "Smite'em" is based on the combination of SMM and MitM.) The key point of Smite'em is to show that to catch an adversary sophisticated enough to live in BIOS/SMM, you need to make your software trustworthy; otherwise you’ll just be reporting the lies an attacker wants you to report.

Introducing Copernicus 2: SENTER the Dragon!

We, of course, wanted to fix this problem. Luckily it turns out that there are widely available Trustworthy Computing technologies built into modern x86 chips that we can leverage to take Smite'em--and a whole host of less sophisticated attackers--off the table. Although we could have used the timing-based attestation techniques we developed in our previous research on BIOS Chronomancy and Checkmate, we instead chose to learn more about Intel Trusted Execution Technology (TXT) and specifically leverage an interesting side effect we already knew about.

At the most basic level, TXT allows for the "late launch" of a trusted environment, even from an already-booted and untrusted system, by using the special "SENTER" instruction. This essentially tears down the existing system state (in a way it can be put back later, of course), and sets up a known and measured environment. These measurements are stored in the Trusted Platform Module (TPM), and can then be securely reported to check whether the environment was tampered with and therefore is not trustworthy. The TPM does this by signing its output.

In past talks, researchers at Invisible Things Labs showed different ways to defeat TXT. One way was by residing in SMM while starting TXT, and then compromising the measurement environment. This succeeded because the attack code residing in SMM is not measured as part of the TXT launch. What wasn’t mentioned though, is that the TXT measured launch actually disables the ability for SMM code to run. It's only after the measured code re-enables SMM that the attacker can proceed to target the measured code. So, the measured code actually need not allow itself to be attacked by SMM. Thus, being in SMM is not an automatic win against the use of TXT. While it's natural to re-enable SMM as soon as possible, if you're using TXT to launch something like a virtual machine monitor (VMM), such as by making use of a single-purpose application like Copernicus, you don't want to let SMM run until you're completely done with your measurement. And that's exactly what we've done with Copernicus 2. This prevents an attacker like Smite'em from being able to subvert measurements.

With Copernicus 2 we leveraged Flicker, an open source late-launch system developed at Carnegie Mellon University to run our code. We also contributed code back to Flicker to allow it to improve the support for running in a stock Windows 7 32-bit system. Previously you had to disable physical address extensions, which also disabled the non-executable memory security feature.

We should note that running code in a TXT measured launch environment does not have the convenience routines of the OS available. However, we were able to port our code to run in Flicker and work through any limitations. For a security tool like Copernicus, which directly checks hardware registers and communicates via hardware busses, the port was relatively easy because Copernicus dives down below the OS abstraction layers anyway. The nice thing about Flicker is that it does provide basic libraries for communicating with the TPM, so we didn’t need to write any of that code.

The Advantage of Using Copernicus 2 Against Advanced Attackers

Unlike Copernicus 1, Copernicus 2 ultimately provides an ability to obtain trustworthy measurements of a system's BIOS and configuration, without the fear that the measurements have been tampered with in memory, on the filesystem, or over the network. For environments where this higher degree of certainty is required, we're hoping that Copernicus 2 will serve as a good example of how special purpose security tools can be made more trustworthy. We will continue to be outmatched by attackers if defenders don't utilize technologies like TXT or the TPM.


As with Copernicus 1, we're purposely releasing only the binary at this time. It is our intention that, like Copernicus 1, you may use Copernicus 2 to protect your systems without consulting or informing us. This model of usage is similar to how Microsoft/Sysinternals security and monitoring tools are made widely available in binary-only form, thus providing many organizations with significant value.

Also like Copernicus 1, the source code for Copernicus 2 is available to organizations that wish to license or evaluate it before collaborating on large-scale deployments. If you would like to discuss such an arrangement, please contact us.