Evil Maids on the rise

The opportunities for evil maids seems to be soaring.

Some weeks ago, I blogged about how a malicious room maid could install a software password sniffer on a portable PC with TrueCrypt Full Disk Encryption (FDE) – needing only a few minutes of access to the abandoned laptop.

Subsequently, the real attacker who hired the maid would steal the laptop and harvest the encryption password. I also suggested that hardware support like a TPM chip was the generic way to defeat this sort of attack.

However, things can change pretty fast in the world of computer security, and researchers at the German Fraunhofer Institute for Secure Information Technology have proved me wrong – at least in regard to the TPM chip.

Well, sort of. Although they were not able to manipulate the password entry procedure of the FDE product (Windows Bitlocker with TPM support) itself, they were able to get hold of the password by installing a fake (Trojan) password entry dialog.

In their paper ‘Attacking the Bitlocker Boot Process’, the researchers described amongst some other – less relevant – attacks against Bitlocker with TPM support, how they managed to manipulate the Bitlocker boot process.

They installed a fake password entry dialog that looks identical to the real one (which isn’t exactly a challenge, see the picture below).

BitLocker PIN screen

This dialog precedes the Bitlocker boot and authentication sequence, and saves the intercepted password away. Then it deinstalls itself again and reboots.

Yet, something’s different: The Trojan password dialog is followed by a restart and the authentic Bitlocker password dialog. Although many average users might realise that something smells fishy here, only a few alert ones will associate it with an attack. Most users will just file it in the category UBP (Unidentified Boot Peculiarities) that we’ve been seeing from the very beginning of the PC era.

So how is it that TPM boot integrity verification is failing here?

With its Platform Configuration Registers (PCR), the TPM chip supervises the integrity of all platform components that are relevant for the boot process (such as MBR, boot sector and boot block). Within the Bitlocker boot process, the TPM doesn’t release any key material which is essential for the decryption of the Windows volume until it has been able to verify the integrity of these components.

However, it is *not* able to stop the boot process before it gets explicitly called. The TPM specification [PDF] states the following:

"As part of system initialization, measurements of platform components and configurations will be taken. Taking measurements will not detect unsafe configurations nor will it take action to prevent continuation of the initialization process. This responsibility rests with a suitable reference monitor such as an operating system."

Apparently, it wasn’t an objective of the TPM designers to autonomously supervise the integrity of the early boot process of a PC and to take actions in case of manipulation. In the Bitlocker boot process, the TPM chip gets called from the Windows boot loader and later from Windows itself.

Although the TPM chip does perform integrity checks already as part of platform initialization, it has no chance to trigger corrective actions until it gets subsequently called. In addition, it does not preserve the checks beyond a reboot. Hence, an attack window opens up that spans from booting the MBR (which an attacker can manipulate) to performing a reboot before the TPM chip gets called the first time by Bitlocker.

This is where the researchers placed their malicious password dialog.

It is still unanswered anyhow why BIOS vendors don’t explicitly call the TPM chip as part of the Power-On Self Test (POST) procedure. By doing this they’d be able to stop the boot process in case of manipulation *before* any malicious code could be executed. Hopefully, future PCs will show this behaviour.

As long as this is not implemented, though, Bitlocker users are advised to carefully count the number of password entries before the system actually boots.

Alternatively, all countermeasures stated in my initial blog entry address this attack as well.