First in-the-wild UEFI bootkit bypassing UEFI Secure Boot | Hacker News Reader

First in-the-wild UEFI bootkit bypassing UEFI Secure Boot

welivesecurity.com

286 pointsmiles76 comments

This is kind of weird in that it's exploiting a vulnerability in the Windows bootloader, but once exploited it's pivoting to using shim+grub (edit: apparently it's not actually grub, it's their own bootloader that's just called grubx64.efi because that's what shim boots by default). There's no absolute requirement to do this, but it's presumably easier to implement their full payload in grub rather than getting it all running in the context of the Windows bootloader. This means it probably doesn't work on the Secured Core PCs that only ship with support for the Windows signing key (but also it can't be used to attack Linux systems that remove trust in the Windows key).

This pivot means that the keys measured into PCR 7 of the TPM will change, which breaks the Bitlocker policy, which is presumably why stage 1 disables Bitlocker before exploiting the bootloader. This means it's also detectable using Remote Attestation (I think Microsoft's Device Health Attestation ought to notice, but haven't verified it), which is nice for all 3 of the people who've rolled that out.

In terms of why the known vulnerable bootloaders weren't already revoked - I have no inside knowledge here, but my guess would be the impact on users with existing install media (including factory restore images). We've revoked a bunch of vulnerable Linux bootloaders, but the level of pain involved in revoking a Windows one is almost certainly way higher.

> We've revoked a bunch of vulnerable Linux bootloaders, but the level of pain involved in revoking a Windows one is almost certainly way higher.

Revoking other OSes install media en-masse is fine, but not Windows ?

You can't exactly swap out the bootloader on Windows install media. You can on Linux because it's a modular component of the system, but on Windows the entire OS + kernel + bootloader is a single image.

Linux users tend to be their own support. Windows users are commercial support which is $.

I wouldn't be surprised if 50% of Linux users already have Secure Boot disabled - and probably 98% of Linux users have the wherewithal to get into the BIOS and disable it if they needed to. And doing so has negligible downsides, as almost nobody on Linux has been fool enough to make use of the TPM.

TPM support on Linux (for drive encryption) is getting better with tools like clevis. Additionally, systemd can do a ton of cool things with TPM, and projects like dm-verity can make linux's boot process more locked down than Windows.

I personally will always use a passphrase for device encryption.

Passphrase + TPM is best.

> [...] almost nobody on Linux has been fool enough to make use of the TPM.

Can you elaborate as to what is foolish about using a TPM?

Not the OP but just anecdotally, last time I looked into enabling secure boot on my X1 Carbon there was an advisory from Lenovo that enrolling your own keys made it possible to brick the machine

https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon_(...

That's only if you fail to enroll the Lenovo hardware firmware images

Can you link to a doc explaining how to do that? I'm not even sure what it means to enrol a firmware image. I'd love to finally get this working.

I think they're referring to the BIOS itself, since even that needs to be signed and verified.

It does, but it's not signed with the UEFI Secure Boot keys (Boot Guard has its own mechanism that's burned into chipset fuses, you can't re-key it)

https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

It's referring to dual booting windows but the same principles apply.

That's related to Secure Boot, not the TPM

In practice you have to enrol your own MOK if you want to use the nvidia drivers, or v4l2-loopback, or virtualbox, or a bunch of other things - so unlike on Windows, it doesn't give you any great OS integrity benefits.

You want those modules signed by someone like Canonical, so you don't have to mess around with a MOK? If you use Ubuntu Core they'll be happy to - for about $100,000 per year per module.

Automatically unlocking hard drive encryption is less secure than just typing in a password at boot.

No OS-independent way of confirming the user's presence means it's less secure than a Yubikey.

No iphone-style activation lock, so it's useless as a theft deterrent.

No xbox-style main memory or system bus encryption, so no protection against evil maid attacks.

Too slow for servers to offload SSL or disk encryption to - so all the important keys end up being held in memory anyway.

The spec and interface are complicated as hell, so you know there's no chance this stuff is bug-free. You want a command line tool? We've got 99 command line tools. Literally.

The foundation of its security is the code of your system's BIOS, which we all know is some of the shittiest code out there.

So the TPM offers a hair-trigger system that'll destroy all your data if your BIOS vendor messes up and miscalculates a PCR value. The security benefits you get in return are pretty minor.

The MOK thing is secure boot, not TPM related.

You can have arbitrarily complex TPM authorization policies for unlocking storage keys. You can have it be that the loaded firmwares and OS are trusted and (or or) you have to enter in a passphrase that only the TPM can verify, and/or you can have a recovery mechanism so that if some firmware got updated you could use a smartcard or whatever to authorize moving on anyways. So, while OSes that support TPMs for storage key recovery generally have -as you say- hair-trigger policies, that's not TPM's fault but the OS's, for they could develop much more interesting policies.

How to do those things in Linux?

Assuming you'll use LUKS for drive encryption, you can have several key slots that all allow unsealing the key to decrypt the drive.

1. You'll have your master password, for which it asks when you first create it. You can make this absurdly long and consider it'll be used as a last resort (say you've lost everything else and your computer is broken - you only have the drive left).

2. You can then add Windows-style auto-unlock with the TPM. It works with systemd. You can of course choose whichever registers you like, the correct TPM device if you have several.

   systemd-cryptenroll /dev/sda1 --tpm2-device=auto --tpm2-pcrs=0+1+7

3. If you're somewhat paranoid, you can have it ask for a PIN. Just add --tpm2-with-pin=true to the above.

4. What if this is an external drive and / or often change your UEFI settings yet still need a quick unlock? Luckily, you have a FIDO2 device, so systemd's got you covered:

    --unlock-fido2-device=auto instead of the tpm2

5. You can probably combine TPM + FIDO2, I've never tried it.

Check the Arch wiki for more:

https://wiki.archlinux.org/title/Trusted_Platform_Module#Usi...

---

edit: it should be noted that even on Windows, there's a recovery key which allows you to unlock bitlocker if the TPM was cleared. It's not clear what the poster above said that the data would be nuked (unless, of course, you only count on the TPM and don't save that key somewhere).

Code needs to be written :(

Intrigued, why is v4l2-loopback related to this?

It has to be built from source.

> Can you elaborate as to what is foolish about using a TPM?

Another backdoored closed piece of hardware ?

I keep it disabled on all my machines. I can secure my machine using whole disk encryption, and secure boot is just a royal pain in the butt.

I recognize that I am decreasing my security a bit, but that tradeoff is worth it to me.

"...secure boot is just a royal pain in the butt."

Fully agree, when I first read the HN story headline my initial reaction was where can I get a copy for use on my own machines.

Disabling it is always one of the first things I do with a new system even if it is running windows. It's probably not rational, but I hate the whole concept of a TPM.

Oh, I think the vulnerable Windows images should also be revoked, but pretending that the damage caused is equivalent isn't realistic. Systems have shipped with factory restore partitions that still contain old bootloaders - this revocation update would stop all of those working, which is going to be a significant support burden for all those manufacturers.

But it still take a first boot to apply the rovoke list update. Just apply them at the same time.

That doesn't update the factory install image, and reinstalling that won't roll-back the revocation updates (so it just won't boot instead)

The write-up I saw suggests that revoking the Windows bootloader would cause existing install and restore images to fail to boot even with Secure Boot disabled because it checks its own signature, which would be pretty amazing if true: https://github.com/Wack0/CVE-2022-21894

I continue to dislike the PCR 7 mechanism. Remote attestation, etc should have a means to accept or reject specific bootloaders, not just their signing keys.

</grump>

That information is still in PCR 4, the reason for just encoding the policy and signing key in PCR 7 is that it remains stable even if you update the bootloader.

Hmm, I guess there could have been a mechanism by which a boot manager would, as the very first thing it does, extend a PCR with its own version number, and other later things that want to require a specific or newer version could check that PCR. Then at least old versions could be reliably distrusted without actually being revoked and thus rendered unable to boot.

Measuring the version is easy enough, and having that in the event log makes it easy to parse out remotely, but given the PCR is just going to end up as the SHA256 of it you can't write policy that says "Unlock if this value is x or greater". There's some stuff you could do with a monotonic counter, but they have some subtly complicated semantics that would make me a little scared of trying.

I realize it would need SGX or make TPM even more horribly complicated, and the TCG has about zero change of getting it right, but it would be really nifty if one could unseal data based on a flexible predicate that can read the event log. Imagine something like an eBPF or Ethereum VM program that takes the event log as input and says yea or nay.

What are some good places to read up on these things (e.g. PCR 7 &, 4)?

Remote Attestation (DHA) is enabled by default with Microsoft's mobile device management product (Intune), so it's likely rolled out to a good number of enterprise customers. Not sure how many use DHA for access control though, and Intune doesn't support servers.

Amusingly, this exploit titled BlackLotus priced at $5,000 is cheaper than its likely namesake, the Magic: the Gathering card Black Lotus.

The cheapest Black Lotus cards are around $10k[1], an artist proof, signed Black Lotus may be worth around $800,000[2].

[1] https://www.tcgplayer.com/search/magic/product?productLineNa...

[2] https://www.rollingstone.com/product-recommendations/lifesty...

Well, sure. I mean, one of these things just lets you hijack the boot process of a fully-patched operating system. The other one lets you add three mana to your mana pool at no cost!

It's really no contest.

You're right. One is a necessary tool for the most skilled actors to use against their greatest threats; the other is merely another vector for exploiting trusted computing primitives.

(replied to wrong comment)

I think you replied to the wrong comment.

Yup

How many more times does this kind of thing have to happen before people realize that "Secure" Boot isn't real security from anyone other than the computer's owner?

I don't disagree with you, but also wonder if, by raising the stakes considerably, 'secure boot' has prevented rafts of malware that could be created by anyone and their dog.

Isn't the kind of malware that most script kiddies would want to make totally outside of Secure Boot's threat model?

Most malware does not mess with boot process because it requires higher skills.

Plus like, there's the possibility of Secure Boot that makes your infected machine not boot if you do it wrong.

There is no evidence secure boot has prevented any malware.

There are UEFI bootkits in the wild that are prevented by secure boot.

An attack that does not work on a technology is not evidence of a control’s effectiveness.

Literally the only difference between a system with secure boot and one without is that unsigned boot components (such as the ones used by prior UEFI bootkits) won't boot. The fact that they don't work is absolutely evidence of the effectiveness of the control.

> some of the BlackLotus installers we have analyzed do not proceed with bootkit installation if the compromised host uses one of the following locales: Romanian (Moldova), ro-MD, Russian (Moldova), ru-MD, Russian (Russia), ru-RU, Ukrainian (Ukraine) , uk-UA, Belarusian (Belarus), be-BY, Armenian (Armenia), hy-AM, Kazakh (Kazakhstan), kk-KZ

I can guess why they might do that, but also wonder if it's an actual international group (nice to see countries working together so well! /sarcasm), or they threw in a few extra plausible ones to mask their origin. For example, if they just picked Moldova, that's relatively small country and would narrow down their location to one city exactly.

Do those countries have reciprocal law enforcement agreements with each other by any chance?

They usually refuse to target all ex-USSR or CIS countries.

I bet it's because Transnistria doesn't have its own locale.

So the revocation list is distributed by BIOS updates? If yes, then secure boot seems like a joke for most consumers.

No, revocation lists can be updated from the OS and are freely available from https://uefi.org/revocationlistfile

So the OS just doesn't do it automatically?

It does. Windows ships them as part of security updates, Linux distributions can use fwupd.

As noted in the other comment, Linux (if running fwupd) and Windows support doing it automatically, but the files are made public so other operating systems and distributions can also implement that.

I find it hard to square with: "In this blogpost we present the first public analysis of this UEFI bootkit, which is capable of running on even fully-up-to-date Windows 11 systems with UEFI Secure Boot enabled."

Microsoft has not yet chosen to revoke the vulnerable bootloader

It already has 234 entries, all issued within a year of each other. How much space does a UEFI BIOS typically allocate for this list? Are you able to use this mechanism to revoke good BIOS signatures, is there an availability issue potentially created by misuse?

A new mechanism called SBAT (https://github.com/rhboot/shim/blob/main/SBAT.md) is now used to allow revocation of groups of bootloaders rather than individual hashes in order to mitigate the resource consumption

I don't know about Windows, but I'm quite sure my Ubuntu Update mechanism has distributed BIOS updates to my Laptop.

I would love to take a look at these underground hacker places to see what goes on and what to watch our for… I’m guessing it’s all dark web stuff though. Are any of these forums available on the clear net?

The "dark web" is one download away [0].

[0] https://www.torproject.org/download/

> Are any of these forums available on the clear net?

Yes. Can you read and understand Russian?

Everyone can - Google Translate is… uhm acceptable. So do not be shy, post the links.

Based on the user rank in the BleepingComputer article's screenshot ("kilobyte") it looks forum.exploit.in. Anyone can buy a membership for ~$100 in BTC. I've read some of these places and honestly it's pretty boring. It's basically just a marketplace for software to steal money from people in first world countries (stealers, n-day exploits, crypters, AV scanning services, phishing services) and a bunch of supporting services like residential proxies, hacked RDPs, SSN lookups, and "drop" bank/crypto exchange accounts.

There are others that are public: antichat, wwh-club, bhf. I'm not on it but I think the most "elite" forum is called Mazafaka and requires a substantial deposit and a recommendation from existing members.

Exploit.in is more technical than most of these forums but a lot of these people are not really very technically skilled they just have a very good understanding of how anti fraud systems work and how to circumvent them.

Да, я нормально понимаю и читаю по-русски. Ссылки пожалуйста.

CVE-2022-21894 PoC: Secure Boot Security Feature Bypass Vulnerability https://github.com/Wack0/CVE-2022-21894

Bootkit samples https://github.com/hardenedvault/bootkit-samples

The short-term solution for workaround is to protect the OS runtime. Otherwise you'd have to build the defense-in-depth at very infrastructure level from scratch with hardware, firmware and OS with attestation service not only based on the "confidential computing" but typically TCG's trusted computing.

> UEFI bootkits may lose on stealthiness when compared to firmware implants – ... – as bootkits are located on an easily accessible FAT32 disk partition.

It's kinda a surprise that it's only detected in the wild now if it's that obvious.

Can this bypass something like ransomware. If the hard drive is encrypted by something like bitlocker, or if you forgot the decryption password.

No, it's only able to disable Bitlocker because the initial deployment requires admin level access in Windows - stage one of infection is to disable Bitlocker from a running system that's already unlocked the drive.

Reply on news.ycombinator.com