CosmicStrand: The discovery of a sophisticated UEFI firmware rootkit
securelist.com
securelist.com
I always marvel at the ingenuity and technical complexity of these kinds of attacks, but this is also something that makes me lose sleep at night.
I can’t help but wonder just how utterly compromised we all are, and won’t know it until many years down the line.
I don't know which one it is.
> Windows doesn’t allow you to do that by default unless you’re an admin.
The refutation is that by default users are an admin. So no, they’re not protected against persistent threats like UEFI malware.
Most people are not going to be downloading random executables and running them, since software is managed through App stores nowdays.
One would have to first craft the shellcode insertion into the exploit, which is not exactly trivial, then hope that enough users visit a particular website to get infection (which is a negative feedback loop as the more users visit a website, the more likely it is to get scanned and reported as containing malware), then drop a crafted executable to presumably steal something that is worth money, which is a whole separate problem.
Possible? Definitely. So is you getting held up, your car stolen, and chopped up for parts, with no available recourse. Both are rather unlikely.
pluton is about burying TPM and keys in the processor package rather than as a separate host on the bus. this could be defeated by using microsurgical technique to reveal the die and alter the connections, an extreme effort requireing an extreme motivation.
Like Microsoft? And like government actors compelling Microsoft via things like NSL’s?
I wrote about the potential for this problem in 2014 for my graduate thesis.
https://search.proquest.com/openview/cd06aab6e06951ba6cdc064...
Edit: to the parent, I shared many of the same concerns back then, too. I tried to speak to those anxieties in my final product.
Look at “bump keys” for example. Those who have the knowledge walk right through security barriers like they aren’t there and meanwhile security companies make optimistic claims of safety just to sell more locks.
It's not hard to imagine.
USB-C 3.0+ cables all need chips inside them for negotiating USB-PD, among other things.
Imagine what could be done with an infected USB-C cable. Yes, of course, keyloggers are possible (that's been done plenty in the past with regular old USB-A 2.0), but think about one of USB-C's common applications: docking stations.
If you hooked up your laptop to a docking station with a malicious USB-C cable and you had ethernet, an external monitor, and a keyboard plugged into the dock, you would basically be giving an attacker a VNC session. It could scoop up everything you type, everything on your screen, and communicate via a connection that is entirely transparent to the OS.
At that point, your only hope is a firewall flagging the connection, otherwise you'll be completely oblivious to the ongoing surveillance. And it could compromise a network connection to insert a malicious payload into a file you're downloading, just to make the surveillance persistent when you're not plugged in.
It's silly to pretend a BSD OS is going to be immune of the consequences of an EFI which is compromised at birth. Sooner or later there will be a value chain in compromising my OS, through the EFI.
I wish we had better out of band EFI validity checks, based on what the manufacturer thinks should be there, as a reproducible bitstream.
https://www.dell.com/support/kbdoc/en-us/000126098/what-is-d...
While some may argue that this header would be the perfect place to install a implant, doing so is vastly harder than popping some manufacturers computer. Also, since the header will be specifically checked by some users, it becomes a very risky place to install an implant.
Having sockets would increase the costs ($1-20/flash chip) and doesn't raise the sophistication level of the attacker from unskilled labor (literally anyone in the chain of custody) to skilled labor (eg: someone that can do SMT or BGA rework).
It's not out of band and therefore vulnerable to massively clever malware, but it's still useful.
[1]: https://raspberrypi.stackexchange.com/questions/8963/are-the...
[2]: https://www.raspberrypi.com/documentation/computers/raspberr...
[3]: https://security.stackexchange.com/questions/97246/badusb-wh...
[4]: https://security.stackexchange.com/questions/44750/malware-t...
Cognitive dissonance is a scary thing, makes people doublethink by repressing the conflict between expectation and observation into the subconscious.
Could this indicate a higher likelihood of it being a consumer board supply chain attack? It might explain the lack of detection in business oriented computers, though it also would seem to indicate that it was not precisely targeted.
Aside from open source UEFI setups like Tiano, you can also use CoreBoot or LinuxBoot where UEFI doesn't work for you.
And so... this could be undetected just because kaspersy isn't being used anymore?
Also the article says it clearly that the uefi rootkit is searching and replacing functions within the kernel and then putting them back once the next phase is complete, in order to avoid security check.
Hooking in windows is a technique allowed by the OS, while this "hooking" is nothing more than just simple search/replace file operation. That's being taught like in 1st month on any coding school.
now if you were handed only the binaries, and left to objdump them etc, how long? evidently there’s symbol names since the article uses those. so hopefully no more than an extra order of magnitude: a couple weeks, maybe a full month if my manager’s asking for a deadline and i want to be conservative?
also, think about where/how they hooked: it sounds like they hooked at the equivalent of an interface boundary, where it’s easiest to inject a new implementation — but then they have to check the return address to know where in the larger scope of the process they’re currently at: if you had access to the codebase and build tools why wouldn’t you patch your exploit into the code more directly and just rebuild it? why abuse the return address like that?
i don’t mean to say it’s not impressive, but it’s not magic. there are lots of competent engineers out there capable of reverse engineering a UEFI implementation.
People who developed such specifications in the first place, like UEFI, would be great candidates for an organization looking for someone with deep knowledge of the subject.
Ooh, I recognise that name. They were involved in certificate shenanigans with Startcom. I'm immediately suspicious.
(I've barely started reading the article, but I'm predisposed to distrust anything involved with Qihoo)
ugh
Tech companies are all subjects to the government in which they operate.
They have become spies. The real terror is when you can't buy chips that don't spy on you.
So about 5 years ago?
I wonder if those computers could be used for false flag operations?
(A rain of downvotes falls on me)
Seriously, even good old BIOS is susceptible to rootkits, there has been tons of them. So no crying over UEFI please.
We need a fully signed and auditable chain of trust for booting OSes.
Of course all this crap needs to be open source but it needs to be locked down to prevent not trusted binaries as much as possible.
And for the 1% of people who are going to bang about their right own the hardware and run Linux and what not (I'm definitely one of those), we need to be able to do it but in an obvious way (computer should boot but display a clear message that it's been tinkerer with).
I really like software freedom, but the fact that I can disable secure boot on pretty much any computer I have physical access to and that the user will never know about it is not okay.
Alert fatigue is real.
Also, it's not just about booting windows or the OS, it's about the UEFI, which even fewer people are going to want to tinker with.
It's not just the severity of harm but also it's frequency.
- it's proprietary
- it's controlled by entities that have a terrible track record
- it's going to be, as usual, forced upon everybody without consent
For the third one, nobody is forcing you to buy a specific product, but yes, it will be hard to avoid.
But like for vaccines, individual consent is at odds with the greater good. Society needs computing that it can trust.
Maybe the solution is a healthier hobbyist market where you can buy "use at your own risk" unlocked computers? Maybe we need laws to force manufacturers to make such models? I don't know. But most people, from my mom to my CEO need a computer that will run what it is supposed to run.
It's not 1990 any more, PCs do way too important things.
There's no reason to think a large, opaque computing base that's been forced into the market by a monopoly power is trustworthy. I'd argue that "boot sector tampering with physical access" is pretty low on the list of computer-related real-world attacks against society; it's certainly lower than zero-days caused by implementation errors in baroque computer software / hardware.
Also, suggesting you can avoid having a computer (or phone) at this point is ludicrous. It's like suggesting you can avoid using credit cards and cash. Some would argue it is actually easier to give up living under a roof than to give up owning a cell phone (and make exactly that tradeoff).
My mother does not have an Internet connection. Or a computer. Or a cell phone.
She definitely prefers to live under a roof. She's just not interested in any of the above.
The playbook that is unfolding right now with pluton is the exact opposite.
Then it shouldn't mess with trust. Closed source tricks is not trust. And MS lost its credibility long ago. Every closed system on a computer inspires distrust.
Yes it is being forced. We have single digit years before participation in society becomes impossible without a device that attests that it is not under the control of the owner. First it will be banks, then government services, then access to the social graph, and so on.
> But like for vaccines, individual consent is at odds with the greater good. Society needs computing that it can trust.
So not under the control of centralised corporations that get paid when they successfully manipulate you into doing something you wouldn't otherwise, and have a proven track record of unaccountable censorship.
[1] Example: 176 pages at https://trustedcomputinggroup.org/wp-content/uploads/PC-Clie...
[2] Example: 2540 pages at https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9...
Hence the suggestion to make it tamper obvious.
As for the attack surface, it is true, but it's a separate problem. You don't have to bloat your firmware to make it trusted.
I don't think there was any chance for a typical system owner to have the time or skill or even the foundation required to understand if their machine's BIOS is vulnerable or compromised. UEFI provides some basis to actually start with that process.
I also think there is a real opportunity to write open-source versions of these components in safe/verifiable languages. That way we could have our cake and eat it too.
I would take that bet, if there were any way to objectively assess. The surface area of BIOS is just so much smaller.
> I also think there is a real opportunity to write open-source versions of these components in safe/verifiable languages.
In theory yes. In practice they're always going to be giant blobs of C written by hardware makers, massaged just enough to get Windows to boot.
I'd love to see a similar effort at ensuring boot integrity for Linux, but way too many distros can't even handle Secure Boot with Nvidia/DKMS. Though even more practical features, one being (f)TPM-backed FDE, are very cumbersome and underutilised.
"Looking at the various firmware images we were able to obtain, we assess that the modifications may have been performed with an automated patcher. If so, it would follow that the attackers had prior access to the victim’s computer in order to extract, modify and overwrite the motherboard’s firmware. This could be achieved through a precursor malware implant already deployed on the computer or physical access"
While Secure Boot + BitLocker with TPM and PIN would have prevented an Evil Maid attack (at least would have triggered a PCR change and a Windows Recovery prompt), a preliminary infection (I understand by it a supply chain attack before it reaches the user for the first time, but maybe I'm extrapolating a bit what the report is saying) would have stayed undetected in most scenarios (depending on how Intel Boot Guard is configured).
Regarding the Linux part, ANSSI did a pretty great job with their CLIP OS implementation: https://docs.clip-os.org/clipos/boot_integrity.html, but it's really "for the masses" :(
Were there? I couldn't find anything, but then again Google is garbage nowadays if you want to find older stuff.
To my understanding, the limitations of the old BIOS world would've made it much harder to hack on it other than maybe enabling hidden menus.
The UEFI world is so much larger, more powerful and already offers plenty of abstractions and services. You can probably write a relatively portable rootkit that works across a plethora of different Mainboards and Chipsets. And then you come in and try to fix it with secure boot, and when secure boot isn't good enough anymore you add pluton and then what?
And what's your threat model anyways? "Professional Hackers" nowadays are in it for the money. Why would they want to custom tailor a rootkit for your BIOS? Why would they want to target you with a generic UEFI rootkit? Apparently, crypto ransomware is perfectly capable of infecting a user on windows with secure boot enabled. No need for a rootkit.
Who is going to be interested in rootkitting you besides a government backed hacking op? And in that case, I fully trust them to be able to get around any secure boot measures either with yet another exploit, or because they have access to the signing keys one way or the other.
That sounds more like he just got the BIOS erased and replaced with something else entirely, rather than something intended to parasitically coexist.
Also, for a while, they had write-protect jumpers.
The only way a TPM could help is if it was the boot loader. But that can't be, not unless the TPM were a firmware TPM running in tight cooperation with the ME.
I think physical access overriding digital security should largely be fine though, because we have a lot of tamper-evident devices for identifying physical access but you largely can't do that for digital.
Like, I can imagine a more consumer friendly PSB using a physical "key" plugged into the motherboard that's essentially a ROM board but using human visible solder pads for the bits of the key. And you could order your own key pair that comes with signing keys from the CPU vendor if you want to sign your own authenticated firmware.
> Of course all this crap needs to be open source
All I can hypothesise is that some entity with huge vested interests is now trying to do damage control.
to prevent not trusted binaries
"trusted" by who? The faceless bureaucracy that wants to control every bloody aspect of your life?
Those common rootkits were not in the BIOS firmware, they were just malicious code on the hard drive. But the code was written on drive space not used by the file system so it withstood malware scanning of the volume and often reformatting/restoration too.
The Master Boot Record (fist 440 bytes of sector 0) would often need to be renewed from trusted media, and the malicious code zeroed using a raw disk editor which can address sectors which are not within the file system.
Or the shotgun approach could be taken and the whole HDD zeroed.
I mean realistically, we'd be naive to not expect that state-sponsored hackers have rooted machines somewhere in the supply chain (hardware, firmware and of course software). Is everyone being monitored all the time? No, but I'd stay away from electronics if I expected an intelligence agency was interested in me.
Though I’d happily cooperate if me watching team did exist and came out of shadows to clarify their doubts and pass along the taxpayer money saved :)
To use with a modified Linux kernel that emulates a bog standard Thinkpad uefi environment of course.
EDIT: I forgot to phrase this as a question - besides missing a QubesOS or KickSecure on top, is this a decent plan for airgapped stuff?
UEFI can be emulated on top of BIOS using something like Clover. But for your BIOS-only mobo, just keep using it with a BIOS-only bootloader, ie GPT disk with grub or whatever written to the MBR + BIOS Boot partition. There's no reason to involve any UEFI, emulated or otherwise.
You will obviously not have as good protection from evil maid attacks as you would've gotten from Secure Boot. But presumably you're okay with that, and emulated UEFI will not help in that regard anyway.
I didn't say it did. In fact I formulated what I wrote precisely to convey the opposite message.
>they can replace the currently active UEFI bootloader with a shim app, enroll their own key.
UEFI can be protected by a password if the implementation supports it. How secure that is is of course up to the implementation.