Secure boot broken (PKFail) on XPS 8960 and other models

Not just Dell.  Somebody accidentally published the "platform keys" on line in an encrypted file with only a 4-digit password that was easily cracked.

In other cases, "test keys" were used on certain PCs when they were only supposed to be used for manufacturing/testing of systems and not on those released for sale.  

~300 PC models from various OEMs are affected by one or the other fault.

Dell will have to create firmware updates for each of their affected models.  You can either let  SupportAssist to check for new BIOS updates, or manually check the Drivers/Download page for your specific model regularly...

The research team that discovered this vulnerability (Binarly) has added the pertinent information to a GitHub page listed under the heading of:

[BRLY-2024-005]

The link to it is as follows:

https://github.com/binarly-io/Vulnerability-REsearch/blob/main/PKfail/BRLY-2024-005.md

This vulnerability is being referred to as PKFail. PK is an acronym used to describe a Platform Key. Platform Keys are an integral part of Secure Boot.

This page lists all the preliminary details on what systems were affected and a script that can be ran on Linux or Windows to check if a machine is relying on compromised keys... 

NOTE: I have 3 Dell computers and my Inspiron 3252 was not listed in the list of affected machines although running the script in powershell returns TRUE (Keys compromised).

       Also, Please be cautious applying any "fixes" from non-official sources as i'm sure this, just like any other major vulnerability, is a breeding ground for fake "quick fixes" and further malware. 

      Not sure how Dell will handle this or what needs to be done for a fix but I would like to add that in a separate article the Binarly Research Team commended Dell on their assistance in working this issue thus far. 

    In the meantime, I have pulled my Inspiron from the network, awaiting instructions. 

Yes I see the True using

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

on

Alienware M15 R3

Alienware M15 R4

Alienware X15 R1

Alienware X15 R2

all with the latest BIOS 
we'll have to wait for Dell to release an update ..

@WhatCouldPossiblyGoWrong​ 

XPS8940 is "False":

==============

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

===============

BIOS Version/Date, Dell Inc. 2.20.0, 6/5/2024

XPS 8930 with BIOS 1.31.0 here is also false...but false doesn't necessarily mean the system is in the clear. 

Authentic keys were likely stolen from that online database which had only a 4-digit password (DUH!). 

So we'll have to wait/see what happens next. Presumably Dell will release BIOS updates with new keys for all affected models.

@RoHe​ 

Hard to tell for sure maybe?

The link to GitHub only lists as far as the XPS line is concerned the 8960 and 8950. This web page, https://www.binarly.io/blog/pkfail-untrusted-platform-keys-undermine-secure-boot-on-uefi-ecosystem is interesting as it mentions the XPS8960.

Also on this web page, https://www.securityweek.com/pkfail-vulnerability-allows-secure-boot-bypass-on-hundreds-of-computer-models/  is this:

==============

Supermicro said in an advisory that it has fixed the vulnerability. Dell, which has directly worked with Binarly on this issue, has also addressed PKfail in its products.

==============

The on-line tool to check this is here, https://pk.fail/ and I assume one uploads to the page the BIOS binary (not sure what 'file' exactly, might be the payload vs. the EXE file?).

Not sure if the FAIL reported 2 posts above yours was on an 8960 or not it was only on the 4 Alienware's listed?

Now what the FIX was to ensure a stolen one can't do 'damage', that is another question, or would new BIOS instead have a new safe Key?

For systems with stolen keys, they likely just need a BIOS update with a new key, just like the ones which have "test" keys will need an update. 

The keys were stolen around 2022, and who knows which models used those keys, when the theft was discovered or what steps may have already been taken to fix the problem. 

My XPS 8930 has had 9 BIOS updates since beginning of 2022, and any one of them might have replaced the key. We may never know, unless older models suddenly get a new BIOS update, but even that isn't conclusive evidence.

@ispalten I uploaded the latest BIOS to the pk.fail [it was the .exe] and it said it was all good and passed, however , when I install that the command still shows as being compromised.
when I ran the BIOS update it updated the BIOS , ME firmware , firmware and other stuff, so I still think they need to push something new out.

@WhatCouldPossiblyGoWrong​ 

@ispalten I uploaded the latest BIOS to the pk.fail [it was the .exe] and it said it was all good and passed, however , when I install that the command still shows as being compromised.
when I ran the BIOS update it updated the BIOS , ME firmware , firmware and other stuff, so I still think they need to push something new out.

Yeah, it sort of makes me think that this isn't something easy, nor a guarantee on any answer?

@RoHe posted "The keys were stolen around 2022" so depending on 'when' exactly, one would think NEW models would not be effected unless the stolen keys were used? My XPS8940 was purchased in early 2022, but it appears to be OK?

Now this link, https://www.binarly.io/blog/pkfail-untrusted-platform-keys-undermine-secure-boot-on-uefi-ecosystem, sort of implies that the problem started with the XPS8960:

====================

Dell PSIRT collaboration on PKfail disclosure

We had great synergy during the disclosure process with our customer, Dell. They use the Binarly Transparency Platform to protect multiple product lines. Initially, we found the default non-production Platform Key (PK) from AMI inside the Dell XPS 8960 Desktop firmware image, making this and other product lines exposed to the PKfail vulnerability. These products initialize Secure Boot variables with non-production values from AMI and are thus vulnerable to PKfail. We have confirmed this finding by checking the NVRAM variables content in live firmware dumps of affected products:

================

So why does Alienware have the problem?

This link, https://medium.com/@nexsecura/millions-of-devices-vulnerable-to-pkfail-secure-boot-bypass-issue-045f94e52d7b, implies the keys were stolen in 2023:

===============

In May 2023, Binarly identified a security incident involving leaked private keys from Intel Boot Guard, affecting multiple vendors. This incident was first reported by BleepingComputer, highlighting that the Money Message extortion gang had leaked MSI source code for firmware used in the company’s motherboards. This leak included image signing private keys for 57 MSI products and Intel Boot Guard private keys for another 116 MSI products.

Earlier in the year, a private key from AMI related to the Secure Boot “master key” was also leaked, affecting various enterprise device manufacturers. Alarmingly, these compromised keys are still in use and have been found in recently released enterprise devices.

==============

The AMI ones are probably used in Dell's BIOS. So I'd assume the 8940's were leaked, Now Dell probably uses the same for all products, but this still doesn't 'equate' to me?

If it were leaked in 2023, surely 8950's and all Dell products (if the same key were used for all products) would known? How every, it seems only the 8950 and 8960's appear in articles to be subject to this?

Same link above has this:

==========

Historical Context

The first firmware vulnerable to PKfail was released in May 2012, with the most recent release in June 2024. This makes PKfail one of the longest-lasting supply-chain issues, spanning over 12 years. The BRLY-2024–005 advisory details almost 900 affected devices, with 22 unique untrusted keys identified through scan results.

===========

As I read that, anything made before 2024 could be vulnerable, but not after, yet more recent Dell's have the vulnerability.

I'm beginning to think some of this data might be indication the AMI vendor part only. Dell BIOS has other non-Dell specific binary's, like the Intel Management Engine included. Maybe the AMI part is used in many/all Dell BIOS version and not 'h/w' specific by nature and hardly ever updated? I suspect this could be the case, but doesn't explain the fails in the Alienware models, not when my 8940 claims to be OK?

Am I missing something or not reading the 'web pages' correctly?

I guess it is possible that only Dell knows the answer here?

This also is important as there have been discussions here in 'force' installing BIOS by MS Update. In this particular instance, 'fixing' the BIOS is a good reason WHY to force install updates.

@ispalten  That PKfail script won't tell you if your PC could have one of the stolen keys. It only looks for "non-production" keys which have "“DO NOT TRUST” or “DO NOT SHIP“ strings embedded in them.  The theft was in ~2022 but only (re)discovered in ~2023. 

According to this, Dell has worked extensively with Binarly to mitigate the problem. It doesn't say which Dell PC models have been updated with new keys, either from stolen or "Do not Trust/Ship" keys.

Best advice is to keep on the lookout for new BIOS updates, regardless of PC model...

Dell Technologies is aware of the Pkfail vulnerability reported by Binarly that may affect a small number of consumer PCs. BIOS updates for potentially impacted devices are in progress.

@DELL-Nat M​ 

A lot more than a small number are affected:

https://github.com/binarly-io/Vulnerability-REsearch/blob/main/PKfail/BRLY-2024-005.md

https://www.dell.com/support/kbdoc/en-us/000227594/dsa-2024-354 some movement