[Security] The "Evil Maid" attack on disk encryption

Micah Lee micahflee at gmail.com
Sun Oct 25 05:26:39 UTC 2009


So I recently read on slashdot about the Evil Maid:

http://it.slashdot.org/story/09/10/23/1212248/Of-Encrypted-Hard-Drives-and-Evil-Maids
http://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html
http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html

It's a tool written by Joanna Rutkowska that attacks TrueCrypt system
encryption on Windows systems. I'm especially interested in this because I
was trying to do a very similar attack against TrueCrypt a couple months ago
before I gave up because I didn't want to try to cram an NTFS driver (which
I know nothing about) into the bootloader. I even (like her) submitted a
vulnerability report to TrueCrypt about it, and they brushed it off saying
that if an attacker gains physical access, then it's impossible to be 100%
secure.

In brief, whole disk encryption works by adding a lightweight layer between
your operating system and your hard drive that does on-the-fly encryption
and decryption, so it's transparent to the user after booting up. When you
boot up, the encryption software asks for your passphrase and uses that as a
key to decrypt the longer encryption keys, which are used for on-the-fly
encryption of your hard drive. In the end, the only program on your computer
that isn't encrypted on the disk is the program that asks for your
passphrase -- which means that with physical access, you can modify that
program to make it malicious, to compromise the disk encryption.

Joanna Rutkowska's attack worked like this. You boot the computer off of a
malicious USB drive that modifies the TrueCrypt bootloader (TrueCrypt and
PGP Desktop store that unencrypted program in the MBR of the drive), and it
modifies the bootloader. The next time the owner of the computer boots up,
it records the passphrase in free space in the MBR. Then, if you get
physically access again, you can boot up to the USB drive again to get the
passphrase. While this is a pretty slick attack, wouldn't it be much slicker
if you didn't have to get physical access to the computer twice, and even
then only get the passphrase? I think you should be able to do this with
only having physical access once, and then having it install a rootkit on
the computer.

I first did this attack against Linux disk encryption that uses cryptsetup
(which is pretty much the standard way of using whole disk encryption in
Linux, and is included in the installers of Ubuntu, Debian, Fedora, and
other distros). It's much easier with Linux, because the entire boot
partition is normally unencrypted, and you have access to busybox and shell
scripts while you're making the attack. I modified cryptsetup in the boot
partition so that it not only records the passphrase, but goes ahead and
uses it to decrypt the hard drive, mount the root partition, and install a
rootkit all while booting up. If anyone wants me to show you this attack and
exactly how it works I'd be happy to.

So once I got Linux, I tried to do the same sort of attack against TrueCrypt
in Windows. I downloaded the TrueCrypt source and modified it so that it
recorded the passphrase, but then I got stuck. At the stage where it mounts
the encrypted hard drive, the filesystem drivers haven't been loaded yet,
and what I really wanted to do was write files to the drive. All I had
access to was writing raw bytes to the drive, which could potentially
destroy the NTFS filesystem without a properly implemented driver. That's
where I got stuck and gave up.

It seems much more difficult (for me at least) to do this attack against
proprietary encryption software, like PGP Desktop. But it's still possible.

Anyway, is anyone else interested in this stuff? Does anyone want to try to
make a much more badass Evil Maid, or even just formalize my work attacking
Linux disk encryption into a paper to publish (since I've never done that
sort of thing, and don't really know how)?

Micah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.noisebridge.net/pipermail/security/attachments/20091024/424ddb79/attachment-0002.html>


More information about the Security mailing list