Vulnerability due to default key makes Secure Boot unsafe on hundreds of PC types

[P4-630]

Hundreds of laptop models from different brands use an unsafe Secure Boot key.
As a result, it is possible to install UEFI malware such as bootkits or to disable Secure Boot completely on at least 900 devices from well-known brands such as Acer and Dell.

Researchers from Binarly draw this conclusion in a study they call PKfail.

Systems affected:

SupplyChainAttacks/PKfail/ImpactedDevices.md at main · binarly-io/SupplyChainAttacks

Contribute to binarly-io/SupplyChainAttacks development by creating an account on GitHub.

github.com

The researchers looked at an internal dataset with UEFI firmware images and scanned them for the use of the Platform Key in question.
According to them, there are more than 900 laptops and systems from Acer, Dell, Gigabyte, HP and Lenovo that are vulnerable to PKfail.
This makes it possible to completely bypass Secure Boot and install code on a system, such as a UEFI rootkit.

The researchers say that the affected devices use a Platform Key that is no longer secure. Such a Platform Key is a kind of master key for Secure Boot devices.
The researchers found a git repository online that contained that master key. That repo was updated in December 2022, but has since been taken offline.
It’s not known when that happened or who had access to it in the meantime, but the researchers say all devices using that master key are vulnerable.
The git repo itself was encrypted, but the password was only four characters long, making it relatively easy to crack.

In practice, this is quite a lot of work; an attacker still has to manipulate the Key Exchange Key, Signature and Forbidden Signature databases on a system.
The researchers have also released a proof-of-concept. This shows how the bug can be exploited on both a Windows and Ubuntu PC.

Kwetsbaarheid door standaardkey maakt Secure Boot op honderden pc-typen onveilig

Honderden laptopmodellen van verschillende merken gebruiken een onveilige Secure Boot-key. Daardoor is het op minstens 900 modellen van bekende merken zoals Acer en Dell mogelijk om uefimalware zoals bootkits te plaatsen of Secure Boot volledig uit te schakelen.

tweakers.net

 

[eidairaman1]

David Plummer's thoughts on it

Windows Secure Boot Compromised! What You Need to Know by a Retired Microsoft Engineer

 

[unwind-protect]

The security industry at work.

 

[chrcoluk]

David Plummer's thoughts on it

Windows Secure Boot Compromised! What You Need to Know by a Retired Microsoft Engineer

Ouch, shame most of the video is explaining how secure boot works, its why I usually prefer walls of text.

In short a testing key that was only ever intended for internal use was shipped publically.

 

[unwind-protect]

In short a testing key that was only ever intended for internal use was shipped publically.

There are two issues they found:

1) a key was left enabled where the private part was accidentally posted on github. This affects about 200 models and is a super screwup

2) as you say, a testing key was shipped

 

[A Computer Guy]

David Plummer's thoughts on it

Windows Secure Boot Compromised! What You Need to Know by a Retired Microsoft Engineer

This Plummer guy has been popping up a lot recently.

 

[Launcestonian]

Insecure secure boot!

 

[eidairaman1]

Ouch, shame most of the video is explaining how secure boot works, its why I usually prefer walls of text.

In short a testing key that was only ever intended for internal use was shipped publically.

He is a Retired MS Developer from the beginning

 

[phanbuey]

In practice, this is quite a lot of work; an attacker still has to manipulate the Key Exchange Key, Signature and Forbidden Signature databases on a system.
The researchers have also released a proof-of-concept. This shows how the bug can be exploited on both a Windows and Ubuntu PC.

This reminds me a bit of the spectre/meltdown where the code had to be locally executed and running unnoticed on the machine, and then would access certain speculative execution registers on the processor (in tiny fragments) and then could send the data back to the attacker to have him piece it together and POTENTIALLY find a password or something in there...

Here you go, bro... good luck.

I feel like this is the least of your problems if an attacker is already on the machine with a su console or an admin powershell

 

[Frick]

Powershell command to test on your own system:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI PK).bytes) -match "DO NOT TRUST|DO NOT SHIP"

 

[chrcoluk]

This reminds me a bit of the spectre/meltdown where the code had to be locally executed and running unnoticed on the machine, and then would access certain speculative execution registers on the processor (in tiny fragments) and then could send the data back to the attacker to have him piece it together and POTENTIALLY find a password or something in there...

View attachment 356525

Here you go, bro... good luck.

I feel like this is the least of your problems if an attacker is already on the machine with a su console or an admin powershell

I agree for the most part, if the machine is already owned, then further exploitation via spectre etc. is moot.

Although a bios based rootkit is different in that even reinstalling the OS wouldnt clean out the system. Presumably one would have to wipe the keys in the bios (in case a new one was added via the malware author), and then if the bios has such a feature wipe all of the writable EFI area.

Thinking about this a little more though, affected systems are compromised at this point regardless of any bios cleaning, as someone decided it was a good idea to not let people view/delete the existing keys, so you then just at the mercy of the manufacturer to provide a bios update, and given the replies from Lenova and co, I dont think one is forthcoming. I do think the practical use case for an actual ongoing bios compromise is limited though, this problem means the bootloader could be replaced for the existing operating system, and from there it can progress, but a full clean reinstall would then reset that bootloader, and the original compromise that allowed them to replace the bootloader in the first place.

But I agree with your basic point, once you are owned, you are owned, regardless of secondary infections.

 

[phanbuey]

I agree for the most part, if the machine is already owned, then further exploitation via spectre etc. is moot.

Although a bios based rootkit is different in that even reinstalling the OS wouldnt clean out the system. Presumably one would have to wipe the keys in the bios (in case a new one was added via the malware author), and then if the bios has such a feature wipe all of the writable EFI area.

Thinking about this a little more though, affected systems are compromised at this point regardless of any bios cleaning, as someone decided it was a good idea to not let people view/delete the existing keys, so you then just at the mercy of the manufacturer to provide a bios update, and given the replies from Lenova and co, I dont think one is forthcoming. I do think the practical use case for an actual ongoing bios compromise is limited though, this problem means the bootloader could be replaced for the existing operating system, and from there it can progress, but a full clean reinstall would then reset that bootloader, and the original compromise that allowed them to replace the bootloader in the first place.

But I agree with your basic point, once you are owned, you are owned, regardless of secondary infections.

I just think that these researchers run the "boy who cried wolf" risk by overplaying some of these more obscure vulnerabilities. It would help if they gave a "real world risk rating" or some other practical guage of the probability of that this exploit will be used. Maybe a risk by consumer type gauge.

 

[unwind-protect]

Although a bios based rootkit is different in that even reinstalling the OS wouldnt clean out the system. Presumably one would have to wipe the keys in the bios (in case a new one was added via the malware author), and then if the bios has such a feature wipe all of the writable EFI area.

Thinking about this a little more though, affected systems are compromised at this point regardless of any bios cleaning, as someone decided it was a good idea to not let people view/delete the existing keys, so you then just at the mercy of the manufacturer to provide a bios update, and given the replies from Lenova and co, I dont think one is forthcoming. I do think the practical use case for an actual ongoing bios compromise is limited though, this problem means the bootloader could be replaced for the existing operating system, and from there it can progress, but a full clean reinstall would then reset that bootloader, and the original compromise that allowed them to replace the bootloader in the first place.

This was the topic of a Qubes OS talk at a recent chaos communication congress. Can't find the link right now.

Basically a computer must not be allowed to have any writeable memory that cannot be removed and mounted in very raw mode on a different computer. The BIOS is the obvious example, but it also applies to all kinds of extension cars, especially wifi. Only that will give you the transparency you need.

It goes without saying that security features like secure boot in the hands of vendors that behave like amateurs is unacceptable, too. The whole shebang needs to be open source.

 

[Caring1]

It's basically a non issue as the "hacker" must have direct access to the device.
Then you have bigger issues.

 

[Waldorf]

@phanbuey
@Caring1
until its someone working at the location (gov/mil etc; no suspicion about being around), going rogue.

not everything is about a real world use on a single end user pc, and for certain things even a "less than 1%/not likely.." isnt good enough (to not worry about it)..

 

[Ruru]

It's basically a non issue as the "hacker" must have direct access to the device.
Then you have bigger issues.

Agree. I'm pretty sure that us normal home users are fine.

 

[pavle]

Insecure secure boot!

Or rather - insecure boot, translated from doublespeak.

 

[P4-630]

insecure boot

A new UEFI feature..

 

[phanbuey]

@phanbuey
@Caring1
until its someone working at the location (gov/mil etc; no suspicion about being around), going rogue.

not everything is about a real world use on a single end user pc, and for certain things even a "less than 1%/not likely.." isnt good enough (to not worry about it)..

That's why I think a risk rating by consumer group would be useful.

Even on mil/gov machines - why try to use this exploit when you already have root?

 

[Ruru]

That's why I think a risk rating by consumer group would be useful.

Even on mil/gov machines - why try to use this exploit when you already have root?

What OSes militaries use today? When I served in 2010, they had Toughbooks with Win7.

 

[eidairaman1]

What OSes militaries use today? When I served in 2010, they had Toughbooks with Win7.

XP, Vista, When I got out in 2012 they were using 7, they probably are using 10

 

[Waldorf]

@phanbuey
because not everyone with physical access, has a (root) login.
while its a bit ago, when i worked for gov stores, never seen any access to the server/room being restricted past it being located in the back area of an office (IT),
and half the time not occupied by a person.

and its not always about the OS. i had a secure boot board before i was using 10..

 

[phanbuey]

@phanbuey
because not everyone with physical access, has a (root) login.
while its a bit ago, when i worked for gov stores, never seen any access to the server/room being restricted past it being located in the back area of an office (IT),
and half the time not occupied by a person.

and its not always about the OS. i had a secure boot board before i was using 10..

yeah but in order to modify the boot manager you have to have ROOT access, in order for this exploit to work.

 

[Ruru]

yeah but in order to modify the boot manager you have to have ROOT access, in order for this exploit to work.

So practically a typical home user is safe?

 

[R-T-B]

meltdown

Meltdown was a lot worse than Spectre. It could basically enable any process to become admin/root, no sorting or sifting needed.

I just think that these researchers run the "boy who cried wolf" risk by overplaying some of these more obscure vulnerabilities. It would help if they gave a "real world risk rating" or some other practical guage of the probability of that this exploit will be used. Maybe a risk by consumer type gauge.

Most of these postings have an officially assigned severity rating. Blame media outlets for not posting it. It's not the researchers fault ya'll like sensationalism and continually feed the media beast.