.webp)
In our previous blog “The Firmware Supply Chain Security is broken Can we fix it”, we delved deep into the challenges of the firmware ecosystem by introducing the supply chain "race condition" paradigm.
Today, we are announcing the discovery of 23 high-impact vulnerabilities in one of the major Independent BIOS Developers (IBV) software. These vulnerabilities impact not only a single vendor, but all the vendors who adopted the IBV code into their UEFI firmware software. Binarly confirmed that all these vulnerabilities are found in several of the major enterprise vendor ecosystems. The verified list of impacted vendors consists of: Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel and Bull Atos.
While working on a pilot for a midsize enterprise company, The Binarly team uncovered several repeatable anomalies on twenty different enterprise machines using the Binarly Platform Anomaly Checker. All these alerts were caused by similar hardware configurations from Fujitsu related to their LIFEBOOK laptop series. In order to understand the nature of these anomalies, we dug deep into the disassembly code and found out that the majority of these anomalies were exploitable vulnerabilities in the System Management Mode (SMM).
In the case of BRLY-2021-021/CVE-2021-42059, we highlighted one misuse of GetVariable() service using our efiXplorer tool:
The misuse of GetVariable() service was previously discussed in our blog post “Firmware Supply Chain is Hardcoded”. Usually, such vulnerabilities are easily exploitable and in most cases they lead to stack overflows.
We contacted the Fujitsu PSIRT to begin the disclosure process. We also decided to further investigate if these issues are present in products from other vendors. We were surprised to discover that all these vulnerabilities affected not only Fujitsu products, but also other vendors, such as HP and Lenovo.
The root cause of the problem was found in the reference code associated with InsydeH2O firmware framework code. All of the aforementioned vendors were using Insyde-based firmware SDK to develop their pieces of firmware. We had a short discussion with Fujitsu PSIRT and came to the conclusion that we should report all those issues to CERT/CC to lead an industry-wide disclosure. This is how the VU#796611 was created and how Binarly collaboration with CERT/CC began in September 2021.
Fujitsu PSIRT deserves a lot of kudos for its lightspeed responses that initially saved a lot of time during the disclosure process. The same should be said about Insyde PSIRT, which immediately jumped on the discovered issues and helped to scope them correctly. All of those points put the disclosure process on the right track and saved a lot of precious time.
The CERT/CC team was very responsive from the start and helped notify and coordinate the disclosure with all the 25+ impacted vendors (including multiple ICS vendors coordinated by DHS CISA). It's always the most challenging to coordinate with all parties when there is an industry-wide disclosure. Binarly acknowledges that using the VINCE platform for communicating with multiple parties was a much easier and smoother disclosure process.
The VINCE platform (developed by CERT/CC team) for vulnerability disclosure has been tested in a real environment to significantly reduce the time from the initial disclosure to the security fix with a 5 month timeline (the usual single vendor disclosure process takes 6+ months).
Coordinating with the vendors is one aspect of the disclosure process, but delivering fixes to the endpoint devices is another. One of the initial challenges of the process was to identify all the impacted parties and get them prepared to receive the fixes. Binarly has already partnered with the LVFS project to help protect the supply chain for enterprise devices against known vulnerabilities. CERT/CC invited Richard Hughes, the creator and maintainer of the LVFS project, to help scope the impacted parties by applying Binarly FwHunt rules to detect vulnerable device vendors.
Disclosing the vulnerabilities and informing the customers of a piece of firmware or device is the most important part for not leaving devices unpatched for years.
Understanding the impact and scope of the affected parties at scale is the most challenging part of each vulnerability disclosure.
The majority of the vulnerabilities disclosed (CVSS score: 7.5 - 8.2 high-severity rating) lead to code execution with SMM privileges. As part of the exploit chain, these vulnerabilities can be used as the second stage to bypass security features or gain long-term persistence (like recently discovered MoonBounce). By exploiting these vulnerabilities, attackers can successfully install malware that survives operating system re-installations and allows the bypass of endpoint security solutions (EDR/AV), Secure Boot and Virtualization-Based Security isolation.
The active exploitation of all the discovered vulnerabilities can’t be detected by firmware integrity monitoring systems due to limitations of the Trusted Platform Module (TPM) measurement. The remote device health attestation solutions will not detect the affected systems due to the design limitations in visibility of the firmware runtime.
Post-exploitation vulnerabilities are usually used as the second stage to deliver malicious payloads. These are the main kinds of vulnerabilities that attackers take advantage of to install both persistent and non-persistent implants after they’ve successfully exploited previous stages of an attack. A firmware implant is the final stage of a persistent implant installation. The attacker can install the implant on a variety of levels of the firmware, either as a modified legitimate module or a standalone driver. This picture shows a high-level classification of post-exploitation impact:
A persistent implant is an implant that can survive full reboot and shutdown cycles. In some cases, it can modify firmware update images before being installed, in order to survive the post-update process.
A non-persistent implant is an implant that doesn’t survive full reboot and shutdown cycles. These implants might provide privilege escalation and code execution inside the operating system with protected hardware virtualization (such as Intel VT-x) and layers of trusted execution (such as Microsoft VBS). They can also be used as covert channels to deliver malicious payloads to the kernel-mode of the operating system.
The disclosed vulnerabilities may result in a critical impact if successfully exploited in the enterprise infrastructure. By exploiting SMM privilege escalation or code execution vulnerabilities, an attacker may be able to break confidential computing in cloud environments. Furthermore, the recently discovered MounBounce firmware implant demonstrated in-memory payload delivery and execution in an operating system environment by placing shellcode into the physical memory and then executing it directly from there. Such a technique can be used for fileless in memory code execution which would be orchestrated directly from the firmware. During an incident response, this technique will cause complications from a forensic perspective.
Binarly developed the FwHunt rule format to detect vulnerable code patterns with semantic annotation flavor. We’ve previously discussed in our blog the reasoning for developing the FwHunt rule format and the advantages of such approach over a YARA-based approach (Detecting Firmware vulnerabilities at scale: Intel BSSA DFT case study).
The Binarly Firmware Hunt (FwHunt) rule format was designed to scan for known vulnerabilities and verify that an affected OEM or vendor has patched the issue in its latest update.
FwHunt rules are based on an open specification and stored in the Binarly GitHub repository. Binarly disclosures help vendors identify all vulnerable devices using the FwHunt technology. After the advisory becomes public and the vendor releases the patch we will publish the appropriate FwHunt rules to the public. The customers of Binarly SaaS platform can be notified about the impact and vulnerable devices earlier to get prepared, in advance, for upcoming fixes.
All the FwHunt rules for Insyde vulnerabilities are publicly available in our GitHub repository and interested parties can leverage them to scope the vulnerable devices in their enterprise infrastructure. Additionally, these rules are being pushed into LVFS to enhance supply chain security in enterprise environments worldwide.
The FwHunt detection for all the issues related to the firmware on Fujitsu devices is shown below:
The FwHunt detection for all the issues related to the firmware on Bull Atos devices is shown below:
Are you interested in learning more about Binarly FwHunt or Binarly Platform? Don't hesitate to contact us at [email protected].
The Binarly team is constantly working to protect the firmware supply chain and reduce the attack surfaces related to 1/N-day vulnerabilities by delivering our innovative technologies to the market.
At the OffensiveCon Berlin security conference on February 4th, the Binarly team will present the research "UEFI Firmware Vulnerabilities: Past, Present and Future" where additional technical details regarding the vulnerability discoveries will be disclosed.
.svg)
