PKfail or leak of private keys Secure Boot

report

. The report is difficult to understand, however, as it is not an isolated case of Secure Boot key leakage, but rather a fundamental oversight by a number of manufacturers, which began back in 2012.

The most recent event in this timeline dates back to 2023: in January, BINARLY discovered a public repository on GitHub that contained a single private key, known in the Secure Boot ecosystem as the Platform Key. The key was published on GitHub in December 2022. It was encrypted, but it used a four-digit password that is easy to crack. This key plays an important role in ensuring the security of the Secure Boot mechanism. A potential attacker can use the Platform Key to generate the so-called Key Exchange Key, and then use it to sign a malicious component that will be executed when the computer boots. As a result, there is a risk of serious compromise of the system, and the malware will be able to survive a complete reinstallation of the OS. To carry out the attack, physical access to the PC or server or administrator rights on the system will be required. The latter is quite achievable, and physical access opens the possibility of implementing a supply chain attack: when an entire batch of computers is “modified” en route from the manufacturer to the customer. But the most important thing is that this is most likely not the only private key that can be considered compromised.

As shown in the screenshot above, the leaked Platform Key has an interesting identifier in the Issuer field: DO NOT TRUST — AMI Test PK. American Megatrends supplies customers with reference code for UEFI firmware that includes the Secure Boot mechanism. This code uses test keys. The reference firmware provider expects the device manufacturer to replace the test keys with their own in the final versions of UEFI. According to Ars Technica, it is recommended to use a unique Platform Key for a specific product line of devices or at least for a specific manufacturer. Instead, several vendors left test keys provided by AMI in the final firmware. That is why the list of affected devices includes motherboards, laptops, desktops, and servers from different manufacturers.

The next step in BINARLY's research was to scan a large database of UEFI firmware for various devices to find test keys with the Issuer field set to “DO NOT TRUST” or “DO NOT SHIP.” There were 22 such keys, and only one of them was accidentally leaked to GitHub (identifiable by its serial number 55:fb:ef:87:81:23:00:84:47:17:0b:b3:cd:87:3a:f4). This does not mean that devices using other Platform Keys are safe. They were distributed over several years among many American Megatrends customers. Since the keys were “test” by nature, they likely did not have any special security measures applied to them. There is a non-zero probability that other keys have been or will be accidentally leaked to the public, and that many people at different companies have access to these private keys.

In addition to the initially affected Acer, Dell, GIGABYTE and Supermicro, firmware scanning revealed the presence of test Platform Keys in devices from AOPEN, Fujitsu, Lenovo and HP. The list of devices in whose firmware test keys were found is posted Here. This list is based on testing a large firmware database, but may not be complete. It contains over 800 devices, of which over 200 contain the one key that is guaranteed to have leaked into the public domain. To check the firmware of other devices, BINARLY has developed a public service to search for unsafe keys, to check there you need to download the firmware from your device. A significant part of the list is GIGABYTE motherboards, from Lenovo devices there is a small number of desktop PCs. Among Dell devices there are both desktop PCs and laptops, including the Alienware gaming series.

Let's go back to the timeline of events. The first public mention of the use of test Platform Keys dates back to 2016: at that time such a key was discovered in the firmware of some Lenovo desktop PCs. The key, which was publicly available on GitHub in late 2022, has been used in devices from different manufacturers since 2018. All 22 test keys have been used since 2012, and the latest firmware of real devices with them is dated June 2024. According to BINARLY, 10% of firmware in their database uses test keys, or 8% if you take only firmware released in the last 4 years – these devices are highly likely to be used today.

A fresh BINARLY study once again reveals a fundamental problem in the implementation of the Secure Boot protection mechanism. Secure Boot was originally created as a solution to prevent unauthorized code from running during computer boot. This is a reasonable protection method in theory, but in practice it has a whole range of problems. Key leakage, the use of test keys in end devices is an organizational problem. There are also technical difficulties: for example, we previously wrote about the previous BINARLY study, which demonstrated an attack method through the substitution of the logo shown to the user when turning on the PC. There are obvious difficulties in controlling the security mechanism, the development of which involves a wide range of organizations. It is unlikely that we should expect mass exploitation of problems in Secure Boot, but the potential for targeted attacks is there, as it was shown last year using the BlackLotus bootkit as an example. The peculiarity of the leak of the test key (the only one so far) adds new colors to the theoretical threat model: potential attackers no longer need to exploit vulnerabilities in Secure Boot. On a limited number of devices, it is enough to throw in a malicious code signed according to all the rules.

What else happened?

Last week, new details were made public about the incident with the CrowdStrike security solution, which we covered in detail in the previous digest. CrowdStrike updated technical description incident. The problematic update sent to clients passed internal testing procedures. However, it contained information that, when processed by a driver running with the highest privileges, caused a failure. Measures to prevent such incidents in the future include both improved testing methods and gradual distribution of updates to clients so that the failure can be identified when it affects a very small portion of client systems. Technical analysis incident Microsoft also published. The monetary estimate of the damage caused by the error in the CrowdStrike Falcon update ranges from one to more than five billion dollars.

Kaspersky Lab shared with my own eyes to protect software updates from failures, which also mentions a phased distribution of updates, starting with testing on the company's internal network, as one of the methods of protecting against errors.

Another publication by Kaspersky Lab experts disassembles a new incident involving the well-known cyber-spyware Mandrake, which was once again able to get into the Google Play store as part of several applications.

Last week, there was also a widely discussed incident at KnowBe4, which they themselves described in detail told on his blog. A “North Korean hacker” was able to successfully get a remote job with them. The anonymous person, using stolen personal data of a US resident, as well as photos (and possibly videos) generated by a neural network, passed all rounds of interviews, and his oddities were discovered only after sending a working laptop: they tried to download malware onto the device.