.webp)
At the LABScon 2024 security conference this week, our REsearch team will present significant new findings on the PKfail story. In this blog, we dive deeper into newly discovered data points gathered from our free detection service pk.fail and major vendor acknowledgements and developments since the initial disclosure in July.
Initially, PKfail was only documented via a BRLY-2024-005 advisory, and no CVE was assigned. However, after the industry wake-up call, with initial Binarly disclosure and a public demonstration of the impact, the situation dramatically changed.
As previously disclosed, PKfail is a critical firmware supply-chain vulnerability affecting UEFI Secure Boot. This flaw is related to the "master key" used in the Secure Boot process, known as the Platform Key (PK), which serves as the Root of Trust. The security of this key is crucial, as the entire Secure Boot verification mechanism depends on it.
During the disclosure process, we worked closely with CERT/CC to coordinate with multiple impacted vendors across the entire tech industry. At the end of August 2024, PKfail was assigned CVE-2024-8105 and VU#455367. Multiple vendors acknowledged our findings by publishing, including:
We were also positively surprised to see that other vendors, such as Protectli, were able to quickly identify and promptly mitigate PKfail, even though they weren’t mentioned in our original advisory because their firmware wasn’t part of our dataset.
From the community response, we instead learned that many other vendors using AMI’s UEFI code are affected by PKfail. For example, the following vendors and respective devices are affected by PKfail, as reported on public forums:
Alongside the public disclosure of PKfail, we released a free pk.fail detection service to allow users to upload firmware binaries for scans to detect any non-production Platform Keys (PK). The free utility was broadly adopted and helped enterprise security teams to test device assets for potential PKfail exposure.
Based on our data, we found PKfail and non-production keys on medical devices, desktops, laptops, gaming consoles, enterprise servers, ATMs, POS terminals, and some weird places like voting machines.
Let’s look deeper into the numbers related to our free detection tool pk.fail.
At the time of writing this blogpost, more than 10,095 unique firmware images have been uploaded on our service, 791 of which contained an untrusted Platform Key, and 9,304 were deemed safe. This results in a 8.5% vulnerable rate, which once again aligns with the findings from our initial research report.
The step plot below shows the number of submissions (log scale), grouped by day:
As we can see, a large number of submissions occurred immediately following the disclosure, but we continue to observe an average of 25 submissions per day over the last month. We also opened an API interface for the pk.fail service to facilitate more submissions and scale the detections.
Let’s examine the unique, untrusted Platform Keys (PK) we discovered while preparing this research study.
The previous table summarizes the non-production keys detected by PK.fail, sorted by total occurrences. From this data we can draw several insights. First, these keys closely align with what we reported in our original report. Second, the most frequently used key (i.e. the one with serial beginning with “55:fb:ef”) is the one that was accidentally leaked on GitHub, putting these devices at immediate risk. Third, as shown in the Already Seen column, the analyzed firmware contained four untrusted keys that we have never encountered before: three of them belong to AMI, while one was generated by Supermicro.
But even more importantly, our original research report might have underestimated the impact of PKfail on other IBVs. In particular, 61 firmware images contained an untrusted key that we traced back to Insyde. This Insyde key was generated in 2011, based on the certificate’s “Not Before” field. Although this key is not new to us, as we previously found during the PKfail research, it only appeared in firmware developed for older devices marketed in the early 2010s. However, the firmware collected on pk.fail tells a different story: this key is also being used in devices currently on the market. We are highly confident on this finding for some of the 61 images containing this key because:
The complexity of the supply chain is overgrowing our ability to effectively manage the risks associated with third-party suppliers. PKfail is a great example of a supply chain security failure impacting the entire industry. However, these risks could be mitigated and totally avoidable if we focus more on delivering a secure-by-design philosophy.
This blog post shows the reaction of the device vendors to the public disclosure of PKfail vulnerability and goes far beyond the firmware ecosystem. The newly discovered data exposed the involvement of other IBVs like Phoenix and Insyde. However, the numbers of non-production cryptographic materials in the wild are dramatically lower than those of AMI.
This research study shows that the industry-wide impact of the PKfail is significantly bigger than we initially saw based on our limited telemetry data. That’s the major reason for the active reaction from the device vendors and CERT/CC coordination regarding this incident. Software supply chain failures could be prevented only with more transparency on measurable artifacts from the software providers to help build a resilient ecosystem.
.svg)
