I recently replaced my OSX based Macbook with an Ubuntu based Lenovo Thinkpad T420. I've done a number of things out of the ordinary to secure it, so thought I'd write an overview. You may find some of these techniques interesting, and maybe even useful. You may even learn about an attack or two that you were unaware of.
Defending from common thieves
My most likely adversary is the common thief. If my laptop is stolen, I want a chance to recover it, that doesn't involve relying solely on the police. Although the laptop came with Windows 7 installed, I had no intention of using it; Ubuntu is my current operating system of choice for laptops/desktops. Rather than wiping Windows 7, I've left it as a honeypot operating system. If a thief steals the laptop, when they turn it on, it will automatically boot up into Windows, without so much as even being prompted for a password. I installed a free application called Prey which will allow me to grab loads of information from the laptop, such as its location, and pictures from the built in webcam. The location is pretty accurate because the laptop came with an F5521gw (pdf) card, which provides GPS and 3G modem capability, and Prey is happy to take advantage of GPS data. Incidently this card also works fine under Linux using MBM. Hopefully, the thief will be too lazy or too dumb to do an immediate full reinstall of the OS, as it will just work out of the box as far as they're concerned.
To make room for Ubuntu on the disk, I installed GParted to a USB stick and booted that up. This allowed me to shrink the Windows 7 partition. The laptop only has a small 128GB drive though (SSD) so I had to try and recover as much space as possible. From Windows 7 I deleted the recovery partition, I disabled system restore, and I disabled swap. Disabling the swap file recovered a massive 8GB of space as the machine has 8GB of RAM.
Defending from experts
In the space recovered from Windows, went my Ubuntu installation. Natty Narwhal (11.04) was the latest version of Ubuntu at time of writing, so that's what I went with. I consider full disk encryption to be essential if you want to secure your laptop. However, there are several attacks against machines that use full disk encryption; I decided to address as many of them as possible.
Evil maid attacks
Even if you have a machine which uses full disk encryption, the boot partition and boot loader need to be stored somewhere unencrypted. Typically, people store it on the hard drive along with the encrypted partitions. The problem with doing this is, whenever you go to your machine, you don't know if somebody has tampered with the unencrypted data to install a software keylogger to capture your password. To get around this, I installed my boot partition and boot loader on a Corsair Survivor USB stick. I wanted a USB stick which would never leave my side. This particular USB stick is very strong, and water proof, so even when I go swimming or scuba diving, I don't need to leave it in a locker somewhere, unattended. I got one of my friends to take it on a scuba diving holiday before I used it. It survived several hours under the water at depths of between 10 and 15 metres.
Coldboot attacks
On a typical system with disk encryption, the encryption key is stored in RAM. This would be fine, if it weren't for the fact that there are several ways for an attacker with physical access, to read the contents of the RAM on a machine which is running, or which has been running recently. You might think that your machine's RAM is wiped as soon as it loses power, but that is not the case. It can take several minutes for the RAM to completely clear after losing power. Cooling the RAM with spray from an aircan, can extend that time period.
An attacker with access to the online machine, could simply hard reboot the machine from a USB stick or CD containing msramdmp to grab a copy of the RAM. You could password protect the BIOS and disable booting from anything other than the hard drive, but that still doesn't protect you. An attacker could cool the RAM, remove it from the running machine, place it in a second machine and boot from that instead.
The first defence I used against this attack is procedure based. I shut down the machine when it's not in use. My old Macbook was hardly ever shut down, and lived in suspend to RAM mode when not in use. The second defence I used is far more interesting. I use something called TRESOR. TRESOR is an implementation of AES as a cipher kernel module which stores the keys in the CPU debug registers, and which handles all of the crypto operations directly on the CPU, in a way which prevents the key from ever entering RAM. The laptop I purchased works perfectly with TRESOR as it contains a Core i5 processor which has the AES-NI instruction set.
Getting TRESOR to work was the most complicated part of installing my laptop. Not because it's particularly difficult, but because you have to build a custom kernel, with the TRESOR patch applied. And once you've got the custom kernel, you need to build custom installation media which uses that kernel. I did a basic Ubuntu installation without encryption to create a platform for building the custom kernel and custom installation media. Once I had the install CD ready, I did a second installation over the top of the first one using that CD instead. I'm not going to go into detail on how to do that, but I will link to the various HOWTOs that I used:
Building a custom Ubuntu Kernel Package
More about building a custom kernel package, but with some useful info about using custom flavours
Patching the kernel with TRESOR
Building a custom Ubuntu Live CD
Attacks via firewire
If a machine has a firewire port, or a card slot which would allow an attacker to insert a firewire card, then there's something else you need to address. It is possible to read the contents of RAM via a firewire port. Here is a great article detailing the issues and fixes for multiple operating systems. My laptop has a firewire port. I could have built a kernel without support for firewire and without firewire kernel modules, but I may need to use that port at some point. So instead, I built firewire as a set of kernel modules, and prevent the modules from loading under normal circumstances using /etc/modprobe.d/blacklist.
Preparing a disk for encryption
During my research, I found numerous people advocating that you should completely wipe a new hard drive with random data before setting up disk encryption. This is to make it impossible for somebody to be able to detect which parts of the drive have had encrypted data written to them. Doing this, is as simple as creating a partition on the space you want to fill with random data, and then using the "dd" command to copy data directly to that partition device in /dev/ from /dev/urandom. This took a few hours to run on my system. I complicated this procedure slightly by using something I purchased called an EntropyKey. The EntropyKey provides a much larger source of "real" random data, as opposed to the much more limited "pseudo" random data that is generated by the operating system. It talks to an application called ekeyd in order to feed /dev/random directly. I also use the entropy key when generating GnuPG keys and any other task which requires a source of good random data.
More on disk encryption
The LiveCD I modified doesn't have a nice GUI for handling full disk encryption. I needed to learn how to use the command line tool "cryptsetup" to set up encryption. Because TRESOR is built as a cipher kernel module, once you've booted from your custom LiveCD, you can just use the option "--cipher tresor" when using cryptsetup to create encrypted devices. It's worth spending some time playing with this tool and understanding what the various options do, if you don't want to lose access to your encrypted device.
When I initially did the installation, I chose to protect the full disk encryption key with a passphrase. It is also possible to protect it with a keyfile. The advantage of using a keyfile is that you can store it on an external device. An attacker can't just observe you entering the password, they also need to get hold of the keyfile. It's also much more difficult to brute force. I have now moved my laptop to using a keyfile. That keyfile is stored on the USB boot stick which never leaves my side, and it is GPG encrypted. Cryptsetup on Ubuntu comes with helper tools to do this. The basic process was:
The update-initramfs command calls a hook script which copies the gpg binary, gpg protected key, and appropriate boot scripts to the initrd on the boot partition. Once I'd confirmed that I can still successfully boot the machine, I emptied the key slot which contained the original passphrase. It would now be impossible to compel me to decrypt my hard drive if I were to lose, "lose", or irreperably damage my USB boot drive.
Swap
If you need to use swap. Make sure it is encrypted too. The easiest way to make sure everything is encrypted is to create an encrypted device, and then use LVM on top of that so that all of your partitions and swap end up on top of the same encrypted device. As this laptop has 8GB of RAM, I decided to go without swap altogether. I'm not going to be using the suspend to disk function which requires swap, and I don't want swapping to cause wearing on my SSD.
Trusted Platform Modules
The laptop I purchased has something called a Trusted Platform Module. This TPM can handle a number of crypto operations it's self. It also provides a random number generator similar to the EntropyKey. Apparently a lot of modern laptops contain one of these. I decided to use the random number generator on the TPM as another source of entropy for when my EntropyKey isn't inserted. To do this I used a piece of software called TrouSerS. There is also a modified version of Grub calledTrusted Grub which can use the TPM to do a number of integrity checks on the system as it boots. I'm not sure that this is of any use to me though as my boot partition and boot loader will never leave my side.
Securing the Web browser
I use Firefox as my web browser. Surfing the web scares me; the browser strikes me as the most likely way in for a remote attacker. And yet, most people run the browser under the same user id as the rest of their programs. So if the browser is compromised, all of the files that your user can access are also instantly compromised. To try and minimise any damage if this happens, I decided to run Firefox in its own account. My normal user account is called "mike". For Firefox I created a new user account called "mike.firefox". "/usr/bin/firefox" was merely a symlink to /usr/lib/firefox-6.0/firefox.sh so I replaced it with a shell script which runs:
PGP smart cards
All of my incoming email is encrypted using my public GPG key. I detailed how I do this here. This means that I need to store my private GPG keys on my laptop. They're protected by a passphrase, but is this enough? If my account was compromised, an attacker could key log my passphrase and then steal my keys. Luckily, when I purchased my laptop, I ticked the "Smartcard Reader" option. I then purchased an OpenPGP Smartcard. My encryption and signing subkeys have been transferred to the smartcard, and the master key has been removed from my laptop. All that remains in the PGP private keyring on my laptop are stubs which refer to the keys on the smartcard. You can not read a key from a smartcard. If you want to decrypt or sign data, gpg sends that data to the smartcard, which then performs the crypto operations on board, and sends the results back. This isn't perfect of course. An undetected attacker could potentially use the card to decrypt data when it is inserted, without my knowledge. I wrote a custom "pinentry" application to further secure my smartcard, from observation attacks. You can read about that here.
Miscellaneous
I use the following Firefox addons to minimise the chance of MITM attacks against my browsing, and to prevent most XSS/CSRF attacks: Certificate Patrol, Cipherfox, DNSSEC Validator, HTTPS Everywhere, HTTPS Finder, NoScript, Perspectives and Request Policy.
I have installed OpenVPN. It connects to my Linode VPS and I route all traffic over it when I'm on untrusted networks such as cafes.
I installed a local DNS resolver called Unbound. It supports DNSSEC. I don't know how many sites support DNSSEC yet, but I should benefit more from this as time goes on.
I installed an application called blueproximity. It detects when my phone is in range, via bluetooth. If my phone moves out of range, the screen automatically locks. I've no doubt that this can be prevented via spoofing my phone, but it adds another layer of security.
My Windows honeypot also has a VPN to my Linode server, and Internet Explorer is configured to use the web proxy at the end of it. If my laptop is stolen, I should be able to intercept all of the browser traffic that comes from it.
Summary
Some people might say that many of these precautions are over the top and paranoid. I don't consider myself an "elite hacker", but I know that I could pull off most of the attacks that I've discussed above without much trouble. Cold boot and Evil maid are practical, easy to pull off, attacks. Why wouldn't I defend against them?
I'm not claiming that my laptop is impenetrable. An attacker could still grab me when I'm using the machine, rip the RAM out, and pull sensitive data from it. They could still grab my USB boot key and then beat the password out of me. They could still remotely compromise Firefox and then use an unknown kernel exploit to gain root privileges. The whole point of this exercise was to reduce the number of attack vectors, not eliminate them. That would be impossible.
If you do anything differently, or better, please let me know in the comments. I'd especially love to hear ways that I can make my Windows honeypot more effective.
My most likely adversary is the common thief. If my laptop is stolen, I want a chance to recover it, that doesn't involve relying solely on the police. Although the laptop came with Windows 7 installed, I had no intention of using it; Ubuntu is my current operating system of choice for laptops/desktops. Rather than wiping Windows 7, I've left it as a honeypot operating system. If a thief steals the laptop, when they turn it on, it will automatically boot up into Windows, without so much as even being prompted for a password. I installed a free application called Prey which will allow me to grab loads of information from the laptop, such as its location, and pictures from the built in webcam. The location is pretty accurate because the laptop came with an F5521gw (pdf) card, which provides GPS and 3G modem capability, and Prey is happy to take advantage of GPS data. Incidently this card also works fine under Linux using MBM. Hopefully, the thief will be too lazy or too dumb to do an immediate full reinstall of the OS, as it will just work out of the box as far as they're concerned.
To make room for Ubuntu on the disk, I installed GParted to a USB stick and booted that up. This allowed me to shrink the Windows 7 partition. The laptop only has a small 128GB drive though (SSD) so I had to try and recover as much space as possible. From Windows 7 I deleted the recovery partition, I disabled system restore, and I disabled swap. Disabling the swap file recovered a massive 8GB of space as the machine has 8GB of RAM.
Defending from experts
In the space recovered from Windows, went my Ubuntu installation. Natty Narwhal (11.04) was the latest version of Ubuntu at time of writing, so that's what I went with. I consider full disk encryption to be essential if you want to secure your laptop. However, there are several attacks against machines that use full disk encryption; I decided to address as many of them as possible.
Evil maid attacks
Even if you have a machine which uses full disk encryption, the boot partition and boot loader need to be stored somewhere unencrypted. Typically, people store it on the hard drive along with the encrypted partitions. The problem with doing this is, whenever you go to your machine, you don't know if somebody has tampered with the unencrypted data to install a software keylogger to capture your password. To get around this, I installed my boot partition and boot loader on a Corsair Survivor USB stick. I wanted a USB stick which would never leave my side. This particular USB stick is very strong, and water proof, so even when I go swimming or scuba diving, I don't need to leave it in a locker somewhere, unattended. I got one of my friends to take it on a scuba diving holiday before I used it. It survived several hours under the water at depths of between 10 and 15 metres.
Coldboot attacks
On a typical system with disk encryption, the encryption key is stored in RAM. This would be fine, if it weren't for the fact that there are several ways for an attacker with physical access, to read the contents of the RAM on a machine which is running, or which has been running recently. You might think that your machine's RAM is wiped as soon as it loses power, but that is not the case. It can take several minutes for the RAM to completely clear after losing power. Cooling the RAM with spray from an aircan, can extend that time period.
An attacker with access to the online machine, could simply hard reboot the machine from a USB stick or CD containing msramdmp to grab a copy of the RAM. You could password protect the BIOS and disable booting from anything other than the hard drive, but that still doesn't protect you. An attacker could cool the RAM, remove it from the running machine, place it in a second machine and boot from that instead.
The first defence I used against this attack is procedure based. I shut down the machine when it's not in use. My old Macbook was hardly ever shut down, and lived in suspend to RAM mode when not in use. The second defence I used is far more interesting. I use something called TRESOR. TRESOR is an implementation of AES as a cipher kernel module which stores the keys in the CPU debug registers, and which handles all of the crypto operations directly on the CPU, in a way which prevents the key from ever entering RAM. The laptop I purchased works perfectly with TRESOR as it contains a Core i5 processor which has the AES-NI instruction set.
Getting TRESOR to work was the most complicated part of installing my laptop. Not because it's particularly difficult, but because you have to build a custom kernel, with the TRESOR patch applied. And once you've got the custom kernel, you need to build custom installation media which uses that kernel. I did a basic Ubuntu installation without encryption to create a platform for building the custom kernel and custom installation media. Once I had the install CD ready, I did a second installation over the top of the first one using that CD instead. I'm not going to go into detail on how to do that, but I will link to the various HOWTOs that I used:
Building a custom Ubuntu Kernel Package
More about building a custom kernel package, but with some useful info about using custom flavours
Patching the kernel with TRESOR
Building a custom Ubuntu Live CD
Attacks via firewire
If a machine has a firewire port, or a card slot which would allow an attacker to insert a firewire card, then there's something else you need to address. It is possible to read the contents of RAM via a firewire port. Here is a great article detailing the issues and fixes for multiple operating systems. My laptop has a firewire port. I could have built a kernel without support for firewire and without firewire kernel modules, but I may need to use that port at some point. So instead, I built firewire as a set of kernel modules, and prevent the modules from loading under normal circumstances using /etc/modprobe.d/blacklist.
Preparing a disk for encryption
During my research, I found numerous people advocating that you should completely wipe a new hard drive with random data before setting up disk encryption. This is to make it impossible for somebody to be able to detect which parts of the drive have had encrypted data written to them. Doing this, is as simple as creating a partition on the space you want to fill with random data, and then using the "dd" command to copy data directly to that partition device in /dev/ from /dev/urandom. This took a few hours to run on my system. I complicated this procedure slightly by using something I purchased called an EntropyKey. The EntropyKey provides a much larger source of "real" random data, as opposed to the much more limited "pseudo" random data that is generated by the operating system. It talks to an application called ekeyd in order to feed /dev/random directly. I also use the entropy key when generating GnuPG keys and any other task which requires a source of good random data.
More on disk encryption
The LiveCD I modified doesn't have a nice GUI for handling full disk encryption. I needed to learn how to use the command line tool "cryptsetup" to set up encryption. Because TRESOR is built as a cipher kernel module, once you've booted from your custom LiveCD, you can just use the option "--cipher tresor" when using cryptsetup to create encrypted devices. It's worth spending some time playing with this tool and understanding what the various options do, if you don't want to lose access to your encrypted device.
When I initially did the installation, I chose to protect the full disk encryption key with a passphrase. It is also possible to protect it with a keyfile. The advantage of using a keyfile is that you can store it on an external device. An attacker can't just observe you entering the password, they also need to get hold of the keyfile. It's also much more difficult to brute force. I have now moved my laptop to using a keyfile. That keyfile is stored on the USB boot stick which never leaves my side, and it is GPG encrypted. Cryptsetup on Ubuntu comes with helper tools to do this. The basic process was:
- Generate the keyfile
- Use cryptsetup to add it to an additional key slot on the encrypted device
- Encrypt with gnupg's "--symmetric" option and copy the encrypted version to somewhere like /etc/keys/
- Update /etc/crypttab to use the new keyfile
- Run "update-initramfs -u" to build a new initrd on the boot partition
The update-initramfs command calls a hook script which copies the gpg binary, gpg protected key, and appropriate boot scripts to the initrd on the boot partition. Once I'd confirmed that I can still successfully boot the machine, I emptied the key slot which contained the original passphrase. It would now be impossible to compel me to decrypt my hard drive if I were to lose, "lose", or irreperably damage my USB boot drive.
Swap
If you need to use swap. Make sure it is encrypted too. The easiest way to make sure everything is encrypted is to create an encrypted device, and then use LVM on top of that so that all of your partitions and swap end up on top of the same encrypted device. As this laptop has 8GB of RAM, I decided to go without swap altogether. I'm not going to be using the suspend to disk function which requires swap, and I don't want swapping to cause wearing on my SSD.
Trusted Platform Modules
The laptop I purchased has something called a Trusted Platform Module. This TPM can handle a number of crypto operations it's self. It also provides a random number generator similar to the EntropyKey. Apparently a lot of modern laptops contain one of these. I decided to use the random number generator on the TPM as another source of entropy for when my EntropyKey isn't inserted. To do this I used a piece of software called TrouSerS. There is also a modified version of Grub calledTrusted Grub which can use the TPM to do a number of integrity checks on the system as it boots. I'm not sure that this is of any use to me though as my boot partition and boot loader will never leave my side.
Securing the Web browser
I use Firefox as my web browser. Surfing the web scares me; the browser strikes me as the most likely way in for a remote attacker. And yet, most people run the browser under the same user id as the rest of their programs. So if the browser is compromised, all of the files that your user can access are also instantly compromised. To try and minimise any damage if this happens, I decided to run Firefox in its own account. My normal user account is called "mike". For Firefox I created a new user account called "mike.firefox". "/usr/bin/firefox" was merely a symlink to /usr/lib/firefox-6.0/firefox.sh so I replaced it with a shell script which runs:
sudo -u mike.firefox -H /usr/lib/firefox-6.0/firefox.shI didn't want to be prompted for a password every time I tried to run firefox though, so I configured sudo to allow me to run that command without entering my password by adding this to the end of my /etc/sudoers (use the visudo command to do this)
mike ALL=(mike.firefox) NOPASSWD: /usr/lib/firefox-6.0/firefox.shThe "mike.firefox" user doesn't have access to the X display though when I'm logged in as "mike". To give it access I went to "System->Preferences->Startup Applications" and told it to run the command "xhost +local:mike.firefox" when I log in. Now, when I run firefox, it runs as user mike.firefox instead. Something to look out for when you do this: Any command that firefox spawns, will it's self run as user mike.firefox. I noticed that when playing flash, there was no audio. This is because the mike.firefox user that I created did not have access to the audio device. To give it permission, I ran the command "adduser mike.firefox audio". I also set up permissions so that user "mike" could access "/home/mike.firefox/Downloads" as that is where Firefox will now download to. I symlinked /home/mike/Downloads/firefox to this directory for simplicity.
PGP smart cards
All of my incoming email is encrypted using my public GPG key. I detailed how I do this here. This means that I need to store my private GPG keys on my laptop. They're protected by a passphrase, but is this enough? If my account was compromised, an attacker could key log my passphrase and then steal my keys. Luckily, when I purchased my laptop, I ticked the "Smartcard Reader" option. I then purchased an OpenPGP Smartcard. My encryption and signing subkeys have been transferred to the smartcard, and the master key has been removed from my laptop. All that remains in the PGP private keyring on my laptop are stubs which refer to the keys on the smartcard. You can not read a key from a smartcard. If you want to decrypt or sign data, gpg sends that data to the smartcard, which then performs the crypto operations on board, and sends the results back. This isn't perfect of course. An undetected attacker could potentially use the card to decrypt data when it is inserted, without my knowledge. I wrote a custom "pinentry" application to further secure my smartcard, from observation attacks. You can read about that here.
Miscellaneous
I use the following Firefox addons to minimise the chance of MITM attacks against my browsing, and to prevent most XSS/CSRF attacks: Certificate Patrol, Cipherfox, DNSSEC Validator, HTTPS Everywhere, HTTPS Finder, NoScript, Perspectives and Request Policy.
I have installed OpenVPN. It connects to my Linode VPS and I route all traffic over it when I'm on untrusted networks such as cafes.
I installed a local DNS resolver called Unbound. It supports DNSSEC. I don't know how many sites support DNSSEC yet, but I should benefit more from this as time goes on.
I installed an application called blueproximity. It detects when my phone is in range, via bluetooth. If my phone moves out of range, the screen automatically locks. I've no doubt that this can be prevented via spoofing my phone, but it adds another layer of security.
My Windows honeypot also has a VPN to my Linode server, and Internet Explorer is configured to use the web proxy at the end of it. If my laptop is stolen, I should be able to intercept all of the browser traffic that comes from it.
Summary
Some people might say that many of these precautions are over the top and paranoid. I don't consider myself an "elite hacker", but I know that I could pull off most of the attacks that I've discussed above without much trouble. Cold boot and Evil maid are practical, easy to pull off, attacks. Why wouldn't I defend against them?
I'm not claiming that my laptop is impenetrable. An attacker could still grab me when I'm using the machine, rip the RAM out, and pull sensitive data from it. They could still grab my USB boot key and then beat the password out of me. They could still remotely compromise Firefox and then use an unknown kernel exploit to gain root privileges. The whole point of this exercise was to reduce the number of attack vectors, not eliminate them. That would be impossible.
If you do anything differently, or better, please let me know in the comments. I'd especially love to hear ways that I can make my Windows honeypot more effective.
If you want to read more stuff like this, follow my blog using Twitter, Atom or RSS, and check out the rest of my articles: All, Security related, Web related
If you want to hire me, you can do it through my UK based consultancy: Cardwell IT Ltd.
If you want to hire me, you can do it through my UK based consultancy: Cardwell IT Ltd.
No comments:
Post a Comment