[LACNIC/Seguridad] Fwd: Evil Maid goes after TrueCrypt!

[Carlos M. Martinez]

Interesante lectura




    Evil Maid goes after TrueCrypt!

<http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html>

via The Invisible Things Lab's blog
<http://theinvisiblethings.blogspot.com/> by noreply en blogger.com
(joanna) on 10/15/09

>From time to time it’s good to take a break from all the ultra-low-level
stuff, like e.g. chipset or TXT hacking, and do something simple, yet
still important. Recently Alex Tereshkin and I got some spare time and
we implemented the Evil Maid Attack
<http://theinvisiblethings.blogspot.com/2009/01/why-do-i-miss-microsoft-bitlocker.html>
against TrueCrypt system disk encryption in a form of a small bootable
USB stick image that allows to perform the attack in an easy
“plug-and-play” way. The whole infection process takes about 1 minute,
and it’s well suited to be used by hotel maids.

The Attack
Let’s quickly recap the Evil Maid Attack. The scenario we consider is
when somebody left an encrypted laptop e.g. in a hotel room. Let’s
assume the laptop uses full disk encryption like e.g. this provided by
TrueCrypt <http://www.truecrypt.org/>or PGP Whole Disk Encryption
<http://www.pgp.com/products/wholediskencryption/index.html>.

Many people believe, including some well known security
<http://citp.princeton.edu/memory/faq/> experts
<http://www.tomshardware.com/reviews/dino-dai-zovi,2260-5.html>, that it
is advisable to fully power down your laptop when you use full disk
encryption in order to prevent attacks via FireWire/PCMCIA
<http://theinvisiblethings.blogspot.com/2009/05/thoughts-about-trusted-computing.html>or
”Coldboot” attacks <http://citp.princeton.edu/memory/>.

So, let’s assume we have a reasonably paranoid user, that uses full disk
encryption on his or her laptop, and also powers it down every time they
leave it alone in a hotel room, or somewhere else.

Now, this is where our Evil Maid stick comes into play. All the attacker
needs to do is to sneak into the user’s hotel room and boot the laptop
from the Evil Maid USB Stick. After some 1-2 minutes, the target
laptop’s gets infected with Evil Maid Sniffer that will record the disk
encryption passphrase when the user enters it next time. As any smart
user might have guessed already, this part is ideally suited to be
performed by hotel maids, or people pretending to be them.

So, after our victim gets back to the hotel room and powers up his or
her laptop, the passphrase will be recorded and e.g. stored somewhere on
the disk, or maybe transmitted over the network (not implemented in
current version).

Now we can safely steal/confiscate the user’s laptop, as we know how to
decrypt it. End of story.

Quick Start
Download the USB image here
<http://invisiblethingslab.com/resources/evilmaid/evilmaidusb-1.01.img>.
In order to “burn” the Evil Maid use the following commands on Linux
(you need to be root to do dd):
|
dd if=evilmaidusb.img of=/dev/sdX
|
Where |/dev/sdX| should be replaced with the device representing your
USB stick, e.g. |/dev/sdb|. Please be careful, as choosing a wrong
device might result in damaging your hard disk or other media! Also,
make sure to use the device representing the whole disk (e.g.
|/dev/sdb|), rather than a disk partition (e.g. |/dev/sdb1|).

On Windows you would need to get a dd-like program, e.g. this one
<http://www.chrysocome.net/dd>, and the command would look more or less
like this one (depending on the actual dd implementation you use):
|
dd if=evilmaidusb.img of=\\?\Device\HarddiskX\Partition0 bs=1M
|
where |HarddiskX| should be replaced with the actual device the
represents your stick.

After preparing the Evil Maid USB stick, you’re ready to test it against
some TrueCrypt-encrypted laptop (more technically: a laptop that uses
TrueCrypt system disk encryption). Just boot the laptop from the stick,
confirm you want to run the tool (press ‘E’) and the TrueCrypt loader on
your laptop should be infected.

<http://2.bp.blogspot.com/_Ti3q3Hdvels/Stdls03RIgI/AAAAAAAAAFo/t-h8arbkmvo/s1600-h/em1.gif>Now,
Evil Maid will be logging the passphrases provided during the boot time.
To retrieve the recorded passphrase just boot again from the Evil Maid
USB -- it should detect that the target is already infected and display
the sniffed password.

<http://3.bp.blogspot.com/_Ti3q3Hdvels/Stdly_rCP0I/AAAAAAAAAFw/MIGLEThUux4/s1600-h/em2.gif>The
current implementation of Evil Maid always stores the last passphrase
entered, assuming this is the correct one, in case the user entered the
passphrase incorrectly at earlier attempts.

NOTE: It’s probably illegal to use Evil Maid to obtain password from
other people without their consent. You should always obtain permission
from other people before testing Evil Maid against their laptops!

CAUTION: The provided USB image and source code should be considered
proof-of-concept only. Use this code at your own risk, and never run it
against a production system. Invisible Things Lab cannot be held
responsible for any potential damages this code or its derivates might
cause.

How the Evil Maid USB works
The provided implementation is extremely simple. It first reads the
first 63 sectors of the primary disk (|/dev/sda|) and checks (looking at
the first sector) if the code there looks like a valid TrueCrypt loader.
If it does, the rest of the code is unpacked (using gzip) and hooked.
Evil Maid hooks the TC’s function that asks user for the passphrase, so
that the hook records whatever passphrase is provided to this function.
We also take care about adjusting some fields in the MBR, like the boot
loader size and its checksum. After the hooking is done, the loader is
packed again and written back to the disk.

You can get the source code for the Evil Maid infector here
<http://invisiblethingslab.com/resources/evilmaid/evilmaid-src-1.0.tgz>.

Possible Workarounds
So, how should we protect against such Evil Maid attacks? There are a
few approaches...

1. Protect your laptop when you leave it alone
Several months ago I had a discussion with one of the TrueCrypt
developers about possible means of preventing the Evil Maid Attack,
perhaps using TPM (see below). Our dialog went like this (reproduced
here with permission from the TrueCrypt developer):

    TrueCrypt Developer: We generally disregard "janitor" attacks since
    they inherently make the machine untrusted. We never consider the
    feasibility of hardware attacks; we simply have to assume the worst.
    After an attacker has "worked" with your hardware, you have to stop
    using it for sensitive data. It is impossible for TPM to prevent
    hardware attacks (for example, using hardware key loggers, which are
    readily available to average Joe users in computer shops, etc.)

    Joanna Rutkowska: And how can you determine that the attacker have
    or have not "worked" with your hardware? Do you carry your laptop
    with you all the time?

    TrueCrypt Developer: Given the scope of our product, how the user
    ensures physical security is not our problem. Anyway, to answer your
    question (as a side note), you could use e.g. a proper safety case
    with a proper lock (or, when you cannot have it with you, store it
    in a good strongbox).

    Joanna Rutkowska: If I could arrange for a proper lock or an
    impenetrable strongbox, then why in the world should I need encryption?

    TrueCrypt Developer: Your question was: "And how can you determine
    that the attacker has or has not worked with your hardware?" My
    answer was a good safety case or strongbox with a good lock. If you
    use it, then you will notice that the attacker has accessed your
    notebook inside (as the case or strongbox will be damaged and it
    cannot be replaced because you had the correct key with you). If the
    safety case or strongbox can be opened without getting damaged &
    unusable, then it's not a good safety case or strongbox. ;-)


That's a fair point, but this means that for the security of our data we
must relay on the infeasibility to open our strongbox lock in a "clean"
way, i.e. without visually damaging it. Plus it means we need to carry a
good strongbox with us to any travel we go. I think we need a better
solution...

Note that TrueCrypt authors do mention the possibility of physical
attacks in the documentation
<http://www.truecrypt.org/docs/physical-security>:

    If an attacker can physically access the computer hardware and you
    use it after the attacker has physically accessed it, then TrueCrypt
    may become unable to secure data on the computer. This is because
    the attacker may modify the hardware or attach a malicious hardware
    component to it (such as a hardware keystroke logger) that will
    capture the password or encryption key (e.g. when you mount a
    TrueCrypt volume) or otherwise compromise the security of the computer.

However, they do not explicitly warn users of a possibility of something
as simple and cheap as the Evil Maid Attack. Sure, they write "or
otherwise compromise the security of the computer", which does indeed
cover e.g. the Evil Maid Attack, but my bet is that very few users would
realize what it really means. The examples of physical attacks given in
the documentation, e.g. modifying the hardware or attaching a malicious
hardware, is something that most users would disregard as too expensive
an attack to be afraid of. But note that our Evil Maid attack is an
example of a “physical” attack, that doesn’t require any hardware
modification and is extremely cheap.

Of course it is a valid point, that if we allow a possibility of a
physical attack, then the attacker can e.g. install a hardware
keylogger. But doing that is really not so easy as we discuss in the
next paragraph. On the other hand, spending two minutes to boot the
machine from an Evil Maid USB stick is just trivial and is very cheap
(the price of the USB stick, plus the tip for the maid).

2. The Trusted Computing Approach
As explained
<http://theinvisiblethings.blogspot.com/2009/01/why-do-i-miss-microsoft-bitlocker.html>a
few months ago on this blog, a reasonably good solution against Evil
Maid attack seems to be to take advantage of either static or dynamic
root of trust offered by TPM. The first approach (SRTM) is what has been
implemented in Vista Bitlocker. However Bitlocker doesn’t try to
authenticate to the user (e.g. via displaying a custom picture shot by
the user, with the picture decrypted using a key unsealed from a TPM),
so it’s still possible to create a similar attack against Bitlocker, but
with a bit different user experience. Namely the Evil Maid for Bitlocker
would have to display a fake Bitlocker prompt (that could be identical
to the real Bitlocker prompt), but after obtaining a correct password
from the user Evil Maid would not be able to pass the execution to the
real Bitlocker code, as the SRTM chain will be broken. Instead, Evil
Maid would have to pretend that the password was wrong, uninstall
itself, and then reboot the platform. Thus, a Bitlocker user that is
confident that he or she entered the correct password, but the OS didn’t
boot correctly, should destroy the laptop.

The dynamic root of trust approach (DRTM) is possible thanks to Intel
TXT technology, but currently there is no full disk encryption software
that would make use of it. One can try to implement it using Intel’s
tboot <http://sourceforge.net/projects/tboot/>and some Linux disk
encryption, e.g. LUKS.

Please also note that even if we assume somebody “cracked” the TPM chip
(e.g. using an electron microscope, or NSA backdoor), that doesn’t mean
this person can automatically get access to the encrypted disk contents.
This is not the case, as the TPM is used only for ensuring trusted boot.
After cracking the TPM, the attacker would still have to mount an Evil
Maid attack in order to obtain the passphrase or key. Without TPM this
attack is always possible.

Are those trusted computing-based approaches 100% foolproof? Of course
not. As signalized in the previous paragraph, if an attacker was able to
mount a hardware-based keylogger into your laptop (which is non-trivial,
but possible), then the attacker would be able to capture your
passphrase regardless of the trusted boot. A user can prevent such an
attack by using two-factor authentication (RSA challenge-response
implemented in a USB token) or e.g. one-time passwords, so that there is
no benefit for the attacker to capture the keystrokes. But the attacker
might go to the extreme and e.g. replace the DRAM, or even the CPU with
malicious DRAM or CPU that would sniff and store the decryption key for
later access. We’re talking here about attack that very few entities can
probably afford (think NSA), but nevertheless they are theoretically
possible. (Note that an attack with inserting a malicious PCI device
that would try to sniff the key using DMA can be prevented
<http://theinvisiblethings.blogspot.com/2009/03/trusting-hardware.html>using
TXT+VT-d technology).

However, just because the NSA can theoretically replace your CPU with a
malicious one, doesn’t mean TPM-based solutions are useless. As for the
great majority of other people that do not happen to be on the Terrorist
Top 10, these represent a reasonable solution that could prevent Evil
Maid attacks, and, when combined with a proper two-factor
authentication, also simple hardware based attacks, e.g. keylogger,
cameras, remote keystroke sniffing using laser, etc. I really cannot
think of a more reasonable solution here.

3. The Poor Man’s Solution
Personally I would love to see TrueCrypt implementing TPM-based trusted
boot for its loader, but, well, what can I do? Keep bothering TrueCrypt
developers with Evil Maid attacks and hope they will eventually consider
implementing TPM support...

So, in the meantime we have come up with a temporary poor man’s solution
that we use at our lab. We call it Disk Hasher. It’s a bootable
Linux-based USB stick that can be configured in quite a flexible way to
calculate hashes of selected disk sectors and partitions. The correct
hashes are stored also on the stick (of course everything is encrypted
with a custom laptop-specific passphrase). We use this stick to verify
the unencrypted portions of our laptops (typically the first 63 sectors
of sda, and also the whole /boot partition in case of Linux-based
laptops where we use LUKS/dm-crypt).

Of course there are many problems with such a solution. E.g. somebody
who can get access to my Disk Hasher USB (e.g. when I’m in a swimming
pool), can infect it in such a way that it would report correct hashes,
even though the disk of my laptop would be “evilmaided”...

Another problem with Disk Hasher solution is that it only looks at the
disk, but cannot validate e.g. the BIOS. So if the attacker found a way
to bypass the BIOS reflashing protection on my laptop, then he or she
can install a rootkit there that would sniff my passphrase or the
decryption key (in case I used one time passwords).

Nevertheless, our Disk Hasher stick seems like a reasonable solution and
we use it often internally at ITL to validate our laptops. In fact this
is the most we can do, if we want to use TrueCrypt, PGP WDE, or
LUKS/dm-crypt.

FAQ

Q: Is this Evil Maid Attack some l33t new h4ck?
Nope, the concept behind the Evil Maid Attack is neither new, nor l33t
in any way.

Q: So, why did you write it?
Because we believe it demonstrates an important problem, and we would
like more attention to be paid in the industry to solving it.

Q: I’m using two-factor authentication, am I protected against EM?
While a two-factor authentication or one time passwords are generally a
good idea (e.g. they can prevent various keylogger attacks), they alone
do not provide protection from Evil Maid-like attacks, because the
attacker might modify his or her sniffer to look for the final
decryption key (that would be calculated after the 2-factor
authentication completes).

Q: How is Evil Maid different from Stoned-Bootkit?
The Stoned Bootkit <http://www.stoned-vienna.com/>, released a few
months ago by an individual describing himself as “Software Dev. Guru in
Vienna”, is also claimed to be capable of "bypassing TrueCrypt", which
we take to mean a capability to sniff TC's passphrases or keys. Still,
the biggest difference between Stoned Bootkit and Evil Maid USB is that
in case of our attack you don’t need to start the victim's OS in order
to install Evil Maid, all you need to do is to boot from a USB stick,
wait about 1 minute for the minimal Linux to start, and then press ‘E’,
wait some 2 more seconds, and you’re done. With the Stoned Bootkit,
according to the author’s description, you need to get admin access to
the target OS in order to install it, so you either need to know the
Windows admin password first, or use some exploit to get the installer
executing on the target OS. Alternatively, you can install it from a
bootable Windows CD, but this, according to the author, works only
against unencrypted volumes, so no use in case of TrueCrypt compromise.

Q: I've disabled boot from USB in BIOS and my BIOS is password
protected, am I protected against EM?
No. Taking out your HDD, hooking it up to a USB enclosure case and later
installing it back to your laptop increases the attack time by some 5-15
minutes at most. A maid has to carry her own laptop to do this though.

Q: What about using a HDD with built-in hardware-based encryption?
We haven’t tested such encryption systems, so we don’t know. There are
many open questions here: how is the passphrase obtained from the user?
Using software stored on the disk or in the BIOS? If on the disk, is
this portion of disk made read-only? If so, does it mean it is
non-updatable? Even if it is truly read-only, if the attacker can
reflash the BIOS
<http://invisiblethingslab.com/resources/bh09usa/Attacking%20Intel%20BIOS.pdf>,
then he or she can install a passphrase sniffer there in the BIOS. Of
course that would make the attack non-trivial and much more expensive
than the original Evil Maid USB we presented here.

Q: Which TrueCrypt versions are supported by the current Evil Maid USB?
We have tested our Evil Maid USB against TrueCrypt versions 6.0a - 6.2a
(the latest version currently available). Of course, if the “shape” of
the TrueCrypt loader changed dramatically in the future, then Evil Maid
USB would require updating.

Q: Why did you choose TrueCrypt and not some other product?
Because we believe TrueCrypt is a great product, we use it often in our
lab, and we would love to see it getting some better protection against
such attacks.

Q: Why there is no TPM support in TrueCrypt?
The TrueCrypt Foundation published official generalized response to
TPM-related feature requests here <http://www.truecrypt.org/faq#tpm>.

Acknowledgments
Thanks to the ennead en truecrypt.org for all the polemics we had which
allowed me to better gather my thoughts on the topic. The same thanks to
Alex and Rafal, for all the polemics I have had with them (it's
customary for ITL to spend a lot of time finding bugs in each other's
reasoning).





      Things you can do from here:

    * Subscribe to The Invisible Things Lab's blog

<http://www.google.com/reader/view/feed%2Fhttp%3A%2F%2Ftheinvisiblethings.blogspot.com%2Ffeeds%2Fposts%2Fdefault%3Falt%3Drss?source=email>
      using *Google Reader*
    * Get started using Google Reader
      <http://www.google.com/reader/?source=email> to easily keep up
      with *all your favorite sites*