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.
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.
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.
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.
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.
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.
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.
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).
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
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.
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
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.
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.
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.
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.
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!
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.
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.
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.
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
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."
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?
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.
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.
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.
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.