OK, you’ve taken our advice and installed your favorite linux distro on a fully encrypted disk. This not only secures your data, but write-protects the bulk of your system, as you someone burglarizing your home cannot write keyloggers and spyware unless he first decrypts the disk-which requires that those keyloggers already be there-checkin and egg, he loses.
Well, not quite: you cannot encrypt the /boot partition because then “chicken and egg” keeps you from booting, as the BIOS cannot read encryption and could be attacked anyway if it could.
It is possible to replace the files that unlock your disk with a version that saves your passphrase for a later attack in what is called an ‘evil maid” attack, as published in 2600. The name comes from the ability to hire someone from the cleaning crew in a hotel to do this by simply booting from a special flash drive in the simplest cases. Truecrypt is easier to write the attack software for, but this can be done against Linux encryption as well with additional effort. The BIOS can also be reflashed, but this requires someone who knows how to reflash the BIOS on the exact machine in question and is considerably more difficult. This is known as the “evil cook” attack due to the requirement for a skilled operative to carry it out.
UPDATE 12-29-2013: To this date the “evil maid” attack has NOT been detected in operational use as opposed to hackers playing games on oneanother. Instead, the Chinese MSS has been caught taking laptops apart to insert hardware keyloggers, a more reliable but more time consuming process. The FBI is believed to do the same. If you must leave an encrypted laptop unattended, consider gluing down the keyboard to prevent this. On desktops, watch for any “adapters” added where the keyboard plugs into the back. Machines handling material that any government would classify “Top Secret” should be bought with cash, never be connected to any network, and never have Windows activated. It is known that computers ordered by foreign governments and embassies from US manufacturers have had bugged hardware substituted, and there are those who suspect the NSA of planting firmware or hardware routines in motherboards that can be remotely turned on but must never be admitted to in any courtroom for fear of harming the computer industry. I consider that attack unlikely, but the Guardian folks handling the Snowden take used a randomly-purchased, never-networked machine for decrypting the take. Assume they knew what they were doing at this level.
None the less, the “evil maid” attack as well as the malicious BIOS reflash known as an “evil cook” attack remain theoretical possiblities that may appear in the field as defenses against hardware keyloggers proliferate. The “evil maid” attack does NOT require advance knowledge of the hardware used nor any additional hardware, and only plugging a hardware keylogger into a desktop keyboard cable is easier for an untrained hired party to do.
Defenses against the “Evil Maid” software keylogger
There are two ways to stop the “evil maid” attack: keeping your boot partition on a flash drive you carry at all times, or using a checksum value of the boot sector and boot partition to detect it and change you passphrase. The evil maid attack requires access twice, with you unlocking the disk in between and not changing the passphrase and remaking the encrypted volume(in the case of LUKS or other systems where your passphrase encrypted a volume key).
The only totally(as far as we know)secure defense is to copy /boot onto a flash drive, install GRUB on that drive, and debug this until you can boot from the flash drive with the encrypted disk as the root filesytem.
This is very secure, but slows things down if you like to quickly boot a cheap netbook.
Therefore, an DC area activist has developed this boot checking system described below.WARNING-it is possible to defeat this code by a more sophisticated evil maid attack than anything yet published, I’m not going to tell you how to do this
This defense against currently-published “evil maid” attacks requires that you edit your /etc/fstab to exclude your /boot partition from auto mounting at boot, and you must mount it manually and re-run the update script if you update software affecting booting (kernel or update-initramfs). This is the main disadvantage, but is simpler than keeping /boot on a flash drive. If you detect tampering, you MUST remake the entire encrypted disk with new keys, as a passphrase change protects only against simple attacks to log the passphrase and not more sophisticated attacks like modifying the Cryptsetup binary to log the LUKS decryption key as well as the passphrase.
The Evil Maid Detection Software
Here are the scripts for boot checking and boot updating: Use them, hack them, evaluate them, try to beat them if you play with evil maid-then try to fix them to block your attacks, posting your results here.
NOTE: REPLACE (to) with right carrot for shell redirection as that character (above the period key with caps selected) is a prohibited character in this page due to html interaction You can do this with the “replace” function in gedit, the default text editor (not word processor) in Ubuntu and other GNOME desktop distros. These scripts assume you are using only one disk, or that /dev/sda is the disk containing your root filesystem or at least the /boot partition. Edit them to reflect the difference if you have /boot on something else.
“##Boot_Integrity_Check.sh
#! /bin/bash
xmessage -c -timeout 2 “Checking for boot password keyloggers…”
# Get boot sector hash for 512 B boot sector
mkdir -p /tmp/booted
dd if=/dev/sda of=/tmp/booted/bootsectorimage bs=512 count=1
shasum /tmp/booted/bootsectorimage (to)/tmp/booted/bootsector
rm /tmp/booted/bootsectorimage
#Get hash for boot partition as booted
shasum /dev/sda1(to) /tmp/booted/bootpartition
#Set shell variables for booted hashes
SECTORIMAGE=$(head -c 32 /tmp/booted/bootsector)
PARTITION=$(head -c 32 /tmp/booted/bootpartition)
#Set shell variables for known good hashes
KNOWNSECTORIMAGE=$(head -c 32 /home/$USER/.boot_integrity/bootsector)
KNOWNPARTITION=$(head -c 32 /home/$USER/.boot_integrity/bootpartition)
# Test Known against booted hashes
if test $SECTORIMAGE != $KNOWNSECTORIMAGE ; then
xmessage -c “WARNING-BOOT SECTOR HASH MISMATCH-a password logger may be present in boot loader ”
else
xmessage -c -timeout 2 “BOOT SECTOR CHECK OK”
fi
if test $PARTITION != $KNOWNPARTITION;
then
xmessage -c “WARNING-BOOT PARTITION HASH MISMATCH-a password logger may be present in bootloader stages, kernel or initramfs”
else
xmessage -c -timeout 2 “BOOT PARTITION CHECK OK”
fi
exit 0
##########################
##Boot_Integrity_Update.sh
#Check boot partition filesystem as it cannot be checked at boot
sudo umount /boot
sudo e2fsck /dev/sda1
#make directory for shasums of boot sector and boot partition
mkdir -p /home/$USER/.boot_integrity
#create image of boot partition
sudo dd if=/dev/sda of=/home/$USER/.boot_integrity/bootsectorimage bs=512 count=1
#save shasum of boot sector in ~/boot_integrity
sudo shasum /home/$USER/.boot_integrity/bootsectorimage (to)/home/luke/.boot_integrity/bootsector
#cleanup
sudo rm /home/$USER/.boot_integrity/bootsectorimage
#save shasum of boot partition in ~/boot_integrity
sudo shasum /dev/sda1 (to) /home/$USER/.boot_integrity/bootpartition
DC Direct Action News 
You’ve made a very good entry.
If it’s fine with you, I would like to seek permission to use your article as it relates to my topic. I will be happy to negotiate to pay you or hire you for this.
With Regards from
Republic Polytechnic
There is no copyright on anything here-feel free to use it.
I have been followed at one point by the FBI or another government authority. I have many reasons to believe I still am being monitored electronically.
I created a 13.10 Ubuntu install CD. Before I created the CD I verified the downloaded ISO hash. I installed the OS onto my Dell Inspiron N5010. Boot partition is unencrypted, rest of sda is default LVM encrypted. At some point I left the laptop at home unattended.
I installed your boot scripts, updated my system via apt and installed the Ubuntu debsums command. At that point a debsums check showed my linux kernel package 3.11.0-12 package did not match. I quickly did a reinstall of this package. Note I have a later kernel in the boot directory on my machine …-15.
I installed VirtualBox, then using the same Ubuntu 13.10 installation DVD which has always had my handwritten signature I installed the OS into a virtual machine. Two Linux kernels appear the -12 and -15. The -12 though isn’t a bin file as the bare metal install on my hard disk though, it registers as a DOS executable. Debsums shows no errors for the kernels but two errors for setuid and setguid.
There’s only so much you can do to prevent getting hacked. I lose things constantly – an encryption key on a USB will get lost. I think your statement about not seeing any boot partition related hacks is invalid.
All hacking is an arms race. “Evil maid” attacks have been done by hackers on hackers (that’s how they were developed), but have never been seen in a courtroom or from cops/FBI as far as anything I have heard about. China is famous for attacks on encrypted laptops, but the MSS favors hardware keyloggers that can go almost as fast into some laptops whose keyboards snap out from the top in the hands of a skilled “repairman.” More reliable, less detectable. The NSA is known to favor intercepting machines ordered by known enemies to install a custom BIOS, no doubt one that does not show itself with extra files in the OS.
Who do you live with? If you are in a multi-hacker household, that linux 3.15 could be a housemate’s custom kernel with anything they want in it. This is not the kind of evil maid published in 2600, but is actually more sophisticated. Counter to a kernel-replacement and boot menu update only attack would have been to always use your boot menu and boot only kernels you knew you had installed.
That way the attacker must guess your kernel version. Also, you should be unable to load any kernel modules if you booted a kernel not present in your encrypted disk-this would be obvious unless the alternate kernel was compiled with all likely modules built-in. Once booted, the attack has run: you must replace both the OS and the encryption keys (not just the passphrase as you don’t know what if anything was logged/transmitted).
There is no -15 kernel at this writing, the latest kernel in pre-release development is linux 3.13. You will have different files after any update, but I’ve never heard of a Linux 3.15 kernel. Nemo/Nautilus sometimes calls a kernel a DOS executable as it is a standalone executable file somewhat like a .com file used to be: one that can run on true bare metal directly from a bootloader
For anyone getting attack files in a virtual machine only, the host installation becomes the immediate suspect. If a new install from a known good installer on bare metal with no network connection shows any files not present on the installer, that would make the BIOS/UEFI the suspect. A BIOS reflash by a 3ed party is an “evil cook” attack due to the extra effort installed.
Whatever you used to detect attack did its job, preventing another attack is a different job. Also consider this: if you are part of a hacker community and people are “playing” with each other, their tools may be fancier than those of the FBI and NSA, as they have a lot less to lose from detection. You can take more chances in a game than in real life!
The real point is this: If you are attacked and detect an evil maid, evil cook, whatever prior to a raid to get your hard drives, you can wipe or re-key and make the attack totally useless. In a hacking contest the other hacker wins, but in insurgents vs cops the cops still lose, because the payload is being able to read the disks after a raid.