CosmicStrand: The discovery of a sophisticated UEFI firmware rootkit

&gt; <i>The most striking aspect of this report is that this UEFI implant seems to have been used in the wild since the end of 2016 – long before UEFI attacks started being publicly described. This discovery begs a final question: if this is what the attackers were using back then, what are they using today?</i><p>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.<p>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 live in fear of being told my factory delivered Dell rackable servers have been EFI infected since inception on my network.<p>It&#x27;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.<p>I wish we had better out of band EFI validity checks, based on what the manufacturer thinks should be there, as a reproducible bitstream.

I wonder why more computers don&#x27;t use the simple boot model that devices like the Raspberry Pi use. From what I&#x27;ve heard, the RPi is effectively immune from persistent malware. Firmware can&#x27;t be modified [1], and while the second stage bootloader can be flashed in the RPi 4, the first stage bootloader can&#x27;t be modified [2]. What this basically means is that no matter what infects your pi, you can always just replace the SD card and restore it to a clean state. In contrast, I&#x27;ve heard so much news about how USB firmware can get reprogrammed [3], how PC malware can survive BIOS reflashing [4], how malware can live in external drive firmware, etc. Of course, if there&#x27;s a bug in the raspi firmware, it also can&#x27;t be fixed, but the attack surface is so small I&#x27;m willing to make the trade-off (and buy a new pi if it comes to light).<p>[1]: <a href="https:&#x2F;&#x2F;raspberrypi.stackexchange.com&#x2F;questions&#x2F;8963&#x2F;are-the-bios-and-firmware-located-on-the-sd-card" rel="nofollow">https:&#x2F;&#x2F;raspberrypi.stackexchange.com&#x2F;questions&#x2F;8963&#x2F;are-the...</a><p>[2]: <a href="https:&#x2F;&#x2F;www.raspberrypi.com&#x2F;documentation&#x2F;computers&#x2F;raspberry-pi.html#raspberry-pi-4-boot-flow" rel="nofollow">https:&#x2F;&#x2F;www.raspberrypi.com&#x2F;documentation&#x2F;computers&#x2F;raspberr...</a><p>[3]: <a href="https:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;97246&#x2F;badusb-why-are-firmware-writeable-in-the-first-place-manufacturers-backdoor" rel="nofollow">https:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;97246&#x2F;badusb-wh...</a><p>[4]: <a href="https:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;44750&#x2F;malware-that-can-survive-bios-re-flashing" rel="nofollow">https:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;44750&#x2F;malware-t...</a>

I remember being called a reactionary naysayer like, 8 years ago, because i told that this would happen.

This rootkit is old by computing standards (2016), and apparently found somewhat by chance in that it was found in free (probably consumer) users of their product.<p>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.

My hopes of large volume fully open source systems died when I learned that beefy RISC V boards will ship with UEFI.

Regarding the alegation that sems to be chinese actor: isn&#x27;t kaspersky gone from the western world after russia x ukraine?<p>And so... this could be undetected just because kaspersy isn&#x27;t being used anymore?

Such sophisticated attacks always amaze me, and I&#x27;ve always wondered how people go about developing them in the first place.

The ars technica article said it was windows focused, but the same techniques should work on other OS. If you had network monitoring how hard would it be to see this firmware-kit trying to talk to the internet. Is it sophisticated enough to hide in normal traffic somehow?

&gt; One of our industry partners, Qihoo360,<p>Ooh, I recognise that name. They were involved in certificate shenanigans with Startcom. I&#x27;m immediately suspicious.<p>(I&#x27;ve barely started reading the article, but I&#x27;m predisposed to distrust anything involved with Qihoo)

Chipsec (<a href="https:&#x2F;&#x2F;github.com&#x2F;chipsec&#x2F;chipsec" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;chipsec&#x2F;chipsec</a>) is a project to check for bugs in your firmware.

This exploit would only work when CSM is enabled? Nowadays with SecureBoot I think it would have to be much more complex? (patching all functions in UEFI, bootloader and OS to bypass the verification).

as a civilian, I am repeatedly amazed at the relentless, intrusive and manipulative tactics that the &quot;heroes&quot; use on the &quot;sheep&quot; .. I am quite capable of managing my own affairs and have invented and solved using computers for decades. I have a sense of personal sovreignty that is offended and threatened by one-way-mirror, controlling, destructive Spy-vs-Spy comic books being played out by eternally funded jerks. I am not running to DELL to save me from &quot;scary&quot; hacks -- indeed, I am being victimized and trodden on by DELL and &quot;state actors&quot; .. DELL <i>is</i> a &quot;state actor&quot; ..<p>ugh

This is something that Pluton &#x2F;TPMs can help prevent via attestation. Pretty funny to read comments here saying that they wish there was a way to plug something into a motherboard to verify all of the software&#x2F;firmware components.

If you have good info or known to have “good” info, just assume you are being watched.

&gt;We were able to identify victims of CosmicStrand in China, Vietnam, Iran and Russia.<p>I wonder if those computers could be used for false flag operations?

That&#x27;s why things like the Pluton processor and TPMs are useful.<p>(A rain of downvotes falls on me)<p>Seriously, even good old BIOS is susceptible to rootkits, there has been tons of them. So no crying over UEFI please.<p>We need a fully signed and auditable chain of trust for booting OSes.<p>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.<p>And for the 1% of people who are going to bang about their right own the hardware and run Linux and what not (I&#x27;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&#x27;s been tinkerer with).<p>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.

Hah, this reminds of a security researcher a few years ago that was reporting malware that he couldn&#x27;t research without infecting his other machines. I&#x27;m fuzzy on the details, but everyone wrote him off as a paranoid delusional and the incident was quickly swept under the rug. Makes me wonder if he found some sophisticated state sponsored stuff and got smeared to hush it up.<p>I mean realistically, we&#x27;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&#x27;d stay away from electronics if I expected an intelligence agency was interested in me.

Furious searches for BIOS only era hardware are taking place on ebay as we speak.<p>To use with a modified Linux kernel that emulates a bog standard Thinkpad uefi environment of course.<p>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?