Elektrine lite

← Feed

@dangoodin@infosec.exchange

Post #2405711

2024-07-25 18:10 UTC

In 2012, an industry-wide coalition of hardware and software makers adopted Secure Boot to protect against a long-looming security threat. The threat was the specter of malware that could infect the BIOS, the firmware that loaded the operating system each time a computer booted up. From there, it could remain immune to detection and removal and could load even before the OS and security apps did. To this day, key players in security—among them Microsoft and the US National Security Agency—regard Secure Boot as an important, if not essential, foundation of trust in securing devices in some of the most critical environments, including in industrial control and enterprise networks. On Thursday, researchers from security firm Binarly revealed that Secure Boot is completely compromised on more than 200 device models sold by Acer, Dell, Gigabyte, Intel, and Supermicro. The cause: a cryptographic key underpinning Secure Boot on those models that was compromised in 2022. In a public GitHub repository committed in December of that year, someone working for multiple US-based device manufacturers published what’s known as a platform key, the cryptographic key that forms the root-of-trust anchor between the hardware device and the firmware that runs on it. The repository included the private portion of the platform key in encrypted form. The encrypted file, however, was protected by a four-character password, a decision that made it trivial for Binarly, and anyone else with even a passing curiosity, to crack the passcode and retrieve the corresponding plain text. The disclosure of the key went largely unnoticed until January 2023, when Binarly researchers found it while investigating a supply-chain incident. Now that the leak has come to light, security experts say it effectively torpedoes the security assurances offered by Secure Boot. “It’s a big problem,” said Martin Smolár, a malware analyst specializing in rootkits who reviewed the Binarly research and spoke to me about it. “It’s basically an unlimited Secure Boot bypass for these devices that use this platform key. So until device manufacturers or OEMs provide firmware updates, anyone can basically… execute any malware or untrusted code during system boot. Of course, privileged access is required, but that’s not a problem in many cases.” https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/

Replies (24)

  • @keen456@infosec.exchange 2024-07-25 18:43

    @dangoodin@infosec.exchange Hi Dan, the PowerShell command in the article has an error- GFD in the comments has the right one. Enjoyed the article a lot.

    Open ##3187077

  • @dangoodin@infosec.exchange File under "News that makes people want to retire and raise chickens, until they remember bird flu."

    Open ##3187079

  • @slothrop@chaos.social 2024-07-25 19:05

    @dangoodin@infosec.exchange Computers were a mistake, pt. 83,517

    Open ##3187080

  • @Rairii@social.nano.lgbt 2024-07-25 19:33

    @dangoodin@infosec.exchange oh, good thing I publicly backed up those github repos last year when I found them archive.org/details/aaeon-uefi-firmware-git-repos

    Open ##3187081

  • @kgb1001001@mstdn.social 2024-07-25 19:42

    @dangoodin@infosec.exchange wasn’t this literally the plot of “Red Team Blues” by @pluralistic@mamot.fr?

    Open ##3187082

  • @ralfmaximus@mastodon.social 2024-07-25 19:47

    @dangoodin@infosec.exchange > Of course, privileged access is required, but that’s not a problem in many cases.” Doesn't that make it an "already past the air lock" kind of attack? Like, a privileged user would have to knowingly execute a link or file while ignoring all the anti-malware warnings thrown up by the o/s. Windows UAC would stop this, assuming the user is paying attention, right? What am I missing?

    Open ##3187085

  • @dangoodin@infosec.exchange so something that's essentially is only slightly less important than the nuclear launch codes is protected by.. .. "clown farts"?

    Open ##3187091

  • @lispi314@udongein.xyz 2024-07-25 20:04

    @dangoodin@infosec.exchange @cstross@wandering.shop Will we finally start getting rid of platform keys and having users provision their own? That'd be nice. There's no reason to trust the corposcum not to sign malware for state surveillance agencies.

    Open ##3187092

  • @aracnus@hub.teia.bio.br 2024-07-25 20:34

    :astonished_face:

    Open ##3187102

  • @shadow06@mastodon.social 2024-07-25 20:37

    @dangoodin@infosec.exchange Use Linux, roll your own.

    Open ##3187103

  • @mhkohne@mastodon.social 2024-07-25 20:39

    @dangoodin@infosec.exchange Can we just go back to masked ROM, please? When the BIOS couldn't be flashed in the field, it also couldn't be compromised in the field.

    Open ##3187106

  • @Fedihacker@masto.es 2024-07-25 20:45

    @dangoodin@infosec.exchange That was close. My motherboard is MSI.

    Open ##3187107

  • @phil_stevens@mastodon.nz 2024-07-25 22:14

    @dangoodin@infosec.exchange Phew. My laptop is from 2017.

    Open ##3187108

  • @coffeetest@infosec.exchange 2024-07-25 22:17

    @dangoodin@infosec.exchange I remember arguing with someone about this way back. I am not sure why I was so opposed back then but this result doesn't surprise me. IIRC maybe I was sure this was just a way to try and lock out unapproved OSs i.e. Linux but to be honest I can't recall. The augment against me was like "but but but security!!!!!!1!!1!"

    Open ##3187111

  • @dangoodin@infosec.exchange For those looking for the command on Linux: you must first install the eftools package `sudo apt-get install efitools` `efi-readvar -v PK`

    Open ##3187113

  • @ericdube@mastodon.social 2024-07-26 02:48

    @dangoodin@infosec.exchange I'm starting to feel something of this severity is coming to surface on a weekly basis lately.

    Open ##3187114

  • @privateger@plasmatrap.com 2024-07-26 05:08

    @dangoodin@infosec.exchange Have these "industry-wide secret keys" ever worked? It's always some dumb stuff like this in the end ​:floofWoozy:​

    Open ##3187115

  • @casandro@f-ckendehoelle.de 2024-07-26 05:38

    @dangoodin@infosec.exchange Well it's "Secure Boot". The security it's meant to provide is for business models, not for user data. So as a user I couldn't care less.

    Open ##3187116

  • @dangoodin@infosec.exchange I'm not sure UEFI with its large attack surface is better, security-wise, than good old BIOS which was at least easily auditable.

    Open ##3187117

  • @jgordon@appdot.net 2024-07-26 22:39

    @dangoodin@infosec.exchange Thank Darwin that was the only blunder compromising Secure Boot and we can absolutely trust it otherwise. (Are typewriters still being made? I had a very fine electric typewriter with small edit buffer I gave away in the 90s. Now it would be worth thousands :-)

    Open ##3187118

  • @g0xmkamovz@mastodon.world 2024-07-28 06:53

    @dangoodin@infosec.exchange I thought secure boot was mainly for Microsoft to strong-arm people away from Linux?

    Open ##3187119

  • @datenwolf@chaos.social 2024-07-28 15:49

    @dangoodin@infosec.exchange nitpick: Secure Boot cannot and does not protect against firmware-level malware. That was never the goal. Secure Boot is intended to protect against booting a compromised operating system. That's all it can do, by design. And as this key leak shows, it's a pretty bad design at that. The better approach would have been implementation of a plain measured boot environment, used for deriving a system image unlocking key. If the machine was manipulated, key derivation would fail.

    Open ##3187120

  • @leo@60228.dev 2024-08-25 18:28

    @dangoodin@infosec.exchange is this not the exact thing described in this fwupd github issue from nearly 4 years ago? https://github.com/fwupd/fwupd/issues/2695

    Open ##3187121

  • @dangoodin@infosec.exchange This may be a utility to test for this issue, or a similar one 🙄🤦‍♂️ https://www.grc.com/isbootsecure.htm

    Open ##3187123