Recently, I’ve browsed several how-to’s regarding the possibility of unlocking a LUKS root volume remotely using an SSH connection. For reference, the first of its kind is the one for Debian, published at Coulmann.de. Some of these how-to’s were posted to forums and mailing-lists and received many thankful comments from sysadmins wondering how to make their encrypted secure setup also easy to administrate.
The problem with their approach is simple: they asked how to fix their setup, but forgot to ask what they’re trying to protect. Having your root filesystem on an encrypted disk doesn’t protect you from remote exploitation or credential leaks. It just protects you from the risk of someone being able to access your machine locally and steal your data, or just steal the whole machine altogether. Now, if I were an attacker having access to your hardware locally, I could easily setup a trap for you in less than 5 minutes:
- Shut down your machine and open it.
- Connect your machine’s root disk to an external USB interface connected to my laptop.
- Copy your initramfs file from boot partition (which is clear-text, remember?), access internal files and extract SSH server keys.
- Bring up an interface with a fake ssh server running on my laptop which runs your initrd script, slightly modified to tap passwords.
- Just wait for you to notice your machine went down and connect via ssh to bring it back up. Ta-da.
Depending on the scenario, some additional step covering may be necessary, but the theory is there: if you can’t check your hardware personally, disk encryption is useless (and even then, human stupidity is the weak link).
In 2004, Autistici/Inventati hacking group was running a server at Aruba server farm and hosting several mailboxes and websites. During a police inquiry on one of those mailboxes, law officers wanted to obtain TLS encryption keys to tap users messages, so they unplugged the server and copied data from the server volumes. When server admins asked Aruba about the downtime, Aruba told them it was an electrical fault, so it took one year to find out about the crackdown. If disks had been encrypted with LUKS and set up for remote unlocking, it would have been quite easy for law officers to trick server admins into typing unlock key over the wire, since ISP employees were under their control.
Bottom line: if you’re paranoid enough to setup encrypted disks, you shouldn’t really trust remote unlocking anyway.
5 Comments
Good point, absolute security is a myth, anyway.
However :
1) In your scenario, if “they” hold sufficient knowledge to set up such a trap, wouldn't “they” try first a cold boot attack ?
2) How about the basic burglary scenario ? Don't fences get more organised every day, trying to get the most out of stolen items, by recovering data from electronic devices ? Forensic tools are getting more popular and accessible nowadays, using them require less and less technical knowledge.
For this second, much more frequent scenario I suppose, can you see any other countermeasure than encrypting the whole system, including swap & var ?
Let's consider privately hosted servers (at company premises or at home), typically stolen over night. Or a bench of laptops, granted to employees, while basic administration tasks, including reboots, need to be performed by the system administrator over LAN or VPN. Shouldn't all these systems be fully encrypted AND offer remote reboot to sysadmins ?
Well,
you haven't thought about a second option.
If this would have to go unnoticed and the modified initrd script would have to unlock the disks for real, the newly unlocked and starting OS could check the disks' plaintext data against an encrypted copy, or rewrite it altogether, or again check that no other storage device is connected to the pc else wipe it securely (or other things). If instead the initrd acts just as a fake interface without really unlocking the disk, you could try to insert a purposedly wrong password before to see if it gets accepted, proving the attack, or rejected with delays, proving the attack too.
Well,
you haven't thought about a second option.
If this would have to go unnoticed and the modified initrd script would have to unlock the disks for real, the newly unlocked and starting OS could check the disks' plaintext data against an encrypted copy, or rewrite it altogether, or again check that no other storage device is connected to the pc else wipe it securely (or other things). If instead the initrd acts just as a fake interface without really unlocking the disk, you could try to insert a purposedly wrong password before to see if it gets accepted, proving the attack, or rejected with delays, proving the attack too.
very pleasure to visit this site. nice post. thanks for sharing.
Found this while looking for a howto on this subject. I just wanted to point out that someone who is paranoid enough to encrypt everything on their server may also have some type of video surveillance on it as well.
One Trackback
[...] LUKS mermaids of remote unlock [...]