Bootkitty: Analyzing the first UEFI bootkit for Linux
welivesecurity.com
welivesecurity.com
This is obviously a low hanging fruit and first PoC implementation. The fact that secure boot can "mitigate" some of this attack right now is mostly due to the attacker being lazy or deploying an unfinished product. The researchers describe this as "unless they install the attackers certificate", which is a nice way of saying that the attacker has not spent much time fishing through DKMS and abusing the keys used for this purpose.
There are a lot of systems that are affected by this type of attack because for various purposes they have to sign their own modules. The most common example of this (until extremely recently, sort of) is Nvidia.
Can you explain, or link to a source explaining this?
Seems to me that in an ideal world, you would only have to add the public key, and an attacker wouldn't be able to forge a signature without the private key...
This is to say, its not impossible that those can be signed from the distro. Just Arch doesn't.
Check out "sbctl" by Foxboron, it's a UEFI key and signature manager [1] that's pretty nice.
But other than that I agree with you there, I wish that upstream kernel builds would be signed by the distro for secureboot usage. Maybe this should be part of the archlinux-keyring package?
I usually store these keys on a LUKS encrypted flash drive. Not the best opsec, but at least good enough to prevent this kind of malware from spreading around. Can't update the kernel without the flash drive though :D
Why would it not be the best opsec?
I replied to your other comment suggesting encrypting your local signing keys. I am not sure if I would use a flash drive though, why not just using the local disk?
One issue I can see with this, though, is that if the malware is already present on your system and can run things, nothing would prevent it from hijacking the modules or the boot image before they're signed.
This is a persistence stage exploit mechanism, meaning in order to install it, privilege escalation happened before that and it already got root rights.
The people here that claim "secureboot prevented that". No, it didn't. A simple call to sbctl to sign the rootkit is missing, because, as every Linux device, you will have to have the signature keys available locally. Otherwise you can never update your kernel.
That is the conceptual issue that cannot be fixed, and also not with TPM or whatever obscurity mechanism in between.
Linux needs to be a rootless system, meaning that there needs to be a read only partition that root can never read. That would limit access to this kind of thing to physical access or the kernel ring at the very least. Technically, this was the intent of efivarfs, but look at where vendor firmware bugs got us with this.
If, hypothetically, you were using a system without custom keys, e.g. with a third party kernel trusted via the Microsoft / Red Hat shim program, [1] wouldn't you be safe, so long as secure boot was enabled? The bootkit would not be able to sign itself with a trusted key since the private key would never exist on the system to begin with.
Obviously, I'm aware that this approach has other problems and has had vulnerabilities in the past.
> Technically, this was the intent of efivarfs
As the original author of efivarfs I can absolutely say that this was not the intent
Now that would be something! Unfortunately, I haven't discovered Microsoft's private key on my computer yet.
The majority of Linux machines out there are running vanilla, distribution-signed kernels. For most people, the only reason to build your own kernel (modules) is Nvidia.
I am wondering: could you store the signing keys on a Fido2 device? Or in a crypted file?
I would think this would not be mere obscurity, as this makes sure that just being root does not give you access to the signing keys.
I cannot help but think the move to UEFI and Secure Boot made things less secure :(
Of course, most/all SB BIOSes enable setting your own platform key.
If i were to design security from the ground up it would be a small external sdcard for firmware and kernel (with a hardware r/w toggle), and optionally a external sdcard adapter that verifies the hash of the content.
Everything else is as dumb as bricks and gets its firmware loaded from the sdcard.
We didn't do that because secure boot was solving the problem of large orgs with remote administration in mind, and designed by orgs happy to sell yearly advanced cybersecurity protection shield plus certification subscriptions.
Designing for remote administration by an IT department will.. increase the attack surface for attackers to remote administrate my device.
You might be interested in Librem Key, based on free firmware?
I had to disable SB to boot the installer for either F39 or Mint 22, i forget which, on an old laptop.
We can argue about whether there is sufficient user demand and benefit to make secure boot easier for lay people. But that is completely orthogonal to whether it increases or decreases security of the system.
> Bootkitty is signed by a self-signed certificate, thus is not capable of running on systems with UEFI Secure Boot enabled unless the attackers certificates have been installed.
> To keep your Linux systems safe from such threats, make sure that UEFI Secure Boot is enabled
In fairness, the blog post confusingly says this in the next bullet point:
> Bootkitty is designed to boot the Linux kernel seamlessly, whether UEFI Secure Boot is enabled or not, as it patches, in memory, the necessary functions responsible for integrity verification before GRUB is executed.
However, this would still require Rootkitty to have gained execution already, which it wouldn't be able to if Secure Boot was enabled and the malicious actor's certificates weren't installed.
On window: It took several years until the first two real UEFI bootkits were discovered in the wild (ESPecter, 2021 ESET; FinSpy bootkit, 2021 Kaspersky), and it took two more years until the infamous BlackLotus – the first UEFI bootkit capable of bypassing UEFI Secure Boot on up-to-date systems – appeared (2023, ESET).
Per article.
It exists as a moat to make it harder to install Linux on your (Microsoft) PC.
...and this bootkit is not able to work if Secure Boot is set up.
UEFI is also a godsend in terms of fixing a lot of the legacy BIOS crap
wrong.
> UEFI is also a godsend in terms of fixing a lot of the legacy BIOS crap
that's like saying cutting the baby in half to end the dispute also solved the crying
In my experience there's a lot more crap in UEFI than there ever was in BIOS, if only because there's so much more of it.
From a user perspective, no, it is not. Booting is far more complicated with UEFI.
The trusted computing initiative was a disaster to the learnability of the computing field.
Devs are users too. Especially the unskilled/ignorant ones.
Most people are probably glad that their computers have guis and they can install applications with just a few clicks. The price of those features is complexity.
Ultimately, we're all like the Amish: we make decisions about our preferred level of technology. I won't have a smart TV in my house, but I'm happy to have UEFI systems.
Good news: you don't need to!
I agree the move to UEFI added a huge new attack surface and that most UEFI implementations (notably, even the open source ones) are teeming with horrible bugs.
And yes, then linking the trust architecture for Secure Boot so deeply with UEFI means that UEFI bugs are also Secure Boot bugs.
But to say this is less secure? No way. Traditional BIOS-based MBR backdoors are like 1980s oldschool classic stuff. Most adversaries would require a good degree of development work to backdoor / root kit a PC they were given with Linux, Secure Boot, and an encrypted filesystem. With a BIOS based PC there would literally be nothing to do.
For desktops and mobos, maybe. Gonna be hard to make that work for laptops and phones.
But generally I'm in agreement. By the time I'm booting into and using the system the BIOS is no longer a discussion point; if I need to update it then I need to shut it down and get under the hood.
Or just in general machines that are wholly controlled by the owner.
Trustworthy people don't ask you to trust them.
But those are merely defaults which you do posess ultimate control over, unlike the blobs and secrets in various bits of hardware.
You can say that I implicitly trust the browser vendor's judgement in what CAs to trust, by the virtue of using the browser, and I'd agree with that. But saying that I was asked by the browser publisher to trust them? No, I disagree, I wasn't. It was a silent decision.
In fact, this bootkit would be about the least thing I would worry about. Because by the time an attack can write to /boot, they can also write to /etc/init.d . And the later is not protected by "secure boot".
Bootkits are to make the infection both more difficult to detect and remove, so whether /etc/init.d is writable is pretty irrelevant.
The entire boot system has much, much fewer places for malware to hide compared to the entire "rootkit" OS attack surface which is astronomically larger. Secure Boot has always targeted the smaller and most useless of the swiss cheese holes.