Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

pulsesecurity.co.nz

Post reply on HN
Print view View original

51–60 of 135 posts

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#51

Post by twitchyliquid64 »

A simple fix might be to bind the encrypted value to a PCR (hopefully one that isnt too fragile, but prefs one that measures the initrd) and then to invalidate that PCR when you drop to the recovery shell (by extending some junk bytes to it).

But if you can't find a PCR thats both not too fragile and measures the initrd, then youll have to settle for sealing the encryption key to a fairly static PCR, in which case the attacker could just boot into another OS and then do the right PCR extend dance to get the disk unlock key.

Its the combo of secure boot + disk unlock sealed to a PCR that is meant to get you most of the way there. Agree with other comments that evil-maid style hardware mod attacks are basically impossible to defend against, and practically most ppl attack model this as whether you can pull the disk key in X minutes rather than at all.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#52

Post by jmetzmeier »

alexvitkov wrote: post #22

There's no viable reason to reboot a Linux box. Even for kernel upgrades you have kexec, and there are ways (hacks) to hand over the LUKS keys to the new kernel. If you need to reboot an encrypted box remotely AND have it automatically decrypt without you knowing the key, you've already lost the game.

What about libc updates? If you need to restart effectively every process on the system anyways, why not reboot?

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#53

Post by jsmith99 »

gameoverhumans wrote: post #31

Meh, it's an interesting exploit for sure (the USB key simulating Enter key being pressed every 15ms is cute). But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. In a hardened setup you lock down the emergency initrd shell - either it's not allowed at all, or it uses…

That just defeats secure boot, it doesn't defeat TPM backed drive encryption, which only releases the key if the OS is unchanged, otherwise you could just defeat it by booting a different signed OS.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#54

Post by jsmith99 »

hollerith wrote: post #48
gameoverhumans wrote: post #31

Meh, it's an interesting exploit for sure (the USB key simulating Enter key being pressed every 15ms is cute). But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. In a hardened setup you lock down the emergency initrd shell - either it's not allowed at all, or it uses…

>But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?

The code that displays the password prompt and unlocks the disk could be replaced by a modified copy as it isn't encrypted. TPM would protect against that though.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#55

Post by LinuxBender »

ddtaylor wrote: post #43
Galanwe wrote: post #37

The best hacker I know is my 12 month old. Give him any kind of device for 2 minutes and you will discover a plethora of UI issues, hidden menus, and security bypasses.

I came home one day and my cat was laying on my keyboard. Above her was a screen with a large amount of random control characters in a terminal with a kernel panic screen. So there's some series of buttons you can press that will crash a Linux desktop from a lock screen.

Possibly sysrq if you have the key + c or m [1]. Good kitty.

[1] - https://www.kernel.org/doc/Documentation/admin-guide/sysrq.r...

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#56

Post by alexvitkov »

TeMPOraL wrote: post #35
alexvitkov wrote: post #22

There's no viable reason to reboot a Linux box. Even for kernel upgrades you have kexec, and there are ways (hacks) to hand over the LUKS keys to the new kernel. If you need to reboot an encrypted box remotely AND have it automatically decrypt without you knowing the key, you've already lost the game.

> There's no viable reason to reboot a Linux box. Even cosmic rays flipping bits in your RAM in a way that can't be recovered from?

If that's a big issue for you consider using ECC memory, or even better - colocating your servers in an abandoned mine.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#57

Post by michaelt »

hollerith wrote: post #48
gameoverhumans wrote: post #31

Meh, it's an interesting exploit for sure (the USB key simulating Enter key being pressed every 15ms is cute). But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. In a hardened setup you lock down the emergency initrd shell - either it's not allowed at all, or it uses…

>But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?

If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot.

The evil maid attack on an encrypted disk with a passphrase is that the attacker installs a hardware keylogger, then comes back the next day and snatches your laptop, which the keylogger tells them the password for.

If you've got highly sensitive chassis intrusion detection that wipes your secrets at the drop of a hat, the evil maid triggers it in a way that looks like a false alarm, and uses a hidden camera in the ceiling to watch your recovery procedure.

And if you would never be so naive as to have a recovery procedure, the attack is to laugh their ass off because you needed that laptop to give the conference talk / client demo you came to this city for, and it also had your boarding pass on it, and now you're fired and you're stranded.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#59

Post by gameoverhumans »

hollerith wrote: post #48
gameoverhumans wrote: post #31

Meh, it's an interesting exploit for sure (the USB key simulating Enter key being pressed every 15ms is cute). But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. In a hardened setup you lock down the emergency initrd shell - either it's not allowed at all, or it uses…

>But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?

In my view, a setup where you are forced to enter a decent-quality disk-unlock passphrase on every cold boot is a rather hardened setup. The problem is, this is awful UX. If something causes a lot of friction, folks tend to just avoid that thing. And that's why many people just bind the disk encryption key to their TPM and call it a day. Thus leading to the exploit detailed in the parent article.

Once you have physical access to a computer, the sky really is the limit on the kinds of exploits (both hardware and software) you can execute on an unsuspecting victim.

Disk password and no TPM binding? `dd` the entire contents of the victim's disk to an external disk. Then infect the bootloader so that the early initrd (which is responsible for that disk password prompt) will send the key to you as soon as network connectivity is established. Game over.

Secure boot? Pwn it with something like the technique I explained already.

Actually good secure boot (custom PK+MOK and a locked down BIOS config)? Pop the laptop lid, solder some wires (or in some cases, just a SOIC clip) to the BIOS flash chip (example: https://forum.phala.network/t/topic/2584), dump the BIOS, flash an insecure one, then do the same bootloader trick already described.

Of course depending on how hardened the computer being attacked it, the attacks get more sophisticated, but if someone is at the point where they're invading your physical boundaries and messing with your hardware in person, they're probably willing and capable to deploy fairly sophisticated attacks?

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#60

Post by gameoverhumans »

jsmith99 wrote: post #53
gameoverhumans wrote: post #31

Meh, it's an interesting exploit for sure (the USB key simulating Enter key being pressed every 15ms is cute). But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. In a hardened setup you lock down the emergency initrd shell - either it's not allowed at all, or it uses…

That just defeats secure boot, it doesn't defeat TPM backed drive encryption, which only releases the key if the OS is unchanged, otherwise you could just defeat it by booting a different signed OS.

That depends on which PCRs you bind your TPM-backend encryption key to. See this list: https://uapi-group.org/specifications/specs/linux_tpm_pcr_re...

As an example, Arch Wiki encourages you to bind to PCR 0+7: https://wiki.archlinux.org/title/Trusted_Platform_Module#sys... ... both of those are firmware-level PCRs, not OS ones.

Post reply on HN