Found in the wild: The world’s first unkillable UEFI bootkit for Linux
Found in the wild: The world’s first unkillable UEFI bootkit for Linux
“Bootkitty” is likely a proof-of-concept, but may portend working UEFI malware for Linux.
“Whether a proof of concept or not, Bootkitty marks an interesting move forward in the UEFI threat landscape, breaking the belief about modern UEFI bootkits being Windows-exclusive threats,” ESET researchers wrote. “Even though the current version from VirusTotal does not, at the moment, represent a real threat to the majority of Linux systems, it emphasizes the necessity of being prepared for potential future threats.”
-
Unkillable? Bro have you even tried kill -9?
-
Attacks only machines running specific Ubuntu kernels and using specific boot methods. Plus no actual payload. This doesn't yet represent a real risk.
Where we'll be in ten years' time is unknowable, however. I think the Ars commentors who suggested going back to forcing jumper cap swaps or other hardware-mediated access requirements before overwriting the mobo's boot firmware might be on the right track, even if it's inconvenient for large corporate deployments. It's normal for security and convenience to pull in opposite directions, and sometimes you just have to grin and bear it.
-
Who would've thought replacing a BIOS with what's essentially a micro-computer would open a can of worms...
-
BIOS was always a micro computer... it's just more standardized now.
And especially things like IPMI (which is essentially a company-sanctioned backdoor to any intel server) which has a full on webserver with an unknown number of threat vectors, things like this really fall flat for security.
Just because threats are found for UEFI (an open standard), it means nothing in grand scheme of things, just that it is more observed and more easily dissected for nefariousness.
-
I meant BIOS is way more limited in scope than UEFI and that's a good thing.
Although since the limitation was most likely due to hardware of the day, i don't know how would a modern BIOS look like.
-
-
-
This bootkit is not unkillable yet. If the diagram is correct, then it installs itself on the EFI partition and not the EFI Firmware.
-
The Bootkitty sample ESET found is unable to override a defense, known as UEFI Secure Boot, that uses cryptographic signatures to ensure that each piece of software loaded during startup is trusted by a computer's manufacturer.
AKA not that big of a deal, yet. An article from another post about this also mentions GRUB explicitly as a requirement as well as PoC using self signed keys, which renders it sort of impossible to abuse.
UKI + your own keys + secure boot is still not broken.
-
How many distros support secure boot out of the box? IIRC it’s only Ubuntu and RHEL. The rest require hacking some shit together with self signed keys.
-
This sounds like a good thing. I don't care if the manufacturer of my equipment trusts the software. I care if I trust it.
-
It is a good thing!
-
-
Unfortunately a lot of people in the Linux world still hate secure boot because they associate it with locking your PC to only running windows. Never mind the fact that basically every big Linux distro plays nicely with secure boot these days, and has for a while now.
-
I associate it with the fight I've had every single time I tried to use it. It's never been a smooth process on any server I attempted to use it on. Usually I either run into problems with a system not wanting to properly boot the memory stick even with a full UEFI image flashed to it, or if I do get that to work I go through the whole installation process only to find the system unbootable for whatever reason. Eventually I just give up and do a standard installation because why should I have to work this hard to put an OS on a machine?
-
The Fedora doc on this is a bit old but it's still mostly the same:
Secure boot activates a lock-down mode in the Linux kernel which disables various features kernel functionality:
- Loading kernel modules that are not signed by a trusted key.
- Using kexec to load an unsigned kernel image.
- Hibernation and resume from hibernation.
- User-space access to physical memory and I/O ports.
- Module parameters that allow setting memory and I/O port addresses.
- Writing to MSRs through /dev/cpu/*/msr.
- Use of custom ACPI methods and tables.
The implementation of secure boot is still questionable to this day, but it is understandable that it doesn't always play nice with Linux. I do believe you can use hibernate now as long as you have an encrypted swap (LUKS).
I can definitely see the pain if you happen to be a kernel dev or use linux on any SBC with IO ports you want to mess with in userspace and not make en entire overkill kernel module for.
-
Yea, I guess that initial total lack of understanding and big headlines has left a long-lasting scar. Admittedly, secure boot could be used to lock a machine down if the ability to turn it off and/or manage the keys yourself was removed.
We'll get there, eventually :)
-
Never mind the fact that basically every big Linux distro plays nicely with secure boot these days, and has for a while now.
In my experience nicely is still pretty relative. It still seems to be the most common area things go wrong on my installs and place I have the hardest time working around...
and the bigger part, it's a solution to a problem that I've never seen happen in the wild, and really can't fathom happening on linux that doesn't involve a very dumb user running software from an unknown source as root.
-
Well... if you have your own keys (like I do) you have to store them somewhere. That somewhere is probably somewhere on a computer where they are used so you can update the kernel. If you have private keys, you can probably bypass secure boot.
Is there a way to have private keys stored on a nitrokey that has to be plugged in for every kernel update?
-
Yes, failing to safeguard keys is fatal, but that applies to everything. But if fs you're storing keys on is behind luks and they're readable by root only - you're as safe enough. There're also LSMs like selinux that can increase the complexity of attack.
I don't know about nitrokey specifically, but TPM is an option (not good enough, imo) and a simple luks encrypted usb. You could get some convenience by storing the key to unlock it somewhere on the encrypted root.
In general - you cannot stop a targeted attack no matter what, but staying safe from all the automated ones is doable.
-
-