Overview
As part of our continuing research into vulnerable and malicious bootloaders, we have identified three new bootloader vulnerabilities which affect the vast majority of devices released over the past 10 years including x86-64 and ARM-based devices. These vulnerabilities could be used by an attacker to easily evade Secure Boot protections and compromise the integrity of the boot process; enabling the attacker to modify the operating system as it loads, install backdoors, and disable operating system security controls.
Much like our previous GRUB2 BootHole research, these new vulnerable bootloaders are signed by the Microsoft UEFI Third Party Certificate Authority. By default, this CA is trusted by virtually all traditional Windows and Linux-based systems such as laptops, desktops, servers, tablets, and all-in-one systems. As a result, an attacker could simply install the vulnerable bootloader, and it would be trusted by the target device. Such an update would require the attacker to have administrator privileges, however, such escalations are common and readily available.
Since this issue impacts multiple parts of the supply chain, the mitigation process may require multiple steps. Ultimately, organizations will need to update the DBX database on their devices, which maintains a list of disallowed code. HOWEVER, it is important to note that any devices that use the three affected bootloaders will need to obtain new bootloaders from the affected vendors BEFORE updating the DBX. Failing to do so will result in the device failing to boot.
The Vulnerabilities
This section summarizes the key points of each vulnerability, however, a more in-depth analysis is available in our recent DEF CON talk (link). We have identified vulnerabilities in three different bootloaders, which have been assigned the following CVEs:
- CVE-2022-34301 – Eurosoft (UK) Ltd
- CVE-2022-34302 – New Horizon Datasys Inc
- CVE-2022-34303 – CryptoPro Secure Disk for BitLocker
Two of the vulnerabilities (CVE-2022-34301 and CVE-2022-34303) are similar in that they involve signed UEFI shells. In the case of Eurosoft, the signed shell is esdiags.efi while for CryptoPro Secure Disk, the shell is Shell_Full.efi. In both cases, an attacker can use the built-in capabilities of the shell to evade Secure Boot, such as the ability to read and write to memory, list handles, and map memory. The exploitation could be easily automated using startup scripts.
The behavior of these shells have a visual element that a user could potentially see on a monitor, yet would remain unseen on systems without a screen such as servers or industrial systems. The New Horizon Datasys vulnerability (CVE-2022-34302) is far more stealthy and would always remain invisible to the system owner. This bootloader contains a built-in bypass for Secure Boot that leaves Secure Boot on but disables the Secure Boot checks. This bypass can further enable even more complex evasions such as disabling security handlers. In this case, an attacker would not need scripting commands, and could directly run arbitrary unsigned code. The simplicity of exploitation makes it highly likely that adversaries will attempt to exploit this particular vulnerability in the wild.
Exploiting these vulnerabilities requires an attacker to have elevated privileges (Administrator on Windows or root on Linux). However, local privilege escalation is a common problem on both platforms. In particular, Microsoft does not consider UAC-bypass a defendable security boundary and often does not fix reported bypasses, so there are many mechanisms in Windows that can be used to elevate privileges from a non-privileged user to Administrator.
It is worth remembering that the intent of Secure Boot is to ensure that malicious code doesn’t violate the integrity of the boot process. While malware and malicious code running at the OS level is relatively common, Secure Boot and other related security capabilities are specifically designed to ensure that those threats can’t further elevate privileges to gain complete control of the device and preempt other security controls. These vulnerabilities would allow attackers to cross this boundary and to do so quite easily.
Mitigation Steps and Supply Chain Challenges
Bootloader vulnerabilities pose a supply chain problem that can complicate an organization’s mitigation efforts. Unlike a traditional vulnerability that can simply be patched and resolved, addressing these bootloader vulnerabilities requires multiple parties. In addition to updates from Microsoft, the affected suppliers will also need to remediate and publish updates for their code. If Microsoft or other OS distributions deploy automated updates that blacklist the vulnerable bootloaders immediately, then any devices using that code may fail to boot.
This means that organizations will likely need to take more manual steps in order to mitigate their risk. It is important to remember that the ease with which these vulnerabilities can be weaponized means there is a high probability we will eventually see threats in the wild. In order to protect their devices, organizations should take the following steps.
- Verify if their devices use any of the vulnerable bootloaders
- By default, bootloaders are stored in the EFI System Partition (ESP). This is not mounted by default on Windows, but can be mounted and examined using the /S flag (mountvol DRIVE: /s). On Linux, this filesystem is mounted at /boot/efi/.
- If using a vulnerable bootloader, the organization should apply a bootloader update from the relevant vendor when available. Organizations with an affected bootloader MUST NOT apply DBX updates before updating the bootloader or the device will fail to boot.
- Update the DBX revocation database only after verifying that the device is not using one of the vulnerable bootloaders. Windows users can refer to the following advisory for recommendations on how to update their DBX.
Eclypsium customers can use the platform to automatically identify vulnerable devices and take appropriate action.
Key Take-Aways
Much like BootHole, these vulnerabilities highlight the challenges of ensuring the boot integrity of devices that rely on a complex supply chain of vendors and code working together. While the industry has made great strides in improving the security of firmware and the overall boot process, these issues highlight how simple vulnerabilities in third-party code can undermine the entire process. The broader issue is that these are not uncommon incidents. There are many more examples of third-party code which has been signed by Microsoft and is therefore trusted implicitly by devices. Like all code, this third-party code can contain vulnerabilities that have unexpected consequences and can be difficult to mitigate. This will require ongoing vigilance both to identify these issues and coordinate better responses to ensure devices remain as safe as possible.
