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.
>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?
It's kinda ridiculous reading the comments in here.
This is a persistence stage exploit mechanism, meaning in order to install it, privilege escalation happened before that and it already got root rights.
The people here that claim "secureboot prevented that". No, it didn't. A simple call to sbctl to sign the rootkit is missing, because, as every Linux device, you will have to have the signature keys available locally. Otherwise you can never update your kernel.
That is the conceptual issue that cannot be fixed, and also not with TPM or whatever obscurity mechanism in between.
Linux needs to be a rootless system, meaning that there needs to be a read only partition that root can never read. That would limit access to this kind of thing to physical access or the kernel ring at the very least. Technically, this was the intent of efivarfs, but look at where vendor firmware bugs got us with this.
> The people here that claim "secureboot prevented that". No, it didn't. A simple call to sbctl to sign the rootkit is missing, because, as every Linux device, you will have to have the signature keys available locally. Otherwise you can never update your kernel.
The majority of Linux machines out there are running vanilla, distribution-signed kernels. For most people, the only reason to build your own kernel (modules) is Nvidia.
> The people here that claim "secureboot prevented that". No, it didn't. A simple call to sbctl to sign the rootkit is missing, because, as every Linux device, you will have to have the signature keys available locally. Otherwise you can never update your kernel.
If, hypothetically, you were using a system without custom keys, e.g. with a third party kernel trusted via the Microsoft / Red Hat shim program, [1] wouldn't you be safe, so long as secure boot was enabled? The bootkit would not be able to sign itself with a trusted key since the private key would never exist on the system to begin with.
Obviously, I'm aware that this approach has other problems and has had vulnerabilities in the past.
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.
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.
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.
I think UEFI has many problems. However, you should not confuse separate (but related) issues from each other. If the initial booting functions can be altered by the operating system, that is a different issue (which perhaps UEFI makes it more severe). An internal hardware switch to disable this function would be helpful, and possibly a software function that the BIOS disables once the system starts (so it can only be altered by the BIOS setting menu, or by a BASIC or Forth in ROM or something like that). Functions being restricted by internal hardware switches would improve security, especially if also the initial booting functions are made less complicated too; if you are paranoid then you could also use glitter or whatever to detect hardware tampering.
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.
Hello everyone, I am the developer of BootKitty. I am studying IT in Korea and I am making bootkit as a private project in BOB, a security program training. If you find it hard to believe that I am a developer, I can prove it. If you have any questions about BootKitty, please ask me :)
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".
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.
>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?
It's kinda ridiculous reading the comments in here.
This is a persistence stage exploit mechanism, meaning in order to install it, privilege escalation happened before that and it already got root rights.
The people here that claim "secureboot prevented that". No, it didn't. A simple call to sbctl to sign the rootkit is missing, because, as every Linux device, you will have to have the signature keys available locally. Otherwise you can never update your kernel.
That is the conceptual issue that cannot be fixed, and also not with TPM or whatever obscurity mechanism in between.
Linux needs to be a rootless system, meaning that there needs to be a read only partition that root can never read. That would limit access to this kind of thing to physical access or the kernel ring at the very least. Technically, this was the intent of efivarfs, but look at where vendor firmware bugs got us with this.
> The people here that claim "secureboot prevented that". No, it didn't. A simple call to sbctl to sign the rootkit is missing, because, as every Linux device, you will have to have the signature keys available locally. Otherwise you can never update your kernel.
The majority of Linux machines out there are running vanilla, distribution-signed kernels. For most people, the only reason to build your own kernel (modules) is Nvidia.
What? The vast majority of Linux systems running in a secure boot world run vendor-signed kernels.
> Technically, this was the intent of efivarfs
As the original author of efivarfs I can absolutely say that this was not the intent
> The people here that claim "secureboot prevented that". No, it didn't. A simple call to sbctl to sign the rootkit is missing, because, as every Linux device, you will have to have the signature keys available locally. Otherwise you can never update your kernel.
If, hypothetically, you were using a system without custom keys, e.g. with a third party kernel trusted via the Microsoft / Red Hat shim program, [1] wouldn't you be safe, so long as secure boot was enabled? The bootkit would not be able to sign itself with a trusted key since the private key would never exist on the system to begin with.
Obviously, I'm aware that this approach has other problems and has had vulnerabilities in the past.
[1] https://wiki.ubuntu.com/UEFI/SecureBoot
> A simple call to sbctl to sign the rootkit is missing, because, as every Linux device, you will have to have the signature keys available locally.
Now that would be something! Unfortunately, I haven't discovered Microsoft's private key on my computer yet.
> obscurity mechanism
I am wondering: could you store the signing keys on a Fido2 device? Or in a crypted file?
I would think this would not be mere obscurity, as this makes sure that just being root does not give you access to the signing keys.
I found this a rather interesting read, nice.
I cannot help but think the move to UEFI and Secure Boot made things less secure :(
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.
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.
The article says that Bootkitty does not work if Secure Boot is enabled. How do you figure Secure Boot made things less secure?
"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.
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.
It's more secure than not having Secure Boot.
I think UEFI has many problems. However, you should not confuse separate (but related) issues from each other. If the initial booting functions can be altered by the operating system, that is a different issue (which perhaps UEFI makes it more severe). An internal hardware switch to disable this function would be helpful, and possibly a software function that the BIOS disables once the system starts (so it can only be altered by the BIOS setting menu, or by a BASIC or Forth in ROM or something like that). Functions being restricted by internal hardware switches would improve security, especially if also the initial booting functions are made less complicated too; if you are paranoid then you could also use glitter or whatever to detect hardware tampering.
And significantly more complicated to setup and maintain in my limited experience :|
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.
Hello everyone, I am the developer of BootKitty. I am studying IT in Korea and I am making bootkit as a private project in BOB, a security program training. If you find it hard to believe that I am a developer, I can prove it. If you have any questions about BootKitty, please ask me :)
I guess we need to go to back to socketed eeprom chips.
Or just in general machines that are wholly controlled by the owner.
A physical jumper or switch to enable/disable writing to the firmware flash could end a lot of these kinds of problems.
Don't be silly, they can't put a subscription on an eeprom ;)
Previously: https://news.ycombinator.com/item?id=42260346
Neat-o wonder where this was discovered and what telemetry is being used to say it isn't used in the wild (guessing commercial anti-v products)
FYI Related articles:
https://news.ycombinator.com/item?id=42262525
https://news.ycombinator.com/item?id=42264655
I think they put the Y in the wrong place; should have called it bootykit!
Not everyone is into pirates you know?
What does the discovery of the Bootkitty UEFI bootkit for Linux systems suggest about the evolving landscape of cybersecurity threats?
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".
It means "just trust us" is not and never was secure.
Trustworthy people don't ask you to trust them.