The World's First Unkillable UEFI Bootkit For Linux (arstechnica.com) 73
An anonymous reader quotes a report from Ars Technica: Over the past decade, a new class of infections has threatened Windows users. By infecting the firmware that runs immediately before the operating system loads, these UEFI bootkits continue to run even when the hard drive is replaced or reformatted. Now the same type of chip-dwelling malware has been found in the wild for backdooring Linux machines. Researchers at security firm ESET said Wednesday that Bootkitty -- the name unknown threat actors gave to their Linux bootkit -- was uploaded to VirusTotal earlier this month. Compared to its Windows cousins, Bootkitty is still relatively rudimentary, containing imperfections in key under-the-hood functionality and lacking the means to infect all Linux distributions other than Ubuntu. That has led the company researchers to suspect the new bootkit is likely a proof-of-concept release. To date, ESET has found no evidence of actual infections in the wild.
Still, Bootkitty suggests threat actors may be actively developing a Linux version of the same sort of unkillable bootkit that previously was found only targeting Windows machines. "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." [...] As ESET notes, the discovery is nonetheless significant because it demonstrates someone -- most likely a malicious threat actor -- is pouring resources and considerable know-how into creating working UEFI bootkits for Linux. Currently, there are few simple ways for people to check the integrity of the UEFI running on either Windows or Linux devices. The demand for these sorts of defenses will likely grow in the coming years.
Still, Bootkitty suggests threat actors may be actively developing a Linux version of the same sort of unkillable bootkit that previously was found only targeting Windows machines. "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." [...] As ESET notes, the discovery is nonetheless significant because it demonstrates someone -- most likely a malicious threat actor -- is pouring resources and considerable know-how into creating working UEFI bootkits for Linux. Currently, there are few simple ways for people to check the integrity of the UEFI running on either Windows or Linux devices. The demand for these sorts of defenses will likely grow in the coming years.
Imagine a Beowulf Cluster... (Score:1)
Re: Imagine a Beowulf Cluster... (Score:2)
Imagine having unstoppable diarrh.... Eh, nevermind.
Re: Imagine a Beowulf Cluster... (Score:2)
Imagine a cloud data center infected by this - attacking all the other data centers.
Re: (Score:2)
article doesn't support summary (Score:5, Informative)
Summary claims firmware is infected.
Article claims GRUB and kernel are infected.
Re:article doesn't support summary (Score:4)
Yeah, looking like they all make use of the UEFI formalised storage(partition) on the HDD/SSD. So the idea of it being in the firmware is plain wrong.
Re: (Score:2)
Well, then the claim of "unkillable" is wrong as well. At least for people with some minimal hardware skills.
Re:article doesn't support summary (Score:5, Insightful)
I would still prefer a 1989-style BIOS flash jumper, though.
Please let me pay $10 more for a $0.04 jumper. I don't even care if it's dangerous by default to keep the support calls down.
Re:article doesn't support summary (Score:5, Insightful)
>"I would still prefer a 1989-style BIOS flash jumper, though."
THIS. I was going to say the same thing. Why can't we have some PHYSICAL barrier to messing with important stuff!?! Doesn't even have to be a jumper- how about holding the reset button why pressing power on?
Re: (Score:2)
how about holding the reset button why pressing power on?
Reset button? I haven't seen one of those for about twenty years. Well maybe that pinhole on the back of a router, but a computer, think of the costs! think of the bonus!
Re:article doesn't support summary (Score:5, Interesting)
That only worked because the BIOS chip was a ROM chip that had separate address, data and control lines. To write to them you needed to actually control the write enable line. The jumper made it such that it was not possible to write to the chip because it would physically disconnect the line.
These days, the BIOS is within a LPC (low pin count) interface, which is a bidirectional interface. There is no write enable line you can control - if you did it on the interface, it would disable it from working. It's just a high speed serial interface used to talk to many low speed peripherals without consuming many pins. There is no way you can physically disconnect the ability to write to the chip because you need to write to it in order to read from it.
Re: article doesn't support summary (Score:3, Insightful)
The interface doesn't prevent the possibility of having a write enable pin on the chip for the firmware.
Re: (Score:2)
And in fact many do indeed still have a WP pin. Sure it's a managed write protect, but that management is done internal to the memory chip. It can't be overridden without maybe something like a power glitch maybe.
Re: (Score:2)
It has. Just does not quite do what you expect it to do for the mainboards I looked at.
Re: (Score:3)
Very true. However, write protection, can be done at another level. For example, a bootloader can refuse to flash a ROM unless a physical attestation is done, or the enterprise signs the ROM with a "yah, this is a good ROM, hit it" key, which is in addition to the vendor key.
BIOS needs layers of protection. Going back to switches is critical, and ensures that unauthorized flashes don't happen. However, one important thing is that companies that sign BIOS revs must, and I mean MUST have their signing key
Re:article doesn't support summary (Score:5, Insightful)
For example, a bootloader can refuse to flash a ROM unless a physical attestation is done, or the enterprise signs the ROM with a "yah, this is a good ROM, hit it" key, which is in addition to the vendor key.
They already do this. UEFI capsules are supposed to be signed by the board manufacturer and verified by the firmware prior to flashing.
BIOS needs layers of protection. Going back to switches is critical, and ensures that unauthorized flashes don't happen.
Agreed.
However, one important thing is that companies that sign BIOS revs must, and I mean MUST have their signing key in a HSM.
Signing shit doesn't work. All it does is say these bugs are blessed, those bugs are not. No hacker is going to depend on the $5.00 wrench to make their bootkit work. If anything, the extra complexity added by X.509 certificate verification will be abused by the hacker to attack the system. (Nintendo knows this particular method of attack very well.)
The problem is that UEFI is an OS, which means it's complexity is so high, and the number of chefs in the kitchen at once so numerous (it can load third party binaries written for it, I.e. it's a standalone binary that can support specially written hosted binaries.), that the chances of finding an exploitable bug to compromise it is just as good as any other traditional OS.
Firmware is supposed to be simple. BIOS doesn't stand for Before Installation Operating System. It stands for BASIC Input Output System. Firmware should never perform the actions of the OS, but because some idiots thought everyone should have enterprise IT functionally shoved down their throats, (PXE Boot, Remote Management, automatic silent firmware updates, etc.), we got to where we are today. Because these idiots moved the goal posts from the easily replaced hard drive / SSD, to a soldered in chip on the motherboard that requires special tools and model specific replacement bits to fix. That's not simple at all, and the simplicity was supposed to cover as many people as possible. Not just IT nerds with an electronics soldering fetish.
The biggest layer of defense is the device owners having the ability to correct the problematic infection themselves. (Even if it's just shoving a WORM recovery disc into a drive and reformatting the machine by following instructions.) Otherwise you get a metric fuckton of infected hardware that takes ages to remove / replace because people don't want to spend their own money to fix something they aren't responsible for breaking. If the hardware manufacturers won't make that possible because profits, then there needs to be regulations that force those profits to be negative.
Re: (Score:3)
You are 100% right about that part. We are seeing firmware essentially acting as a full fledged hypervisor, be it virtualized or para-virtualized, such as the Minix install discovered.
If we didn't have to care about enterprise management, the job would be simple. If something needs to be flashed, then the user does something that goes out of the way, showing physical attestation to show the flash request is genuine.
However, the fact that so many systems have no way to recover from bongoed firmware is just
Re: (Score:2)
What is to keep someone from hacking a car make, flashing ECU firmware to force valves into the combustion chamber when the piston hits TDC, ...
A timing chain; the way the gods intended...
Re: (Score:3)
Where's the Crowdstrike edition for MINIX?
*ducks*
Re: (Score:2)
the extra complexity added by X.509 certificate verification will be abused by the hacker to attack the system. (Nintendo knows this particular method of attack very well.)
What happened with Nintendo?
Re:article doesn't support summary (Score:4, Insightful)
Or rather, it's hard because some bean counter thinks that keeping the entire world "UEFI Infection Ready" is more profitable because there aren't enough governments and private individuals filing lawsuits against them yet.
Re: (Score:2)
You'd imagine that the server vendors would have a range of 'secure' servers which have (say) a key switch to enable/disable firmware updates. The beancounters would be appeased because said key switch probably adds something like $200 to the price of the server ;-)
I know a good few places that would have that keyswitch in the off position, if they had the choice. But yeah, I know a (probably larger number) that would just put it to the 'enabled' position and forget where they left they keys ;-)
Re:article doesn't support summary (Score:4, Informative)
Actually, most SPI flash has a WP line (Write Protect). On the SPI flash I looked at it does not do full protection though, but some "bank protection" thing. And no, SPI FLASH is not LPC. That is a _different_ interface.
Re: (Score:2)
Yes. This. Or maybe a mode like modern PCs where you put the BIOS update on a USB flash drive, stick it in a slot, power the machine down, hold down a button on the back, so the motherboard processor (not the CPU) fetches the BIOS update and applies it, all offline. Something that takes direct user action.
For company owned PCs, have it signed by whatever MDM is managing them.
This should be a solved problem, as exactly the parent mentioned. People knew that rogue BIOS flashing was a thing decades ago, an
Re: (Score:2)
hold down a button on the back
Corporate IT departments will scream if they can't manage enterprise-wide updates from their comfy office*. Manufacturers will respond with remote capabilities and the rest of the world will have to suffer from their sloth.
*The one in Mumbai.
Re: (Score:2)
Why take such lame half measures? Socketed EPROMs eliminate issues with flash updates altogether.
Re: (Score:2)
I would still prefer a 1989-style BIOS flash jumper, though.
or EPROMS. If only we knew now what we knew then.
Re: (Score:2)
Indeed. I even engineered a physical write-protect switch for somebody that had to look at a lot of files from others back in the MFM disk days. These days you can get USB SSD enclosures with that switch though. But doing it for the BIOS is a bit tricky. Just connecting it to the R/W signal line does apparently not cut if for modern SPI flash chips, it just seems to do some "bank protection". Need to look at this a bit more. Maybe they are just using the wrong chips for it on the mainboards I looked at.
Re: (Score:2)
Google cared a lot about getting it right and I know in the past Chromebooks had this.
They also run Coreboot, so you can install your own Coreboot if you like.
Re: (Score:2)
Correction, it probably just disabled the singing, I guess Google could still do the signed updates.
Re: (Score:2)
Yet, the article says that the bootkit is "unkillable", which is obviously false.
A pity, I had a good opinion of the author of the article.
Re: (Score:1)
Yet, the article says that the bootkit is "unkillable", which is obviously false.
A pity, I had a good opinion of the author of the article.
Did they say that? The only use of the word "unkillable" I find in the article is:
Still, Bootkitty suggests threat actors may be actively developing a Linux version of the same sort of unkillable bootkit that previously was found only targeting Windows machines.
That seems fairly reasonable. If you're referring to the headline, the author almost certainly didn't write that, it would be some editor at the site. That's why headlines so frequently say something completely different than the articles, which maddens me greatly (especially considering that the headline is all most people see, most times).
Wait what? (Score:2)
Additionally, the inability to defeat Secure Boot limits infection opportunities to devices that (1) don’t enable the defense or (2) have already been compromised by the same attacker to install a self-signed cryptographic certificate.
Why would you install a signed bootloader shim only to also disable the very purpose of having a signed bootloader shim? Isn't the point of the signed GRUB shim to enable UEFI secure boot? *facepalm*
Re: Wait what? (Score:2)
Add to it that the key has to be known and if your installation media key isn't known by the uefi your option is to turn off secure boot unless you can install the key into the uefi.
Ventoy has an option where you can install an uefi key.
So the uefi might not be as secure as you think.
Re: (Score:2)
Ventoy has an option where you can install an uefi key.
My guess is the screen you see is actually a screen from the BIOS/firmware.
Re: (Score:2)
Possibly, but the design of it don't match the rest of the BIOS/UEFI style on the computer where it happens but is identical regardless of computer brand.
I have seen that on at least Dell and HP.
Of course - it could be some generic UEFI feature that the brand manufacturers don't care about because they think it's so rare that someone lands there.
Re: (Score:2)
1) Workaround Microsoft's NO OSS bootloader signing requirements (Because Microsoft controls Secure Boot signing not the device owner.) by embedding a new certificate within the closed source shim that verifies everything else.
2) Allow hardware that requires out of tree kernel modules to still work with a signed kernel by having shim load additional "trusted" certificates. (NVIDIA)
The big dirty secret of shim is the last one. It loads any cert that was created by t
Re: (Score:2)
2) Allow hardware that requires out of tree kernel modules to still work with a signed kernel by having shim load additional "trusted" certificates. (NVIDIA)
Seems like something that you should be able to disable.
At Last! (Score:5, Funny)
Re: (Score:2)
This particular bootkit actually isn't more able and doesn't do anything more special than any BIOS-based Linux bootkit from the past, so no.
Secure Boot protects from this (Score:2)
"The Bootkitty sample ESET found is unable to override a defense, known as UEFI Secure Boot"
So if an attacker gets root they can install anything into the EFI partition, and if secure boot is off, the computer will boot it? Whoop-de-doo... how is this anything new?
Re: (Score:3)
Currently, the malicious pre-grub patcher is stored on the ESP so it's as "simple" as using an external trusted host to scan the boot drive and erase it. The fact that it works on the kernel by just blinding overwriting certain offsets clearly says "this is a prototype." But if they can find a way to write it into the bios flash, that's Game O
Re: (Score:2)
if they can find a way to write it into the bios flash, that's Game Over... it would be (or at least, could be) absolutely impossible to eliminate it short of physically removing the BIOS memory and using an external flash programmer
This is true for some boards and not for others. Some do have an interface you can use to rewrite the chip. It is also sometimes possible to use a piggyback socket.
I still agree that there should be a jumper for BIOS write enable.
Re: (Score:2)
Re: Secure Boot protects from this (Score:1)
Is MBR still an option for Windows? (Score:2)
Re: (Score:3)
Windows 10? Yes. Windows 11? No. People should be migrating off of 10 to something else anyway.
Re: (Score:2)
That's interesting, because it was possible. I did it in a VM by accident by not turning enough stuff on and turning off too many checks. When I later wanted to turn all the features on I had to convert my "disk" to the newer format.
Re: (Score:2)
Officially (meaning if you ask Microsoft), it's not possible. Unofficially, there are ways to do it. Same with other new system requirements, like TPM.
Re: (Score:2)
Well, that makes sense anyway. I try not to ask Microsoft anything on account of not wanting to be lied to.
Re: There used to be a write-protect jumper (Score:2)
I can't see that it's in any way related.
Win11 shouldn't need to write to the uefi firmware.
Re: (Score:2)
Agreed. I think this is uninformed FUD, as that jumper vanished in most settings decades ago.
Know how I know your article is written by AI? (Score:2)
"To date, ESET has found no evidence of actual infections in the wild."
These contradictions are in the same paragraph. Not just the same article. No one edits their chatbot's work at Ars, apparently.
Re: (Score:2)
Is it possible they found the malware source or binary in the wild (hacker forums, dark web, etc.) but no actual infections have been found? I'm too lazy to re-read the article.
Re: Know how I know your article is written by AI? (Score:1)
Re: (Score:2)
That's nothing, /. editors don't even read the articles they steal.
Color me surprised (Score:2)
Putting an extensible mini operating system in the system firmware to use as a glorified boot loader? Color me surprised that it hasn't been exploited more often.
Seriously. the things that belong on my motherboard's Flash is simple. System board information, such as model number and layout. Default mappings of peripherals and slots on the bridge hierarchy. Some initialization for memory and bus training procedure. Trampolines for suspend and resume power states. Some boot loader code, like load some sectors
Re: (Score:2)
The old BIOS got hacked way more often than UEFI does. UEFI actually has a security model.
The old BIOS supported module loading as well, only it had to be x86 machine code. You need it to do things like boot from add-in cards like NICs and HBAs.
You also very much want the ability to load your own certificates because that's how you enable Secure Boot for your non-Windows bootloader, and you really want Secure Boot.
Re: (Score:3)
Putting an extensible mini operating system in the system firmware to use as a glorified boot loader? Color me surprised that it hasn't been exploited more often.
Seriously. the things that belong on my motherboard's Flash is simple.
While I agree with you in principle, this particular exploit doesn't attack any vulnerabilities in UEFI and Secure Boot themselves. Moreover, it's so primitive that even Secure Boot protects against it. Let's wait until the real exploits arrive.
Can this bypass secure boot? (Score:2)
Is this malware (and other similar nasties) bypassing secure boot somehow? Have the creators managed to get it signed? Is it only infecting systems without secure boot?
Re: (Score:2)
Is this malware bypassing secure boot somehow?
No.
Have the creators managed to get it signed?
No.
Is it only infecting systems without secure boot?
Them, and also already exploited systems where this malware's key has somehow been added to Secure Boot's allow list.
It's not "unkillable" anyway, so it's no big news.
Socketed firmware. (Score:3)
For the extra cautious the could be write-once chips that once written and verified, can't be infected.
BIOS updates will become far easier and lower risk.
This socket needs to be standardized across manufacturers, so we can have third party memory chips and usb flashers.
Re:Socketed firmware. (Score:4, Interesting)
>"We need socketed firmware chips that can be easily pulled out and programmed outside the PC. [...]BIOS updates will become far easier and lower risk.[/quote]
??? How is opening the computer and removing a static-sensitive chip, putting it in another socket outside the computer without ruining it, flashing it, and then all the reverse "easier"? It is a hell of a lot harder.
I think what is needed is
1) An optional setting that cannot be software-changed, that can be turned on which will force some type of physical challenge, which cannot be simulated in software, in order to approve writing critical BIOS/UEFI changes. This could be something with the reset button, or holding the power button on when applying power, or inserting a usb drive on a certain point with a certain file, or whatever.
2) A way to restore the BIOS/UEFI to a factory state. This would mean a protected backup of the data that cannot be physically changed, ever. And a physical method to trigger reverting back to it (like something already described). Many motherboards had this in the past ("Dual BIOS") and it should be standard.
Every owner needs #2. It should not be possible to "brick" a general purpose computer, period.
Individual users need #1, but it might not work out well for businesses trying to control lots of machines in mass updates. Unless they are willing to send a person around to every machine.
Re: Socketed firmware. (Score:2)
Option #2 is dumb. See Nintendo Wii and Super Smash Bros Brawl as why a read-only fixed backup is a bad ideaâ"it likely comes with bugs and youâ(TM)ve just gave it a permanent back door to exploit.
Unkillable? (Score:2)
Re: (Score:2)
Hard drive replacement/formatting fixes it. No need of firmware reflashing. Affected PCs may need to have their Secure Boot key storage examined, though.
UEFI attack not Linux ... (Score:3)
This is ESET just stirring up fear to get people to buy their products ...
They state themselves have not found this .... and it's nothing to do with Linux ...