.webp)
Today, Binarly’s security research lab announced the discovery and coordinated disclosure of 16 high-severity vulnerabilities in various implementations of UEFI firmware affecting multiple enterprise products from HP, including laptops, desktops, point-of-sale systems, and edge computing nodes.
One month ago we announced the discovery of 23 high-impact vulnerabilities in one of the major Independent BIOS Developers (IBV) software. These vulnerabilities impacted not only a single vendor, but all the vendors who adopted the same code into their firmware software. Binarly confirmed that all these vulnerabilities were found in several major enterprise vendor ecosystems and CERT/CC (VU#796611) helped notify the impacted parties.
Some of the vulnerabilities from the previous disclosure, affecting Siemens devices, had a CVSS score of 9.8 Critical. The critical high severity score applied to five vulnerabilities discovered by the Binarly team and affected the majority of the Siemens SIMATIC industrial controllers. The Siemens security advisory (SSA-306654) was released three weeks after the initial disclosure date. The critical severity of those vulnerabilities was elevated due to the connection to the impacted storage components implemented into the firmware: AhciBusDxe (BRLY-2021-016/CVE-2021-45969), IdeBusDxe (BRLY-2021-015/CVE-2021-45970), SdHostDriver (BRLY-2021-012/CVE-2021-45971), and FvbServicesRuntimeDxe (BRLY-2021-027/CVE-2021-42554). The attacker can control read/write/erase access to the SPI flash storage by escalating privileges to SMM to execute arbitrary code in the FvbServicesRuntimeDxe. The impact of such a vulnerability is indeed critical because an attacker can achieve one of the highest levels of persistence in SPI flash storage as malicious implants can survive the software firmware update process.
All of those asynchronous parts of the initial disclosure only confirmed our concerns regarding the firmware supply chain problems described in one of our previous blogs, “The Firmware Supply Chain Security is broken Can we fix it”. The U.S. government recently raised awareness of major weaknesses in the firmware supply chain in the “Assessment of the Critical Supply Chains Supporting the U.S. ICT Industry” report.
In many cases firmware is a single point of failure between all the layers of the supply chain and the endpoint customer device.
On March 23rd, Alex Matrosov, the CEO of Binarly, will discuss the firmware supply chain security gaps and their impact at “The Maritime and Control Systems Cybersecurity Con – Hack the Port” conference.
Binarly, HP PSIRT, and CERT/CC teams worked closely to reduce the timeline of the coordinated disclosure process to get the industry fixed faster. The first part of the disclosure (VU#917518), which included five vulnerabilities, became public on the same day as our OffensiveCon presentation "UEFI Firmware Vulnerabilities: Past, Present and Future" where we demonstrated the exploitation of some of the aforementioned issues.
The second part of the HP coordinated disclosure (VU#683814) becomes public today with another 11 high-impact vulnerabilities. Over the last few months, Binarly worked closely with CERT/CC and HP PSIRT teams to confirm the vulnerabilities, provide additional technical details, evaluate the associated risks, and work through the responsible disclosure process.
The Binarly team found all those vulnerabilities by leveraging the Binarly Platform Anomaly Checker in the field. In order to understand the nature of these anomalies, we dug deep into the disassembly code and found out that the majority of these identified issues were exploitable vulnerabilities.
Binarly team believes that the lack of a knowledge base of common firmware exploitation techniques and primitives related to the UEFI firmware makes these failures repeatable for the entire industry. We are working hard to fill this gap by providing comprehensive technical details in our advisories. This knowledge base is crucial for developing effective mitigations and defense technologies for device security.
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.
The HP disclosure information is available at:
PSR-2021-0112: https://support.hp.com/us-en/document/ish_5661066-5661090-16
PSR-2021-0174: https://support.hp.com/us-en/document/ish_5817864-5817896-16
Unfortunately, most of the issues in our reported vulnerabilities are repeatable failures, some of which are due to the complexity of the codebase or legacy components that get less security attention, but are still widely used in the field.
In many cases, the same vulnerability can be fixed over multiple iterations, and still, the complexity of the attack surface can leave room for an attacker to succeed. The majority of the enterprise tools available for source code analysis are not suitable for finding firmware-specific bugs. There are multiple reasons, one of the most obvious being the differences in implementations of the memory management functions compared to the non-firmware-specific software. This leads to a false sense of security when no vulnerabilities are detected at source code level.
Probably one of the best examples of such a problem is the American Megatrends (AMI) UsbRt component (not related to the HP disclosure), which, as we highlighted in our OffensiveCon presentation, has a history of almost 6 years of successful attacks. The Binarly Platform continues to detect vulnerable versions of AMI UsbRt at scale in enterprise infrastructure, and the number of impacted devices is pretty scary.
But some of the vendors continue to provide false claims to their customers, which only escalate such problems and increase the timeline of fixing these vulnerabilities for the entire industry. Such vendor behavior and tactics work to hide the problems in the short term but unfortunately create unnecessary security risks for the industry. A completely opposite example was the collaboration on the disclosure between Insyde and Binarly when such level of transparency created a positive impact on reducing security risks at scale and increasing customer awareness in general.
Getting back to the current disclosure, using Binarly’s in-house code similarity technology on the whole firmware corpus, a detection triggered on a piece of firmware belonging to a Dell device (vulnerability originally was found on HP devices), which led us to conclude that the vulnerability (BRLY-2021-004) exists in some piece of reference code. Additional investigation connects this code to AMD's firmware driver (AgesaSmmSaveMemoryConfig), which is widely spread across the entire device ecosystem.
The BRLY-2021-004 is a good example of a misuse of EFI_BOOT_SERVICES and EFI_RUNTIME_SERVICES because it is unsafe to run such code inside System Management Mode (SMM). An attacker capable of executing code in the unprivileged DXE runtime phase can exploit this vulnerability to escalate privileges to SMM.
The decompiled vulnerable SMI handler code from the HP device is shown below:
The decompiled vulnerable SMI handler code from the Dell device is shown below:
HP's renaming of the EFI variable caused some delay in detecting the same problem in different devices. Binarly is heavily investing in developing cutting-edge technology for deep code inspection. This vulnerability research was triggered by an anomaly detection in one of our customer environments, allowing us to report the issue to CERT/CC to deliver the fix industry-wide.
Binarly has already publicly disclosed 41 high impact vulnerabilities since the beginning of the year. The majority of them target enterprise devices, such as servers, industrial systems and network appliances.
Binarly’s number one priority is to build effective security solutions to protect our customer devices. However, innovative technology cannot be achieved without in-depth research. Offensive research is the key to developing cutting-edge defense technologies.
In our previous blog, we’ve already discussed post-exploitation impact from firmware vulnerabilities which can lead to long-time persistence on the device. A firmware implant is the final goal for an attacker to obtain persistence. The attacker can install the malicious implant on different levels of the firmware, either as a modified legitimate module or a standalone driver. The impact of targeting unprivileged non-SMM DXE runtime drivers or applications by a threat actor is often underestimated. This kind of malicious DXE driver can bypass Secure Boot and influence further boot stages.
| Name of Implant | Name of Implant | Year of Discovery || ------ | ---------- | ----------- | ---------- || MoonBounce | DXE Runtime Application | 2022 | | ESPecter | EFI Bootloader (bootmgfw.efi) | 2021 | | FinSpy | EFI Bootloader (bootmgfw.efi) | 2021 | | MosaicRegressor | DXE Runtime Application | 2020 || Lojax | DXE Runtime Application | 2018 || HackingTeam Rkloader | DXE Runtime Application | 2015 |
Binarly developed the following scheme to demonstrate the logical connection between different types of vulnerabilities (Issue), exploitation techniques (Exploitation), and successful results (Result), which lead to the security risk (Impact).
By using this scheme, you can navigate the various types of vulnerabilities and understand their impact, which is vital for calculating security risks and building threat models.
An understanding of the impact is crucial to incident response and infrastructure security teams. The right understanding of impact allows enterprises to make the right decisions from the start, to respond in a timely manner, and reduce additional risks.
We want to raise awareness regarding repeated failures we are finding with the GetVariable() service misuse. These vulnerabilities can be found by simple heuristics we implemented almost two years ago for our Black Hat Europe 2020 research paper "efiXplorer: Hunting for UEFI Firmware Vulnerabilities at Scale with Automated Static Analysis". Binarly Platform detects a large number of those problems at scale.
In the case of BRLY-2021-003/CVE-2021-39297 vulnerability, we highlighted a pretty common type of misuse of GetVariable() service using our efiXplorer tool:
The same type of misuse of GetVariable() service was previously discussed in detail in our blog post entitled “Firmware Supply Chain is Hardcoded”. Usually, such vulnerabilities are easily exploitable, and in most cases, they lead to stack overflows.
Proof of Concept (PoC) code was developed by our research team to demonstrate the simplicity of exploitation of such problems and increase industry awareness. The PoC code is available in this advisory report. The following figure shows the exploitation PoC of the vulnerable DXE application responsible for HP Hardware Diagnostic Tool, which is widely available on HP server devices:
Next, here is another example of a similar problem caused by the misuse of the GetVariable() service leading to a classical stack buffer overflow. This vulnerability (BRLY-2021-021/CVE-2021-42059) was disclosed a few weeks ago in our previous vulnerability disclosure.
The PoC code is available in this advisory report. The following figure shows the exploitation PoC of the vulnerable DXE driver, which is widely available on BullSequana Edge server devices:
The GetVariable() service misuse is widely spread and very reliable in terms of exploitation. This class of vulnerabilities exists because the original EDKII implementation of GetVariable() service was not implemented in a secure manner. The common static analysis tools will not help in detecting such problems.
A summary of the mitigations and ways of exploiting such vulnerabilities has been discussed in the blog post entitled “Zen and the Art of SMM Bug Hunting | Finding, Mitigating and Detecting UEFI Vulnerabilities” by Assaf Carlsbad. We highly recommend the use of the Binarly efiXplorer IDA plugin, which includes the vulnerability checker functionality that detects the GetVariable() misuse at both DXE and PEI boot phases to reduce the attack surface of such vulnerabilities.
One of the goals for Binarly vulnerability disclosures is to increase awareness and help vendors identify all vulnerable devices at scale. For such reasons, we developed the FwHunt technology. After the results of the coordinated disclosure become public and the affected vendors release the patches, we are also releasing the appropriate FwHunt rules. 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 HP vulnerabilities are publicly available in the Binarly’s GitHub repository, and interested parties can leverage them to scope the vulnerable devices in their enterprise infrastructure. Additionally, these rules are being pushed to the Linux Vendor Firmware Service (LVFS) to enhance supply chain security and awareness in enterprise environments worldwide.
The FwHunt detection for all the issues related to the firmware on HP devices is shown below:
Are you interested in learning more about Binarly FwHunt or Binarly SaaS Platform? Don't hesitate to contact us at [email protected].
The recent report “Assessment of the Critical Supply Chains Supporting the U.S. ICT Industry” increases awareness of firmware issues, but the industry needs the right tools to detect and respond to such problems at scale.
Firmware can also be a lucrative target with a relatively low cost of attack. Over the past few years, hackers have increasingly targeted firmware to launch devastating attacks.
The Binarly team is constantly working to protect the firmware supply chain and reduce the attack surfaces of our customers industry-wide by delivering innovative technologies to the market.
.svg)
