We have frequently covered the topic of supply chain problems related to reference code when silicon vendors ship vulnerable code to the entire ecosystem. These vulnerabilities typically require a significant amount of time and effort to get fixed since they impact all the vendors that incorporate the vulnerable code into the firmware on their devices.
The Binarly security research team conducts a comprehensive analysis of the recent Intel and MSI source code leaks to model the potential impact.
The Binarly REsearch team disclosed three high-severity vulnerabilities to AMD in December 2022, with confirmed industry-wide downstream impact. It’s normal for vulnerabilities in reference code to live in the supply chain for long periods of time, even after the fixes are released. In these cases, the silicon vendor did not assign the CVEs to the internal discoveries and released silent fixes to some vendors. Binarly’s researchers discovered these CVE-2023-20558/BRLY-2022-044 and CVE-2023-20559/BRLY-2022-042 independently and disclosed them to AMD’s security response team. A fourth vulnerability, BRLY-2022-045 (8.5 High), is still unfixed due to the complexity of the issue and its impact. AMD expects to release a patch later this year.
In my recent blog post on the BlackLotus UEFI bootkit, we discussed how big a problem the firmware supply chain poses to Microsoft Windows bootloaders, showing how the BatonDrop (CVE-2022-21894) vulnerability can bypass both device attestation and secure boot.
My experience with the analysis and detection of rootkits and bootkits goes back more than 20 years. In the early 2000s, the main challenge was dealing with infected machines when rootkits and bootkits modified the operating system kernel to conceal malicious components. It was such a fun time reverse engineering advanced threats in the good old days that I co-wrote "Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats," a book full of the most interesting stories of our time going down the rabbit hole of advanced malware.
In today's disclosure we opened Pandora's box of ARM devices with UEFI firmware vulnerabilities impacting enterprise vendors. As far as we know, this is the first major vulnerability disclosure related to UEFI firmware on ARM. The big part of vulnerabilities disclosed today related to Qualcomm’s reference code for Snapdragon chips. The vulnerabilities in reference code are usually one of the most impactful since they tend to affect the whole ecosystem and not just a single vendor. Due to the complexity of the UEFI firmware supply chain, these vulnerabilities often create additional impact. UEFI's unified specification not only brings consistency to the firmware development process, but also to the attack surface. This consistency creates cross-platform attacks, so many attack vectors from the x86 ecosystem will also be available on ARM, though exploitation specifics will differ.
Binarly released a new version of efiXplorer v5.2 [Xmas Edition] today, with support for the new IDA SDK v8.2 and the addition of multiple code analysis improvements.
Last month, our friends at ESET discovered a few interesting security vulnerabilities in Lenovo devices that allow attackers to bypass Secure Boot and execute malicious code on the device.
The technology industry is in the midst of active discussions about the use of “software bill of materials” (SBOMs) to address supply chain security risks. In order to implement supply chain security practices, there must be better transparency on software dependencies. Previously, any piece of software shipped as black-box without providing any information related to software dependencies and third-party components. Firmware has largely been looked at the same way. In an earlier blog post, Binarly team discussed the multiple levels of complexity in the UEFI firmware ecosystem and supply chain taxonomy (The Firmware Supply-Chain Security Is Broken: Can We Fix It?).
Over the past two years, attacks on multiple targets in the semiconductor industry have consistently led to leaks of firmware source code. A compromised developer device could potentially give an attacker access to the source code repository, adding a major gap in the security of the software supply chain.
Binarly Inc., providers of the industry’s first AI-powered firmware protection platform, today announced the addition of veteran cybersecurity executives from BlackBerry and Dragos, expanding an experienced management team to deliver enterprise firmware security solutions at scale.
In a previous blog covering one of Binarly’s presentations at the Black Hat 2022 conference, we discussed in detail our research on attacks that disable Windows Management Instrumentation (WMI) and blind an entire class of endpoint security solutions. We introduced a template for attacks, dubbed ‘one-bit change attack’, on objects residing inside the WMI service address space. We also demonstrated another way to disable WMI by isolating the WMI service from the rest of the operating system through a sandboxing attack.
Only two months have passed since our Black Hat talk where we spoke about a bunch of discovered vulnerabilities. Our presentation at Black Hat revealed 12 serious vulnerabilities affecting enterprise devices industry-wide. The Binarly security research team continues to find evidence of repeatable failures in the firmware development ecosystem, exposing critical vulnerabilities that impact the entire industry rather than just a single vendor.
We promised to release the new version of efiXplorer with ARM-based firmware support last week at the inaugural LABScon event. This is one of the most important releases since the project began in February of 2020. In the beginning, efiXplorer focused primarily on x86-based firmware analysis, but after seeing the growth of ARM-based servers and laptops, we are now adding support for ARM.
The Binarly security research team continues to find evidence of repeatable failures in the firmware development ecosystem, exposing critical vulnerabilities related to the ecosystem that impact the entire industry rather than just a single vendor.
The Binarly security research team has had a busy year finding, documenting and helping to fix high-impact vulnerabilities affecting multiple enterprise vendors. In this blog, we provide an in-depth look at some of the vulnerabilities we discussed at the Black Hat 2022 conference affecting HP EliteBook devices.
The Binarly team is constantly researching ways to automate our proprietary deep code inspection technology to improve the discovery of different classes of bugs within system firmware. The Binarly efiXplorer team has decades of experience in program analysis and automation, enabling us to develop unique binary analysis techniques and technologies internally.
In our previous blog, we discussed post-exploitation impact from firmware vulnerabilities which can lead to long-time persistence on the device. A firmware implant is the ultimate goal for an attacker to obtain persistence. An 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. All these firmware threats have been discovered only after many years of being deployed in the wild.
The increasingly large number of firmware vulnerabilities gives attackers a lot of options for persistence and the means to bypass traditional endpoint solutions. At least two recently discovered firmware implants -- MoonBounce and CosmicStrand -- have persisted for more than seven years by using basic firmware bootkit techniques. In general, the UEFI system firmware grows in complexity every year and constantly introduces new attack surfaces.
Speculative execution mitigations have been discussed for some time, but most of the focus has been at the operating system level in order to adopt them in software stacks. What is happening at the firmware level? When it comes to applying these mitigations, how does the industry take advantage of them, and who coordinates their adoption specifically into the firmware? These are all good questions, but unfortunately no positive news can be shared.
Every startup, like a story, has its own beginning. Binarly started with a simple idea to gain more visibility into firmware through binary code analysis and change the cybersecurity industry’s approach to managing the firmware threat landscape.
Almost a year ago, while describing our company mission and the limitations of available solutions for detecting firmware threats, we discussed our initial vision around binary code inspection for detecting firmware threats and vulnerabilities (See: Why Firmware Integrity Is Insufficient For Effective Threat Detection And Hunting).
A month ago, Binarly’s security research team managed the coordinated disclosure of 16 high impact vulnerabilities in HP devices and 23 additional security defects impacting major enterprise vendors. In less than a year, Binarly disclosed 42 high severity vulnerabilities haunting the UEFI firmware ecosystem, all serious enough to cause arbitrary code execution in System Management Mode (SMM).
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.
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.
At the beginning of December, Binarly was very active in spreading the word about the problems in the firmware supply chain ecosystem at multiple security conferences. Alex Matrosov, the Binarly CEO, gave a keynote entitled “The Evolution of Threat Actors: Firmware is the Next Frontier” at AVAR conference in which he focused on the evolving threats coming from historically overlooked places below the operating system.
As experts in firmware security, the Binarly team is frequently asked why endpoint solutions can’t detect threats originating below the operating system such as firmware implant payloads. Unfortunately, the problem requires a more complex approach and the modern architecture of Endpoint Detection & Response (EDR) solutions are weak against generic attack patterns.
In our previous two blogs, Firmware Supply Chain is Hard(coded) and Attacking (pre)EFI Ecosystem, we described in detail four high severity vulnerabilities that impacted the UEFI system firmware and put a large number of enterprise devices at high risk.
At Black Hat USA 2021, Binarly CEO Alex Matrosov jointly presented with Nvidia security researchers Alex Tereshkin and Adam 'pi3' Zabrocki their findings in the “Safeguarding UEFI Ecosystem: Firmware Supply Chain is Hard(coded)” talk, highlighting five high severity vulnerabilities that affected the whole UEFI ecosystem.
At Black Hat USA 2021, Binarly CEO Alex Matrosov jointly presented with Nvidia security researchers Alex Tereshkin and Adam 'pi3' Zabrocki their findings in the “Safeguarding UEFI Ecosystem: Firmware Supply Chain is Hard(coded)” talk, highlighting five high severity vulnerabilities that affected the whole UEFI ecosystem.
Today we are pleased to announce that "Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats" book by Alex Matrosov, Eugene Rodionov and Sergey Bratus has been featured in the Highest-Rated Books for Malware Analysts Available on Amazon.
Currently, integrity checking is the standard methodology for firmware security validation and threat detection. This article details the different scenarios where firmware integrity is necessary, but insufficient from the threat analysis and incident response perspective.
This blog post describes my joint research with Alexandre Gazet that culminated with us presenting the “Breaking Through Another Side: Bypassing Firmware Security Boundaries from Embedded Controller” (slides) talk at BlackHat 2019 Conference in Las Vegas. Our REsearch focused on the Embedded Controller security and Intel BIOS Guard technology implementation in Lenovo Thinkpad BIOS and took around 5 month of our spare time.
At the last Black Hat event in Vegas, I presented the first publicly known concept of an attack on a specific implementation of Intel Boot Guard technology - technology that is mostly undocumented. While I was working on this research one thought bothered me: the specification of a technology can be almost perfect, but after all, the implementation part is done by third-parties and it is challenging to maintain proper level security in this case. Intel Boot Guard is an excellent example of a complex technology where there are places where making a small mistake allows an attacker to bypass the security of the entire technology.
