This project has moved. For the latest updates, please go here.

Question about "evil maid" attack detection

Topics: Technical Issues, Users Discussion
Dec 29, 2015 at 11:32 PM
I want to understand how reliable is "evil maid" attack detection in VeraCrypt.

I suspect that VeraCrypt simply checks if bootloader was modified or not.

If this is the case I can imagine two types of attacks that will break this protection:

Example 1:
  1. Adversary replaces VC bootloader with malicious bootloader
  2. When I start PC, malicious bootloader asks me to enter password, saves this password to a certain place on the disk, replaces itself with VC bootloader, and starts operating system
  3. When operating system is started, VC checks bootloader and finds that it was not modified
  4. Adversary returns and steals the disk with password saved in the certain place
Example 2:
  1. Adversary copies the disk and replaces VC bootloader with malicious bootloader
  2. When I start PC, malicious bootloader asks me to enter password, sends this password via internet and starts operating system
  3. When operating system is started, VC detects attack, but adversary already has the copy of the disk and password sent via internet
Please, explain why these types of attacks are not possible.
Coordinator
Dec 30, 2015 at 5:47 AM
Indeed, the detection is implemented by checking if the bootloader was modified or not on the disk.

If the malicious bootloader is able to erase itself and write back a genuine copy of VC bootloader before starting Windows, then obviously this will defeat the detection mechanism.

The current detection protects against simple attacks that were possible since TrueCrypt days and now it requires attackers to develop more complex code. It make attacks harder but not impossible.

That being said, there is a detection mechanism for the type of malicious bootloader you are describing: such bootloader must perform on the fly encryption/decryption to enable Windows to boot so it can't remove itself from RAM. This is the weakest point of such evil maid bootloader. Such property means that when Windows is booting and before we activate our filter driver, we can scan memory to look for the bootloader code and from there we can compare it with our embedded version and also with the one on the disk.

Such sophisticated detection has not been implemented because of its complexity that requires a lot of work and tests to analyze the risks of false positives but definitely it should be put on the list of important features for the versions to come.
Dec 30, 2015 at 7:36 AM
Edited Dec 30, 2015 at 7:36 AM
Thank you for clarifying the current state of things.

I suspect that writing the discussed malicious bootloader is a matter of weeks, maybe months, but not years, which means that VC user can't consider himself protected against this type of attack.

Anyway, thank you for what you do. Limited protection is better than nothing.
Dec 30, 2015 at 9:16 AM
Edited Dec 30, 2015 at 9:18 AM
i563456 wrote:
...which means that VC user can't consider himself protected against this type of attack.
I think this is way too much said... I think that if you let your PC fall in the hands of the evil maid... then you have yourself compromised the security model.... at least partially....

In line with that, if you use BIOS/uefi password at logon, then the evil maid attack to be possible, one has to dismantle your system first, taking out the hard drive etc.....

I consider much more dangerous the leaking of the encryption key to swap-file, hibernation file, memory dump files, etc . ......not in the case of full system encryption of course
Jan 3, 2016 at 10:07 PM
Edited Jan 3, 2016 at 10:29 PM
@ i563456

Example 2 would realistically take a long time.
  1. Adversary copies the disk and replaces VC bootloader with malicious bootloader
You would need to know the size of the disk for time reasons, and as its encrypted you will not know which partitions contain the data you want, and so the only other option is to image the whole drive, which depending on the size of the whole disk could take a few hours.

The time issue is a deterrent in itself.

And as a user already stated here, enable BIOS password, which the password can be removed by taking out the CMOS battery or using the motherboard jumper, but you can put a lock on the case, both these and imaging the drive would take very long time.

Using a live System, hash the the encrypted drive which includes the boot loader, then make an image of the drive, then take a hash of the image compare them both to make sure nothing changed, save your hashes for future reference.

After that if you want to check if anythings changed on return, boot from live system, check the hash of the encrypted drive, if it matches all is fine, if not your system is compromised and you know not to connect to the Internet :)

You will need to check hashes every time your will leave your system for a long time, as the hashes will change as you use your drive, only hash when you know you will not be using it for a long time.

Or simply just Installing some hidden cameras along with hidden router if your gone for a long time defeats this possible risk :)
  1. When I start PC, malicious bootloader asks me to enter password, sends this password via internet and starts operating system.
Usually you connect to the Internet after the OS starts not before, and disabling DHCP or unplugging the RJ45 cable defeats a malicious app sending data before OS starts.

Remember, defense in depth.
Jan 4, 2016 at 6:53 AM
Edited Jan 4, 2016 at 6:55 AM
Why not just boot to a USB stick and hash the boot loader on the HDD? If the hash is correct, boot to the HDD. No way evil maid can replicate the hash.
Jan 4, 2016 at 10:41 AM
Edited Jan 4, 2016 at 11:13 AM
@ GeorgeWest

Yes I agree with you, you could even boot from CD too.

Have you tried to do what you suggested? if we can find the boot loader on the HDD we can do this, I know you could find it on the recovery disc and hash it there, but obviously you would need to be able to check the hash of the boot loader on the HDD too, I think this is how the evil maid detection works with VeraCrypt, it just s checks the hash of the boot loader.

But if a malicious program copied the boot loader and then put it back when the damage is done the hash would still match.

The rescue disk could play a bigger role for this kind of attack than just replacing the boot loader.

If we make the boot loader polymorphic, as in it changes some of its own code as its copied, this will defeat this type of evil maid attack, also add some armour so a malicious program cannot read its code.

You can always restore the boot loader from rescue disk everytime you turn your system on, this would overwrite the malicious boot loader, but not if it was running from RAM from a secret location, you would need to add detection and prevention of some kind with the CD recovery disk as mentioned, as well as replacing the boot loader,

The key is in hashing and rescue disk for sure, its just implementing it in the correct way.
Jan 4, 2016 at 7:51 PM
@Paul

"But if a malicious program copied the boot loader and then put it back when the damage is done the hash would still match."

Wouldn't this require that the user boot without checking the boot loader hash in order for any damage to get done? And after knowing that his computer was subjected to compromising circumstances like a gap in physical custody?
Jan 4, 2016 at 11:30 PM
Edited Jan 5, 2016 at 12:11 AM
@ GeorgeWest

It wouldn't matter as the hash before the attack would be the same
and the hash after the attack would be the same, so your still left unaware
that an attack was in place, other than the fact you left the machine
alone in an obvious place to be attacked.

There is no current way of knowing unless we make it possible to use the rescue disk at boot
and make it check the hash of the boot loader and a hidden place on the HDD which if using a polymorphic
code and if the HDD boot loader is copied will change some code in the hidden place on the HDD which
will be unreadable or detectable to malicious program, even if the hashes match for the boot loader by the malicious
program putting back the original boot loader hey will not match for the hidden place

The disc would also need some type of detection, for example by looking for hooked processes in RAM and the
rescue disc to be able to hide its own code.

That is the important part not just depending on hashes alone
Coordinator
Jan 5, 2016 at 8:20 PM
The attack described by the OP doesn't involve any process running on Windows: all the logic is in the malicious bootloader which erase itself from disk and replace it with the original VeraCrypt bootloader. This makes any detection, even by comparing to the rescue disk, impossible.

As I said, the only solution to detect such sophisticated attack is to implement a memory scan of the BIOS memory to look for our bootloader and if it is missing, then ring the alarms.

Until then, the best protection is to never boot from hard disk in case of doubt and always boot using Rescue Disk. Recently, I published a package containing free tools and instructions on how to create a bootable USB key that will act as rescue disk, so one can always carry such USB key when traveling for example and always boot on it instead of local disk if the PC was left unattended. The package can be found at http://sourceforge.net/projects/veracrypt/files/Contributions/VeraCryptUsbRescueDisk.zip/download.
Jan 13, 2016 at 10:37 PM
Edited Jan 13, 2016 at 11:07 PM
@ Idrassi

In regard to the original posters statement " When I start PC, malicious bootloader asks me to enter password, sends this password via internet and starts operating system."

and yours " The attack described by the OP doesn't involve any process running on Windows: all the logic is in the malicious bootloader which erase itself from disk and replace it with the original VeraCrypt bootloader." I presume you are talking about one of the attacks mentioned above and excluding the password being sent over the Internet, if so ignore my following comment.

Yes that's true, but a malicious bootloader like explained above would be unable to send out packets (password) if it has
not obtained an ip address first (if its coded for network access) but you would need to know such an attack took place to have any benefit, as if the OS contained malicious code too working with the malicious boot loader it wouldn't matter, but if the malicious bootloader was network enabled before boot without the need for an OS malicious app, simply booting from
the rescue disk and configuring your network to use static ip addresses within the range of the router and with DHCP disabled it would defeat such action of the password being sent before boot, unless the malicious bootloader was able to sniff a static ip address and assign the subnetmask and default gateway by itself, in which case just plugging out the cable before boot would also stop this.

The main problem is actually knowing, so we should use all steps mentioned as a precaution if needed.

I like your idea for prevention of this attack but we also need to scan RAM as well as BIOS memory, all this running from a live mini Vera OS of course or the rescue disk.

On a separate note, excellent work.