UEFI vulnerabilities classification focused on BIOS implant delivery

Alex Matrosov
Firmware Threat Hunting
4 min readJan 17, 2019

Tons of research has been already presented about problems in UEFI firmware ecosystem and how relatively easy deliver and install implant/rootkit. But in this blog post, I want to focus on classification of vulnerabilities and attack vectors which is opening the doors of BIOS for persistent infection. Note that the threat model represented on the following figure only covers flows related to UEFI firmware, whereas nowadays the scope of security issues for Intel ME and AMT is significantly increasing. Additionally, in the past few years the BMC emerged as a very important security asset for remote management server platforms, and is getting a lot of attention from the researchers.

All classes of vulnerabilities in this figure can help an attacker to violate security boundaries and install persistent implants.

All the vulnerabilities can be divided into two big groups: “Post-Exploitation” and “Compromised Supply Chain”. In the previous blog post, I explained the possible remote exploitation schemes and stages of the attacks, but we did not touch on the details of actual exploits and vulnerabilities.

Let’s start from classes of vulnerabilities from Post-Exploitation part of the figure.

Secure Boot Bypass — focuses on compromising the secure boot process over exploiting Root of Trust (full compromise) or a vulnerability in one of the boot stages before the OS loads. Secure Boot bypasses can occur in different boot stages and can be leverages by the attacker against all the subsequent layers and their trust mechanisms.

SMM Privilege Escalation — SMM has a lot of power on x86 hardware, as almost all privilege escalation issues for SMM end up as code execution issues. Privilege escalation to SMM is often one of the final stages of a BIOS implant installation.

UEFI Firmware Implant — the final stage of persistent BIOS implant installation. It can be installed on different levels of the UEFI firmware as a modified legitimate module or a standalone driver (DXE, PEI).

Persistent Implant — a BIOS implant that survives full reboot and shutdown cycles. Also, in some cases can modify BIOS updates images before installation to survive the post-update process.

Non-Persistent Implant — a BIOS implant that doesn’t survive full reboot and shutdown cycles (in some cases can survive sleep or hibernate states). Focused on privilege escalation and code execution inside the OS with protected hardware virtualization (e.g., Intel VT-x) and layers of trusted execution (e.g., MS VBS). Also, can be used to deliver malicious payloads to kernel-mode or break TEE memory isolation.

The class of Post-Exploitation vulnerabilities is the leading one for persistent or non-persistent implant installation after successful exploitation of previous stages. But Compromised Supply Chain is another important class of scenarios where critical security issues can arise from unwitting mistakes by the BIOS development team or the OEM hardware vendor, or from deliberate misconfigurations of the target software intended to provide the attackers with a deniable bypass of the platform’s security features.

Misconfigurations of hardware and firmware become an important vector for attacks in the situations when the hardware’s owner cannot monitor physical access to the hardware, such as when leaving a laptop in a checked bag, surrendering it for a foreign customs inspection, or simply leaving it in a hotel room. All these situations can serve as opportunities for delivering BIOS implants. These attack vectors are sometimes referred to as the “Evil Maid attack”, which can be thought of as a convenient catch-all term for any threat outside of the supply chain compromise. Most common examples include firmware or hardware implant installation, exploiting hardware vulnerabilities to bypass full disk encryption, or even simple attacks on data confidentiality such as hard drive cloning.

Misconfigured Protections — misconfigurations of protection technologies introduced during development process or post-production.

Non-Secure Root of Trust — Root of Trust can be compromised from the OS via its communication interfaces with firmware (for example, SMM).

Malicious Peripheral Devices — implanted peripheral devices can be installed in production or delivery stages. Malicious devices can be used in multiple ways, such as for DMA attacks.

Implanted BIOS Updates — infected BIOS updates can be delivered via a compromised vendor website or another remote update mechanism. The points of compromise can include the vendors’ build servers, developer systems, or stolen digital certificates with vendor’s private keys.

Unauthenticated BIOS Update Process — broken authentication process for the BIOS updates. This includes vendors that deliberately do not authenticate the BIOS updates, and thus allow attackers to apply any modifications to the update images.

Outdated BIOS with known security issues — one of the most common security failures of the BIOS firmware is due to the BIOS developers continuing to use the older vulnerable code versions even after the underlying code base has been patched. An outdated version of the BIOS originally delivered by the hardware vendor is likely to persist un-updated on the users’ PCs or data center servers.

The compromised supply chain is very hard to fix without changes in the development and production lifecycles. Usually, production client or server platforms involve a lot of third parties components as in software either in hardware. Most of the companies who are don’t own full production cycle don’t care too much about security.

This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.

--

--

Alex Matrosov
Firmware Threat Hunting

Embedded Security REsearcher with more than two decades of experience in offensive and defensive research. Author of “Rootkits and Bootkits” book (bootkits.io).