Some weeks ago, Polish researcher Joanna Rutkowska published an attack on the TrueCrypt Full-Disk Encryption (FDE) software, which allows an attacker with access to an unattended PC to install a password sniffer in a first strike, and to steal the PC including the FDE password in a second strike.
She coined the term “evil maid attack” for this kind of incident, as it specifically applies to scenarios in which a traveller leaves a portable PC unattended in a hotel room, and a person who has access, but not necessarily dedicated technical skills (e.g. a room maid) actually executes the attack.
Technically, this person (in the absence of any reliable data on popular names for room maids, let’s just call her Trudy) inserts a bootable medium (e.g. a CD-ROM or USB stick), turns the laptop on, and consequently the bootable malware code on the medium gets executed.
This code then installs a transparent key logger in the Master Boot Record (MBR) of the hard disk. Later, the unsuspecting owner turns on his laptop, enters the passphrase and boots up. Without his knowledge, the keylogger intercepts the passphrase and stores it on the hard disk.
Finally, Trudy only needs to steal the laptop and to hand it over to the person who targeted the victim. Both steps don’t require any particular technical knowledge, and can be performed by a person instructed/bribed by the master attacker.
It’s not only TrueCrypt which is susceptible to this kind of attack, but basically all pure software FDE products. These products don’t employ any additional hardware (e.g. TPM chip) to maintain the integrity of the boot process.
Although Sophos engineers have invested a lot of time implementing several additional hurdles to make this type of attack a lot more difficult than with TrueCrypt, Sophos FDE products (as well as respective competitor products) are eventually affected. Product specialists have known about the general susceptibility of products to this kind of attack for quite some time, and preceding projects such as the Stoned Bootkit paved the way to finally implement it.
After all, it’s a somewhat philosophical question where the responsibility of a security software ends and where the owner’s responsibility to maintain the integrity of the respective hardware platform starts. Attackers who are able to gain full control over the hardware will always find a way to breach the security of the overall system – for instance, imagine a hardware keylogger hidden invisibly inside the case of a PC. It is important, however, that the user understands these risks and boundaries, and knows how to deal with them.
And yes, there are several ways to mitigate them quite efficiently:
Firstly, and most obviously, don’t leave your laptop unattended. Alternatively, lock it away whenever this is possible.
Secondly, disable the possibility of booting from an external medium (such as USB stick or CD ROM) in the BIOS, or move such media to be after the hard disk in the boot sequence.
Subsequently, protect BIOS access with a password. On a Mac, simply activate the firmware password, which will implicitly do both jobs.
These steps are available on basically every laptop, and will require Trudy to dismount the hard disk from the device and to mount it in an external USB enclosure with (or directly in) another computer to infect it with the keylogger. This will most likely exceed the available time and skills of any average Trudy.
Thirdly, use biometric or two-factor authentication (e.g. a passphrase and a hardware token) to perform authentication with the FDE system.
These mechanisms will stop an evil maid gathering any easily interceptable and reusable logon credentials (such as a password), and will raise the bar for a successful attack even higher. An attacker will require advanced skills in reverse-engineering and cryptography, and several weeks (or even months) of preparation to mount an attack against a system with such an authentication device.
As already indicated, a more generic protection against this kind of attack requires hardware support to supervise the integrity of the boot process. Windows Bitlocker with TPM support is one product that optionally supports this approach.
However, not all notebooks have a TPM chip, and emergency recovery with such systems can become a complicated and expensive operation (just think of a broken motherboard and the following TPM key restoration procedure). Self-encrypting hard disks following the Opal standard (see my earlier blog which covered that) may improve this situation in the future, as they promise a fully protected pre- and early boot procedure.
With Sophos SafeGuard Enterprise, you have the option to use a variety of smart cards, fingerprint readers and other hardware devices as pre-boot authentication tokens that help you to counter this attack.
Beyond that, our engineers are carefully observing the development of hardware support in this area, and will come up with a solution for a fully protected pre-boot process with easy disaster recovery management as soon the technical preconditions are met. So stay tuned…