[HN Gopher] Bootkitty: Analyzing the first UEFI bootkit for Linux
___________________________________________________________________
Bootkitty: Analyzing the first UEFI bootkit for Linux
Author : doener
Score : 89 points
Date : 2024-11-28 11:02 UTC (11 hours ago)
(HTM) web link (www.welivesecurity.com)
(TXT) w3m dump (www.welivesecurity.com)
| jmclnx wrote:
| FYI Related articles:
|
| https://news.ycombinator.com/item?id=42262525
|
| https://news.ycombinator.com/item?id=42264655
| jmclnx wrote:
| I found this a rather interesting read, nice.
|
| I cannot help but think the move to UEFI and Secure Boot made
| things less secure :(
| brookst wrote:
| The article says that Bootkitty does not work if Secure Boot is
| enabled. How do you figure Secure Boot made things less secure?
| ghjfrdghibt wrote:
| Gonna assume it's because you have to disable it to run your
| operating system of choice, unless you beg Microsoft to let
| you.
| brookst wrote:
| So that would be _undesirable_ if true, but how would it be
| _less secure_ than not having secure boot?
|
| Of course, most/all SB BIOSes enable setting your own
| platform key.
| athrowaway3z wrote:
| Because it can lock the door behind itself in an opaque
| hardware-dependent layer users have no control over.
|
| If i were to design security from the ground up it would
| be a small external sdcard for firmware and kernel (with
| a hardware r/w toggle), and optionally a external sdcard
| adapter that verifies the hash of the content.
|
| Everything else is as dumb as bricks and gets its
| firmware loaded from the sdcard.
|
| We didn't do that because secure boot was solving the
| problem of large orgs with remote administration in mind,
| and designed by orgs happy to sell yearly advanced
| cybersecurity protection shield plus certification
| subscriptions.
|
| Designing for remote administration by an IT department
| will.. increase the attack surface for attackers to
| remote administrate my device.
| fsflover wrote:
| > If i were to design security from the ground up
|
| You might be interested in Librem Key, based on free
| firmware?
| KennyBlanken wrote:
| You only need disable it until you've got that OS
| installed, and then you can re-enable it. All the major
| linux distros have supported Secure Boot for years (which I
| was not aware of, and will now look into setting up!)
| j0057 wrote:
| FUD: you can install your own keys, enable secure boot and
| run the OS of your choice.
| eightys3v3n wrote:
| And significantly more complicated to setup and maintain in my
| limited experience :|
| Doe-_ wrote:
| What makes you think that? Secure Boot prevents this rootkit
| from running and is the recommended mitigation:
|
| > Bootkitty is signed by a self-signed certificate, thus is not
| capable of running on systems with UEFI Secure Boot enabled
| unless the attackers certificates have been installed.
|
| > To keep your Linux systems safe from such threats, make sure
| that UEFI Secure Boot is enabled
|
| In fairness, the blog post confusingly says this in the next
| bullet point:
|
| > Bootkitty is designed to boot the Linux kernel seamlessly,
| whether UEFI Secure Boot is enabled or not, as it patches, in
| memory, the necessary functions responsible for integrity
| verification before GRUB is executed.
|
| However, this would still require Rootkitty to have gained
| execution already, which it wouldn't be able to if Secure Boot
| was enabled and the malicious actor's certificates weren't
| installed.
| otabdeveloper4 wrote:
| "Secure boot" is not actually meant to improve security.
|
| It exists as a moat to make it harder to install Linux on your
| (Microsoft) PC.
| exe34 wrote:
| does it also help keep drm keys safe? that's how it works on
| Android, they even delete the 4k keys if you root your phone.
| telgareith wrote:
| What!? Last I checked even with ring0 the system didn't
| have access to the WideVine keys. Talk about yet another
| reason to just pirate everything
| exe34 wrote:
| or buy them, but obtain a pirated version to recover
| what's yours when they lock you out.
| 1oooqooq wrote:
| and identity. most of the world now replaced your credit
| card and government id with apps that rely on the OS
| assurences to prove you're yourself with vendor keys,
| mandatory selfies and such.
| AzzyHN wrote:
| It's more secure than not having Secure Boot.
| 65a wrote:
| UEFI itself is way too complex, has way too much surface (I'm
| surprised this didn't abuse some poorly written SMI handler),
| and provides too little value to exist. Secure boot then goes
| on to treat that place as a root of trust, which is security
| architecture mistake, but works ok in this case. This all could
| be a lot better.
| pluc wrote:
| It was just a way for Microsoft's partners to limit the ease
| with which one can install alternative OSes. Try explaining to
| your mother how to disable SecureBoot to install Ubuntu. It
| used to be a single sentence - pop the CD in and follow the
| instructions, but Microsoft couldn't have that. As is always
| the case with Microsoft, security is never the goal unless they
| gain a competitive advantage or make it harder for their
| customers to move away in the process.
| KennyBlanken wrote:
| "It was just to keep people from installing something other
| than Windows" seems very counter-indicated by it taking ~7
| years for a Windows UEFI bootkit to come out, and 13 years
| for one for Linux.
|
| ...and this bootkit is not able to work if Secure Boot is set
| up.
|
| UEFI is also a godsend in terms of fixing a lot of the legacy
| BIOS crap
| 1oooqooq wrote:
| > and this bootkit is not able to work if Secure Boot is
| set up.
|
| wrong.
|
| > UEFI is also a godsend in terms of fixing a lot of the
| legacy BIOS crap
|
| that's like saying cutting the baby in half to end the
| dispute also solved the crying
| Aissen wrote:
| > Try explaining to your mother how to disable SecureBoot to
| install Ubuntu
|
| Good news: you don't need to!
| bri3d wrote:
| What?
|
| I agree the move to UEFI added a huge new attack surface and
| that most UEFI implementations (notably, even the open source
| ones) are teeming with horrible bugs.
|
| And yes, then linking the trust architecture for Secure Boot so
| deeply with UEFI means that UEFI bugs are also Secure Boot
| bugs.
|
| But to say this is less secure? No way. Traditional BIOS-based
| MBR backdoors are like 1980s oldschool classic stuff. Most
| adversaries would require a good degree of development work to
| backdoor / root kit a PC they were given with Linux, Secure
| Boot, and an encrypted filesystem. With a BIOS based PC there
| would literally be nothing to do.
| nature556 wrote:
| What does the discovery of the Bootkitty UEFI bootkit for Linux
| systems suggest about the evolving landscape of cybersecurity
| threats?
| Brian_K_White wrote:
| It means "just trust us" is not and never was secure.
|
| Trustworthy people don't ask you to trust them.
| Joker_vD wrote:
| Indeed. For example, none of those CA in the built-in bundle
| in my browser ever asked me to trust them, that's how I know
| they are trustworthy.
| AshamedCaptain wrote:
| Nothing. This is just a proof of concept that is ridiculously
| easy to detect. If your attackers can drop files in your /boot
| or /boot/efi directory, I think you have much worse things to
| worry about than this.
|
| In fact, this bootkit would be about the least thing I would
| worry about. Because by the time an attack can write to /boot,
| they can also write to /etc/init.d . And the later is not
| protected by "secure boot".
| KennyBlanken wrote:
| > Because by the time an attack can write to /boot, they can
| also write to /etc/init.d . And the later is not protected by
| "secure boot".
|
| Bootkits are to make the infection both more difficult to
| detect and remove, so whether /etc/init.d is writable is
| pretty irrelevant.
| AshamedCaptain wrote:
| How is an infection hidden somewhere in the friggin entire
| rootfs easier to detect and remove that one that literally
| replaces the one file for your kernel /boot ? What
| advantage could the latter possibly have ? Not to mention
| that something from a bootkit bootstrapping an infection in
| the root filesystem is the realm of useless tech demos like
| this one; while for something that can already write your
| rootfs, infecting the kernel is trivial.
|
| The entire boot system has much, much fewer places for
| malware to hide compared to the entire "rootkit" OS attack
| surface which is astronomically larger. Secure Boot has
| always targeted the smaller and most useless of the swiss
| cheese holes.
| Brian_K_White wrote:
| I guess we need to go to back to socketed eeprom chips.
|
| Or just in general machines that are wholly controlled by the
| owner.
| voxadam wrote:
| Previously: https://news.ycombinator.com/item?id=42260346
| ddtaylor wrote:
| The researchers are keen to note things about this, but also
| likely want to avoid giving attackers "more ideas", which I feel
| limits the discussion. Plus, I highly doubt these attackers don't
| know everything we should be discussing.
|
| This is obviously a low hanging fruit and first PoC
| implementation. The fact that secure boot can "mitigate" some of
| this attack right now is mostly due to the attacker being lazy or
| deploying an unfinished product. The researchers describe this as
| "unless they install the attackers certificate", which is a nice
| way of saying that the attacker has not spent much time fishing
| through DKMS and abusing the keys used for this purpose.
|
| There are a lot of systems that are affected by this type of
| attack because for various purposes they have to sign their own
| modules. The most common example of this (until extremely
| recently, sort of) is Nvidia.
| 0xDEAFBEAD wrote:
| >The fact that secure boot can "mitigate" some of this attack
| right now is mostly due to the attacker being lazy or deploying
| an unfinished product. The researchers describe this as "unless
| they install the attackers certificate", which is a nice way of
| saying that the attacker has not spent much time fishing
| through DKMS and abusing the keys used for this purpose.
|
| Can you explain, or link to a source explaining this?
| 1oooqooq wrote:
| if you can add keys and sign things on the fly secure boot
| doesn't matter. it only protects you from downward payloads.
| if the one above the one that cares about secureboot is
| compromised its useless. you're confused because it's sold
| differently from this.
| 0xDEAFBEAD wrote:
| That all makes sense, but is it really that easy for an
| attacker to add keys? If so, the entire thing seems a
| little silly.
| josephcsible wrote:
| Attackers don't need to add their own keys. They can
| piggyback off of the key that you added legitimately to
| get DKMS working.
| grahamj wrote:
| I think they put the Y in the wrong place; should have called it
| bootykit!
| fecal_henge wrote:
| Not everyone is into pirates you know?
___________________________________________________________________
(page generated 2024-11-28 23:00 UTC)