[HN Gopher] Mashing Enter to bypass full disk encryption with TP...
___________________________________________________________________
Mashing Enter to bypass full disk encryption with TPM, Clevis
dracut and systemd
Author : LinuxBender
Score : 124 points
Date : 2023-09-01 15:01 UTC (7 hours ago)
(HTM) web link (pulsesecurity.co.nz)
(TXT) w3m dump (pulsesecurity.co.nz)
| kaylynb wrote:
| The article title is very misleading. This isn't bypassing FDE in
| any way. It's just getting a root shell on a machine you have
| physical access to with a particular boot configuration.
|
| Clever? Yes. But no encryption is bypassed.
|
| Most systems will only be listening to PCR 7 anyway, so a similar
| attack could be done by loading your own custom bootloader, or
| possibly reading messages on the SPI bus when booting. This is
| just a nice trick that's easier/faster.
|
| There is a balance of convenience versus security and this could
| be prevented easily by disabling recovery shell or registering
| more PCRS (with correct boot setup), but would be much more
| annoying to remotely administer since you could get failure
| states where the TPM won't release the keys in a variety of
| situations.
|
| Ultimately TPM-only unlock is a significant increase in security
| vs unsophisticated attackers and probably fine for 99% of people,
| but isn't something to rely on if you are concerned about
| sophisticated attackers.
|
| Even with perfect PCR setup and enrolling only custom keys in
| UEFI, a running machine is still vulnerable. Cold boot or DMA
| attacks (Thunderbolt or PCI) are just a few that come to mind.
| These sound extremely sophisticated but are easily done even with
| hobbyist equipment. Any running machine with currently unlocked
| disks should be assumed to be possible to compromise with
| physical access.
|
| If interested in Linux boot chain Poettering has a good read:
| https://0pointer.net/blog/brave-new-trusted-boot-world.html
|
| There are a lot of interesting talks around Linux boot security
| in the upcoming _All Systems Go!_ conference: https://all-
| systems-go.io/
|
| Microsoft has info regarding boot security in _BitLocker
| Countermeasures_ : https://learn.microsoft.com/en-
| us/windows/security/operating...
| tedunangst wrote:
| Additional prior art: https://www.jwz.org/blog/2021/01/i-told-
| you-so-2021-edition/
| hedora wrote:
| They suggest modifying the kernel commandline to disable the root
| fallback. Does secure boot include a hash of grub boot
| parameters? Couldn't the attacker just change the command line
| back (or to an even easier to exploit config?)
| gameoverhumans wrote:
| In a "properly" hardened setup, you would protect the GRUB
| command line with ... yet another password! :)
| https://help.ubuntu.com/community/Grub2/Passwords
|
| But see my sibling comment about the possibilities of trivially
| bypassing Secure Boot.
| hedora wrote:
| Grub passwords don't protect against the attack I was
| thinking of, since you can just pop the drive + edit the grub
| config:
|
| "Errors in creating a password-protected GRUB 2 menu may
| result in an unbootable system. To restore a system with
| broken passwords, access and edit the GRUB 2 configuration
| files using the LiveCD or another OS."
|
| However, it didn't occur to me that you can just press "e" at
| the grub prompt, then modify the command line without
| physical access. "Trivial" indeed.
| temp_gnuser wrote:
| I have long advocated for disabling tpm in bios, uefi-boot raw
| dm-crypt to even get grub much less init. This is also how I have
| done encrypted disks in the cloud using dropbear ssh as an
| initram shim for key/pass entry. Bios boot pass is annoying but
| required. Watch your acess/auth logs. Run a HIDS. Isolate your
| procs and especially their network comms. Security is an onion,
| not that most c-suites have any idea these days, blinded by fast
| talkers.
| jiveturkey wrote:
| if security is an onion, why do you advocate for throwing the
| baby out with the bathwater?
| Galanwe wrote:
| 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.
| ddtaylor wrote:
| 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.
| wolfgang42 wrote:
| My favorite bug report in this vein:
| https://bugs.launchpad.net/ubuntu/+source/unity-
| greeter/+bug...
|
| > Steps to reproduce:
|
| > 1. Leave laptop unattended in a cold room with a warm cat.
|
| > 2. Cat will sit on laptop keyboard.
|
| > 3. Wait 1 hour.
|
| > 4. Lightdm will become unresponsive.
|
| Also included: "Alternative steps to reproduce if cat is
| unavailable or uncooperative about being placed on keyboard
| (see attached pictures)"
| buildbot wrote:
| At least for my cat and sad surfacebook Windows machine, I
| figured it was the device literally cooking it's ram into a
| bitflip that caused it to bsod. The cat loves how toasty it
| gets!
| trelane wrote:
| > I figured it was the device literally cooking it's ram
| into a bitflip that caused it to bsod.
|
| Funny, that's _exactly_ how I push "control" in emacs.
|
| Ref: https://xkcd.com/1172/
| LinuxBender wrote:
| Possibly sysrq _if you have the key_ + c or m [1]. Good
| kitty.
|
| [1] - https://www.kernel.org/doc/Documentation/admin-
| guide/sysrq.r...
| betaby wrote:
| I don't see any encryption bypass there. Encrypted partition
| stays encrypted.
| LinusU wrote:
| Did you read the article? ;)
|
| > From here it's easy to manually use the TPM to unlock the
| disk with the Clevis tooling and mount the root volume for
| hacking (it takes a few tries sometimes, but it gets there in
| the end):
|
| They use the exploit to get dropped into a root shell, and then
| asks the TPM to unlock the disk for them, which it promptly
| does.
| Guvante wrote:
| Technically, but really the fault lies in the OS for
| providing an exploitable prompt that doesn't break the chain
| of custody of the boot process on failure.
| rlpb wrote:
| Ubuntu developer here. I don't think that's fair. The OS,
| as shipped today, isn't designed with this threat model in
| mind. It's correct to say that for TPM-based LUKS unlock to
| be safe, the initramfs must not allow the user to take
| control of it. But that's a new requirement introduced when
| the user modified their system to configure TPM-based LUKS
| unlock. This isn't the responsibility of an OS that doesn't
| ship with that support, and in fact, prior to TPMs, it was
| perfectly reasonable to allow the user to take control of
| the initramfs prior to LUKS unlock!
|
| That's not to say that an improvement can't be made as we
| move towards a future where TPM+LUKS might be the norm -
| just that you can't retrospectively claim fault on an OS
| that doesn't claim to support that.
| Guvante wrote:
| I think it is fair to say that OS configuration to fix
| this should be required.
|
| I agree with the logic that by default the OS is doing
| the right thing without any changes to support this
| model.
| AshamedCaptain wrote:
| > This isn't the responsibility of an OS that doesn't
| ship with that support, and in fact, prior to TPMs, it
| was perfectly reasonable to allow the user to take
| control of the initramfs prior to LUKS unlock!
|
| And it still is perfectly reasonable behavior. Any
| distribution that decides (perhaps as a consequence of
| this) that on any boot process abnormality the default
| response is to enter an immediate reboot loop would be
| called crazy.
| phoronixrly wrote:
| Sorry but Clevis (similarly to bitlocker without PIN) is
| security theatre.
| formerly_proven wrote:
| This is one of those designs where you skim a description
| and already know it's going to break in a million different
| ways.
| AshamedCaptain wrote:
| I still don't understand why people believe that you can
| have any expectation in these ludicrous scenarios.
|
| Like, you are dropping a general purpose computer into
| the middle of Russia, expect to be able to command it
| remotely to do anything, even remotely update it and
| reboot it; and at the same time never bother to come
| check it up in person or even have minimum chassis
| intrussion detection. Do people really expect this to
| work just by adding some TPM craziness?
|
| The article is just connecting a keyboard
| sniffer/simulator but it would have been as easy to do
| anything to the network traffic, SSD, motherboard/CPU
| JTAGs, RTC, etc.
| michaelt wrote:
| Well, it's sorta possible. Just not with the TPM, and not
| in general purpose computing applications.
|
| Games consoles are super locked down, to prevent piracy,
| and some modern consoles have gone years without a
| successful hack, despite being in the physical possession
| of the attacker. The iphone's activation lock is
| extremely hard to bypass, and even cops and border guards
| struggle to extract users' data.
|
| Simply buy your PC from your operating system vendor
| directly, and forego options like being able to replace
| components and being able to install your own software,
| allowing the memory and PCI bus to be encrypted. Add some
| cloud backup features so the device can wipe itself at
| the drop of a hat without losing your data. After that,
| just have your OS vendor produce perfect code with no
| exploits, and you're secure!
|
| Simple! /s
| Guvante wrote:
| 100% this is sketch. I was thinking if this was a
| supported security model you shouldn't be able to take
| control without disabling the TPM.
|
| But it isn't so not the OSes problem.
| betaby wrote:
| I did. It says 'From here it's easy to manually use the TPM
| to unlock the disk with the Clevis tooling and mount the root
| volume for hacking (it takes a few tries sometimes, but it
| gets there in the end)'
|
| However screenshot says 'Unsealing failing'. Yet Ubuntu-lv is
| mounted. I don't follow how Luks password was guessed for it.
| bri3d wrote:
| There wasn't a password necessary, the TPM was an unlocking
| mechanism.
|
| Secure Boot with TPM-backed disk encryption works off of a
| series of numbered hashes. The idea of TPM based FDE is
| that the machine will use Secure Boot to boot only a
| software chain that the end-user trusts not to contain
| authentication bypasses. In Secure Boot, the EFI firmware
| provides hashes of each stage in the boot chain to the TPM,
| and the TPM only unlocks the full-disk encryption key
| (really the key encryption key, since the TPM isn't fast
| enough to actually decrypt the disk) slot if each stage /
| configuration is valid.
|
| This issue breaks that chain. In some sense it's an
| illustration of this system being silly conceptually, but
| it is a real issue IMO.
| j0057 wrote:
| No LUKS password was guessed, clevis-disk-unlock command in
| the last screenshot used the TPM to provide a key to a LUKS
| keyslot for getting at the actual decryption key to decrypt
| the disk. The TPM should have had information about the
| boot state to be able to refuse to provide the key, but
| didn't.
| jeroenhd wrote:
| The system that should only unlock the drive after the
| appropriate remote command has been provided, unlocks the drive
| without the remote command being provided. That's the problem.
|
| I'm not sure why you would rely on just the TPM in this case,
| though. TPM only disk encryption is rather risky, you'd expect
| a TPM+PIN setup at the very least.
|
| You'd still be at risk because of this flaw, because the root
| shell would allow sniffing the key from a secure session.
| Ideally, attempts to brute force the user account should
| prevent further attempts by rebooting or refusing further
| interactive input.
| michaelt wrote:
| _> I 'm not sure why you would rely on just the TPM in this
| case, though. TPM only disk encryption is rather risky, you'd
| expect a TPM+PIN setup at the very least._
|
| I think the target market is "I have a server in a data
| centre, I need unattended boot, I don't really need a high
| grade of security I just need to tick a checkbox saying the
| hard disk is encrypted"
|
| If your organisation is large enough to start losing track of
| entire servers, and yet small enough you can't adopt
| effective organisational controls to prevent such losses,
| even mediocre encryption might give you some peace of mind -
| and it lets you avoid reporting data breaches, as the lost
| data was 'encrypted'.
| xoa wrote:
| In addition to sibling replies, I'll add that a common
| important use for encryption (and reason to have it be
| completely standard 100% of the time, even in fully
| transparent mode) is storage EOL procedures. It's much
| easier/cheaper/safer to get rid of an HDD or SSD and feel
| confident everything is gone if it was all fully encrypted
| from the beginning and you just need to trash the key.
| [deleted]
| 13of40 wrote:
| It's not a totally meaningless check box. If the key for
| decrypting the disk is in the TPM, this fixes the case
| where the drive gets pulled and thrown in a recycle bin,
| then someone recovers data from it later.
| SoftTalker wrote:
| > this fixes the case where the drive gets pulled and
| thrown in a recycle bin
|
| Also allows you to do that when you retire a server or
| cluster. I've been in situations where we had to wipe
| hundreds of multi-TB hard drives. If you've never done
| it, that takes a good deal of time. You can get
| appliances that do it, or try to build your own DBAN rig,
| but it still takes days. Or you can just shred them, but
| hard drive shredders are not cheap either, and that's
| rather wasteful and may not be environmentally conscious.
| michaelt wrote:
| Yes, when I say "small enough you can't adopt effective
| organisational controls" I mean organisations that are
| large enough that they're discarding so many disks they
| might accidentally forget to wipe some, and yet small
| enough they don't have procedures and record-keeping that
| prevent such accidents.
|
| A large organisation will usually have tedious checks and
| record-keeping for wiping and discarding hardware,
| probably instituted after they wiped and discarded the
| wrong hardware.
| patrakov wrote:
| It is not about forgetting to wipe a disk. A realistic
| scenario is that an SSD fails in a way that it ceases to
| be recognized by the system. At this point, you have no
| way to wipe it. Still, you may be required to return it
| to the vendor (by the contract that gave you the
| discounted price in the first place) - and they can read
| it using their tools not available to mere mortals.
| 0xC0ncord wrote:
| The threat vector mitigated by Clevis[1] is someone with
| physical access (e.g. an insider) removing the server from
| the data center and being able to access its data.
|
| [1] https://github.com/latchset/clevis
| hedora wrote:
| I don't see any discussion of threat vectors on that
| page, but Clevis clearly fails to mitigate the threat
| vector you describe.
| flangola7 wrote:
| You can't read encrypted data without the key
| betaby wrote:
| Looks like so. From https://rogueai.github.io/posts/arch-
| luks-tpm/#unlock-the-lu... 'From a security point of view,
| passwordless LUKS unclocking might look like we're giving
| up some security, as booting will go straight to login
| without asking any password whatsoever. We're indeed
| trading a bit of security in favour of convenience, it's
| important to note though that binding the LUKS to the TPM
| ensures the volume will only unlock in our machine, with
| Secure Boot enabled and our signed boot image.'
|
| So there we are somewhat breaking 'Secure Boot' process in
| general.
| tomatocracy wrote:
| Another potential use is encrypted root with home
| directories subsequently requiring login password to
| decrypt (using pam_ecryptfs, pam_mount, etc). Less secure
| than root fe needing a PIN/password but can still defend
| against some threat models.
| LinuxBender wrote:
| Mirror [1]
|
| [1] - https://archive.ph/zr3Zf
| knodi123 wrote:
| infinite captcha loop
| dpkirchner wrote:
| .ph was working for me yesterday and is working today but
| most of the time I'm stuck in an infinite captcha loop. I'm
| using Google DNS, Safari on iOS, and no extensions. I dunno.
| I figure Cloudflare is just broken sometimes.
| LinuxBender wrote:
| Interesting. I've never seen a captcha on that domain. Maybe
| uBlock or NoScript is preventing it for me. The admin is on
| HN so maybe they will see this.
| trillic wrote:
| Are you using Cloudflare's DNS?
|
| Archive.is purposefully gives bad results to Cloudflare's DNS
| resolvers as they do not respect and pass along EDNS subnet
| information which Archive wants to run their own CDN.
|
| https://jarv.is/notes/cloudflare-dns-archive-is-blocked/
| [deleted]
| causi wrote:
| Cloudflare also gives captcha loops if you have a number of
| different VPN extensions installed.
| Helmut10001 wrote:
| Also seeing infinite Captcha loop, not on Cloudflare DNS.
| CatWChainsaw wrote:
| Trying to access Archive on Mozilla with my only
| extension disabled (uBO) also results in captcha loop...
| twitchyliquid64 wrote:
| 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.
| patrakov wrote:
| On my laptop I have custom Secure Boot keys. I know I did not
| sign any other OS (well, I did - but with a different key), so
| this attack won't work, unless the attacker can somehow trick
| the unmodified previous version of the kernel + initrd combo
| into asking my passphrase and saving it somewhere, which is
| highly unrealistic.
| dhon_ wrote:
| I'm imagining a scene in a Bond movie where 007 casually bypasses
| encryption by mashing the enter key. Actually I don't think even
| movie studios would think that looks realistic.
| alexvitkov wrote:
| 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.
| SomeoneOnTheWeb wrote:
| I used to have a custom NAS with full disk encryption, whose
| bootloader would spin up a tiny SSH server with very few
| features, mainly only access to an unlock function that would
| allow to transmit the encryption passphrase over the said SSH
| tunnel. Then the SSH connection would be closed by the server
| and it would startup with the decryption key.
|
| That way, it was impossible to access the data physically, but
| I was still able to reboot the box whenever I wanted without
| any problem.
| alexvitkov wrote:
| That's sensible, unlike trusting that
| TPM+GRUB+dracut+systemd+getty+logind+whatever all work fine
| and won't leak your key.
|
| Rebooting a box is often the easiest way to get something
| done if you can't be bothered with exotic configs, I just
| don't believe that remotely rebooting a encrypted box for
| which you dont have the key is ever a reasonable thing to do,
| and that's the assumptuon this article is based on.
| teddyh wrote:
| Might I suggest that Mandos might be a slightly easier
| version of a solution to that problem?
|
| (Disclosure: I am a co-author of Mandos.)
| webstrand wrote:
| My experience with kexec has been poor. Every time I kexec, I
| have to load and unload a bunch of drivers to restore the
| system to a functional state. Critically i915 sometimes needs
| to be reloaded after boot to get the display to actually work.
| And on a VM I had issues with the `cirrus` display driver
| failing to unload correctly leaving the system unable to boot.
| Its random and totally unreliable for desktop use.
|
| Aside, this is a nice script that prompts for the LUKS password
| _before_ kexec:
| https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981...
| it does assume you're using opensuse's naming convention of
| calling the root partition cr_root. I used this because my
| bootloader was also encrypted, so rebooting into an initramfs
| with ssh was impossible.
| TeMPOraL wrote:
| > _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?
| alexvitkov wrote:
| If that's a big issue for you consider using ECC memory, or
| even better - colocating your servers in an abandoned mine.
| jmetzmeier wrote:
| What about libc updates? If you need to restart effectively
| every process on the system anyways, why not reboot?
| alexvitkov wrote:
| static link musl
| PlutoIsAPlanet wrote:
| Only rolling distros should be shipping mid-release cycle
| updates that break libc compatibility.
|
| It's not a normal thing for release-based distributions where
| userspace<>userspace compatibility is nearly assured during a
| release.
| Groxx wrote:
| So to double check my understanding of this article and the
| linked one that led to it[1], the issue is:
|
| 1. the TPM does not require a password to get the decryption keys
|
| 2. bootup decryption passwords are checked _by code_ , before
| asking (using?) the TPM's data (passwordless, because the bootup
| code is trusted)
|
| 3. exhausting multiple layers of retries causes ^ part 2's code
| to accidentally get/use the decryption data from the TPM
|
| And assuming that's correct....
|
| _WTF_
|
| Isn't that stupidly insecure design, because even with trusted-
| boot checks it's probably _trivially_ bypassed with hardware
| access (edit: like cutting traces)? Why even offer a bootup
| password if that 's how it's implemented?
|
| Like... at the absolute minimum, a sane design would not
| _completely_ trust the TPM. Combine the TPM 's key with the
| password to get the real key. No additional steps for users, and
| it eliminates all TPM-only attacks (subject to your password
| strength... but currently that is 0 so anything is an
| improvement).
|
| [1]:
| https://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptset...
| [deleted]
| brenns10 wrote:
| TPMs typically won't give out a secret unless all of the
| software which has been loaded and executed was "measured" and
| found to be unmodified from when the secret was stored. So you
| couldn't simply stick your own hard disk or USB disk into the
| computer and then ask the TPM for the secret: the running
| software wouldn't match, and the TPM would refuse.
|
| This is a problem because the "approved" software has this
| strange vulnerability to get into the rescue shell, right at
| the point where the TPM would be happy to give you the secret
| because the software is unmodified.
| Groxx wrote:
| Which wouldn't really be an issue if _all_ the trust wasn 't
| unnecessarily put on a single system, yes.
|
| This is the equivalent of a rubber hose attack, where _your
| OS vendor_ is being threatened and can give away your
| information retroactively. That 's ridiculous to even
| consider allowing if you're selling something as "securely
| encrypted", just make it E2EE (derive the key rather than
| directly using the TPM's data).
| Klasiaster wrote:
| Sounds like it would have also worked to replace the hard drive
| with an own one where the OS directly gives a root shell to read
| the TPM secret.
|
| The solution is to bind the TPM secret to a measured boot state,
| but that requires a way of precalculation of the expected
| measurement values. Read more about signatures for these
| precalcuated measurement values here:
| https://0pointer.net/blog/brave-new-trusted-boot-world.html
| (TLDR: The publishing of prebuilt OS vendor kernel+initrds and
| signed PCR policies allows to bind the secret to the signature
| being valid, so that it still works when auto updates change the
| measurement as long as the vendor signature is also there.)
| arjvik wrote:
| The point of this article is that this attack doesn't change
| any of the TPM measurements.
| gameoverhumans wrote:
| 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 a password which _hopefully_ is a little more secure against
| an attacker pressing the Enter key a lot ;)
|
| The real eye opener for me is what Ventoy can do. You can plug it
| into a computer with Secure Boot enabled, and it will give you a
| nice user-friendly way to just ... completely and trivially
| bypass Secure Boot protection. Yes, really:
| https://www.ventoy.net/en/doc_secure.html
|
| It won't work for every mobo/firmware combo. It worked first try
| for me on some used Lenovo ThinkCentre M710q I bought on eBay,
| though. Even with the latest June 2023 BIOS installed.
|
| Ventoy does this by using a known exploit in a GRUB shim that is
| signed with the official Microsoft certs (that ones that are
| embedded in virtually every mobo sold with Secure Boot support),
| in order to pop the KeyEnroll UEFI application and then enroll
| its own keys in there. Or something like that.
|
| Sure, M$ put out a windows update ages ago that updates the DBX
| to prevent _this_ particular signed shim with known
| vulnerabilities: https://support.microsoft.com/en-
| us/topic/kb5012170-security... ... but who knows how many more
| are out there in the wild?
|
| Once you've pwned Secure Boot (and I'm making the case here that
| any script kiddy can do this on a vast majority of commonly
| available/used mobos, let alone a professional cybercrime
| gang/local LE division or, god-forbid, 3 letter agency), then you
| can simply pop in your favourite (Arch, obviously) Linux live USB
| and `cryptsetup open` your favourite encrypted drive in seconds.
|
| For unattended machines, especially if you've already bothered to
| stick a Clevis in there, you really ought to blend your TPM ping
| with a SSS (min 2) one-two combo-punch of a Tang pin.
|
| But again, if the attacker is literally sitting at your desk
| typing in your computer connected to your trusted networks and
| such, you're always gonna be pretty screwed.
| hollerith wrote:
| >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?
| gameoverhumans wrote:
| 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?
| magicalhippo wrote:
| There's also voltage glitching which has been used with
| great success as well[1][2].
|
| [1]: https://web.archive.org/web/20190801014726/https://www
| .cl.ca...
|
| [2]: https://arxiv.org/abs/2108.04575
| gameoverhumans wrote:
| Indeed! Voltage glitching was used to jailbreak Tesla
| recently! I believe it was also used to jailbreak the
| Nintendo Switch.
|
| If a discrete TPM (separate chip on the mobo, rather than
| an fTPM which runs in the CPU/SoC) is in use, one can
| also use bus sniffing to pwn TPM protection:
| https://blog.scrt.ch/2021/11/15/tpm-sniffing/
| Kiuhrly1 wrote:
| For the Nintendo Switch, it was used to dump some
| firmware which was then analysed and found to have a
| buffer exploit (can't remember what sort), which let to
| the famous Fusee Gelee exploit on early switches. IIRC it
| was a security chip which is both ironic and incredibly
| useful because it couldn't be patched without a hardware
| revision and it ran before anything loaded from the
| onboard storage.
| adrian_b wrote:
| Because of things like those described by you, I have never
| trusted bootable encrypted SSDs/HDDs.
|
| In my computers, I have only non-bootable and non-
| partitioned SSDs/HDDs, which are completely encrypted with
| a random 256-bit key, so as long as an attacker has only
| access to the computer, for instance to a stolen laptop,
| there is absolutely nothing that can be done to gain access
| to the stored data.
|
| To boot the computers, I use a small and inconspicuous USB
| memory containing the boot loader and the kernel, from
| which the encrypted SSD is mounted and then pivot_root is
| executed to replace the USB memory with the encrypted SSD
| as the root device, and then the USB memory is removed and
| it is not used during normal operation.
|
| The USB key contains an encrypted form of the SSD
| encryption key, requiring the entering of a passphrase
| after the kernel has booted, but before mounting the
| encrypted SSD.
| alexeldeib wrote:
| Are you still using LUKS for these? How are you invoking
| decryption with the pass phrase protected key?
| adrian_b wrote:
| I am not using LUKS, I am using a custom kernel module
| that implements a block device that presents to the
| kernel the decrypted SSD. The kernel module receives the
| key when it is loaded, then it creates the block device
| that is eventually mounted as the new root device.
|
| I do not know if LUKS could be used for this, I have not
| examined it. IIRC, LUKS stores the actual decryption key
| in the encrypted disk (protected by a passphrase) or in
| the TPM, like most commercial products for disk
| encryption, which are methods that I do not approve.
| StillBored wrote:
| While cool/interesting, i'm failing to understand the
| attack your protecting against here in the context of
| just prompting for an unlock PIN.
|
| Particularly if that unlock pin is for a FIDO key or
| whatever which can also be removed.
|
| I mean, if someone steals your backpack, or stops you at
| the border, breaks into your house, whatever, they are
| getting the boot image too, right?
|
| Furthermore, are all your machines AMD Pro or equivilant
| (with the encrypted RAM enabled)? Because the disk
| encryption key is probably just sitting unencrypted in
| system RAM otherwise, and is susceptible to people
| freezing the ram and removing it to another machine to
| extract the keys.
| theLiminator wrote:
| Is there a way to do 2FA yubikey style disk encryption? Ie.
| requires a passphrase + user's yubikey to login?
| malwrar wrote:
| The thing that prompts for your password is necessarily
| unencrypted, the evil maid just needs to modify that to e.g.
| log the decryption key. On linux, this is usually just a
| shell script invoking cryptsetup somewhere in the initramfs
| image.
| StillBored wrote:
| Maybe, it is possible to use both a firmware unlock against
| an OPAL encrypted drive, and validate the signature of the
| initrd/UKI as part of secure boot. Either or both protect
| against this to a certain extent depending on
| configuration.
|
| As does of measuring all of the above into PCRs that are
| unlocked with by the utility prompting for a pin used
| alongside the PCRs to unlock the key.
| jsmith99 wrote:
| 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.
| michaelt wrote:
| 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.
| [deleted]
| [deleted]
| chatmasta wrote:
| You raise a valid point, but this attack is particularly
| alarming because it circumvents a TPM, which is a hardware
| module that was specifically designed to protect against evil-
| maid class of attacks, e.g. every iPhone after the 5S uses its
| Secure Enclave (a TPM) to enforce time delays between passcode
| attempts [0], so that a physical attacker can't brute force the
| passcode. (Incidentally, the attack described in the OP is
| reminiscent of some early attacks against the iPhone that used
| an HID device to circumvent passcode rate limiting.)
|
| IMO, the continuing difficulty that the FBI has breaking into
| seized iPhones is proof that it's possible to ship a device
| with hardware that is sufficiently secure to mitigate against
| any physical exfiltration of data, but this is probably only
| possible because of the fully vertical integration of Apple
| hardware, firmware, and software (and even then - it's still a
| cat and mouse game, bugs will eventually be exposed, etc.). For
| open source software that runs on any arbitrary assemblage of
| hardware components, I suspect it's nigh impossible to achieve
| this same level of physical security.
|
| [0] https://support.apple.com/en-
| gb/guide/security/sec20230a10d/...
| gameoverhumans wrote:
| No, this explot has nothing to do with the TPM. The problem
| is tricking the initrd in giving you a shell, at which point
| you are able to run arbitrary "unprivileged" code (i.e your
| shell commands) and tell the TPM to do whatever you want.
|
| Gaining a shell using the technique in this article is
| functionally equivalent to the bypass Secure Boot -> boot
| live Linux scenario I described in parent comment.
|
| The article notes that Windows "avoids" this issue by
| measuring into PCR11 as early as possible, but it stands to
| reason that any kind of exploit that is found in the windows
| boot flow that happens _before_ this moment would be the same
| issue as the described Clevis+initrd issue.
| hedora wrote:
| It doesn't really bypass the TPM though. These machines
| configure the TPM without a pin so they can boot + decrypt
| the drive in an unattended mode.
|
| I'd trust this setup to prevent drives that were removed from
| servers from being decrypted (like for recycling), but it's
| basically useless against any other class of attack.
|
| It's good to see publicized exploits of it though; that way
| people can link to this blog post if a pointy-haired-boss
| tries to misapply this class of disk encryption.
| ajross wrote:
| > this attack is particularly alarming because it circumvents
| a TPM,
|
| FWIW, I think this phrasing is a little confusing. The TPM
| wasn't compromised at all. What happened is that the attack
| trips systemd into a fatal error path where it gives up and
| just drops the user at a root shell (!!!). From there you can
| simply command the TPM to do its thing and cough up the key,
| and it will trust you because you're the presumably-
| authenticated boot firmware.
| jiveturkey wrote:
| In addition to the inaccuracies others have mentioned, the
| iPhone secure enclave is not a TPM. Saying it is isn't a
| simplification, it's muddying the waters.
| chatmasta wrote:
| Can you explain the difference a bit more, and why it's
| more than just splitting hairs? Is it because TPM is a
| specific standard for implementation of a secure co-
| processor, whereas Secure Enclave is part of a larger SoC
| (T2), which while it could be considered an implementation
| of a secure co-processor, is distinct from the TPM
| standard?
|
| In researching this comment I learned that the T2 chip
| actually runs its own operating system (bridgeOS), so I can
| see why you'd call it an oversimplification (or muddying
| the waters) to equate it to a TPM.
| als0 wrote:
| The TPM is an TCG standard (also ISO/IEC 11889), and
| specifies commands that support a lot of use cases. The
| Secure Enclave from Apple is something simpler and more
| restrictive, that is tailored only for Apple's use cases.
| jiveturkey wrote:
| simpler? hardly.
|
| high level overview:
| https://support.apple.com/guide/security/secure-enclave-
| sec5...
|
| low level overiew: https://www.blackhat.com/docs/us-16/ma
| terials/us-16-Mandt-De...
|
| AFAIK, and it's hard to find the info since I don't have
| it handy, so I don't want to devote the searching time,
| but bringing it back on-topic, all disk i/o has to go
| through the secure enclave for encryption and decryption.
| i believe this is better documented on mac than iphone.
| the data storage is _always_ encrypted since T2. If
| filevault is enabled, then the user 's password gets
| mixed in with the T2 hardware keys. Because those keys
| can never leave T2, all disk i/o necessarily goes through
| it.
|
| This is vastly different than how TPM operates.
| jsmith99 wrote:
| 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.
| gameoverhumans wrote:
| 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: h
| ttps://wiki.archlinux.org/title/Trusted_Platform_Module#sys..
| . ... both of those are firmware-level PCRs, not OS ones.
| tomatocracy wrote:
| PCRs 0+7 might not be sufficient if you don't have an up to
| date dbx (revocation list) - older versions of shim won't
| (I think) extend into PCR 7 enough information on what they
| chainload. This means a malicious bootloader could fake the
| correct PCR extensions.
|
| Updating dbx to a version which revokes versions of shim
| with this issue would fix this I think, as would including
| PCR 4 in the list bound to, to make doubly sure that the
| version of shim is new enough not to present a risk.
___________________________________________________________________
(page generated 2023-09-01 23:00 UTC)