How can the Equation Group HDD firmware malware help bypass FDE?

Question

There is currently a lot of discussion going on across the Internet about the "Equation Group" family of malicious hard disk drive firmware.

One thing that has me wondering is the claim that malicious HDD firmware would be able to access details on any running full-disk encryption scheme. For example, we have How the NSA's Firmware Hacking Works and Why It's So Unsettling, by Wired which states, in part (referring here to unused portions of the firmware EEPROM):

“Taking into account the fact that their GrayFish implant is active from the very boot of the system, they have the ability to capture the encryption password and save it into this hidden area,” [Costin Raiu, director of Kaspersky’s Global Research and Analysis Team] says.

Maybe I'm missing something obvious, but I don't understand how this follows. There are two cases I can see here:

• Microsoft Windows, with Bitlocker enabled. The firmware loader is apparently a Windows executable, and Windows is a common OS, so you could have some leverage with "out of the box" code.
• Some other OS with FDE, say Linux with LUKS or FreeBSD with GEOM. These would, at the very least, be immediately unaffected by a Windows binary.

When using full-disk encryption, the storage device (whether HDD, SSD, floppy, or whatever) is tasked with safekeeping the encrypted bits. Certain headers are known to exist in different FDE schemes, do often contain key material, and can presumably be detected based on magic numbers or on-disk location, but the meaty parts are encrypted by the time they reach the storage device.

How can a storage device's firmware meaningfully subvert properly implemented full disk encryption, in which the storage device sees only encrypted data in READ and WRITE commands?

The only real possibility I can see is if the storage device firmware can somehow influence other parts of the system perhaps by exploiting DMA, but wouldn't the CPU's memory manager step in there? Or is DMA always done in supervisor mode (ring 0 in Intel terminology)? That would seem to open up a whole different can of worms.

Let's assume here a fairly typical FDE setup: BIOS or UEFI, handing off to a tiny unencrypted bootloader that prompts the user for a password and proceeds to initialize the cryptosystem state before going resident to intercept disk I/O and doing encryption/decryption as the data flows between the normal I/O layer of the OS and the storage device itself. All "one way or another", leaving technical implementation details aside unless they directly pertain to answering the main question.

Answer 1

This is equivalent to an evil maid attack, which compromises the (unencrypted) bootloader to capture your FDE password the next time you start your computer.

This assumes the bootloader is kept on the same drive. If that's not the case (for example if you keep your bootloader on a removable drive) and you explicitly configure your computer to not boot from the main hard drive (as to not execute potentially malicious code planted on it) then this attack won't work.

By default, with both LUKS and Bitlocker, a small part of the drive is kept unencrypted and the FDE-aware bootloader lives there and is executed on each boot; so the drive does more than safekeeping the encrypted bits. A TPM could help mitigate that by verifying the integrity (hashes) of the bootloader before giving out the keys, and Bitlocker takes advantage of that by default. For LUKS, there is no official support for TPM but some solutions exist like TrustedGRUB (for actually extending the chain of trust) and tpm-luks for saving and retrieving the LUKS key from the TPM.

Answer 2

I'd imagine the firmware is retooled to present one of the "spare" blocks on the platter to the MOBO for boot (after first writing a rootkit to that hidden sector) and then to chain load what ought to be the "real" boot sector sector (i.e., the one containing your encrypted disk boot loader) after the rootkit is in memory.

Read up on the stoned bootkit here: http://www.stoned-vienna.com/ If an attacker compromises the OS and can plant firmware hacks that accomplish this, the attack is a simple matter. Really all the firmware adds is persistence.

Not sure how this would work with more modern bootstrap situations such as UEFI, but then again I suspect the timing of the NSA attacks predated large scale (which is to say Windows 8 era) adoption.

It would be nice if the security folks could get ahold of one of these drives and see whether, for example, having disk encryption boot loader load off a USB or CDROM avoids this.

Another thing I can think of is to have the firmware place a bootkit that does nothing but scan the keyboard buffer for stings of certain length followed by a carriage return, and to then store those in the disk maintenance tracks. Or maybe it simply sits there scanning memory until it finds some AES keys and writes them to storage.

The point is its a persistent way to own a system and once that happens (ring zero access baby), all bets are off and a fairly broad series of attacks are possible.