Under the cloak of UEFI Secure Boot: Introducing CVE-2024-7344

ESET researchers have discovered a vulnerability that allows bypassing UEFI Secure Boot, affecting the majority of UEFI-based systems. This vulnerability, assigned CVE-2024-7344, was found in a UEFI application signed by Microsoft’s Microsoft Corporation UEFI CA 2011 third-party UEFI certificate. Exploitation of this vulnerability leads to the execution of untrusted code during system boot, enabling potential attackers to easily deploy malicious UEFI bootkits (such as Bootkitty or BlackLotus) even on systems with UEFI Secure Boot enabled, regardless of the installed operating system.

The affected UEFI application is part of several real-time system recovery software suites developed by Howyar Technologies Inc., Greenware Technologies, Radix Technologies Ltd., SANFONG Inc., Wasay Software Technology Inc., Computer Education System Inc., and Signal Computer GmbH. Following is the list of vulnerable software products:

• Howyar SysReturn before version 10.2.023_20240919
• Greenware GreenGuard before version 10.2.023-20240927
• Radix SmartRecovery before version 11.2.023-20240927
• Sanfong EZ-back System before version 10.3.024-20241127
• WASAY eRecoveryRX before version 8.4.022-20241127
• CES NeoImpact before version 10.1.024-20241127
• SignalComputer HDD King before version 10.3.021-20241127

The vulnerability is caused by the use of a custom PE loader instead of using the standard and secure UEFI functions LoadImage and StartImage. As a result, the application allows the loading of any UEFI binary – even an unsigned one – from a specially crafted file named cloak.dat, during system start, regardless of the UEFI Secure Boot state.

We reported our findings to the CERT Coordination Center (CERT/CC) in June 2024, which successfully contacted the affected vendors. The issue has now been fixed in their products and the old, vulnerable binaries were revoked by Microsoft in the January 14^th, 2025 Patch Tuesday update.

Key points of this blogpost:

• ESET researchers discovered a new vulnerability, CVE-2024-7344, that allows bypassing UEFI Secure Boot on the majority of UEFI-based systems.
• Exploitation of this vulnerability allows execution of untrusted code during system boot, enabling deployment of malicious UEFI bootkits.
• All UEFI systems with Microsoft third-party UEFI signing enabled are affected (Windows 11 Secured-core PCs should have this option disabled by default).
• The issue was fixed by affected vendors and old, vulnerable binaries were revoked by Microsoft in the January 14^th, 2025 Patch Tuesday update.

Following is the coordinated disclosure timeline. We’d like to thank CERT/CC for its help in coordinating the vulnerability disclosure process, and the affected vendors for smooth and transparent communication and cooperation during the vulnerability disclosure and remediation process.

Coordinated disclosure timeline:

• 2024-07-08: ESET found the vulnerability.
• 2024-07-09: ESET reported the vulnerability to CERT/CC.
• 2024-07-23: CERT/CC agreed to help us coordinate the vulnerability disclosure process – public disclosure date was set to 2024-10-21.
• 2024-08-05: CERT/CC successfully reached out to the affected vendors.
• 2024-08-20: Vendors provided initial patch for review.
• 2024-08-20: ESET confirmed the reported issue was addressed correctly, but discovered another newly introduced issue with the same root cause.
• 2024-08-28: Vendors provided second patch for review.
• 2024-09-23: We agreed with Microsoft on the new public disclosure date of 2025-01-14.
• 2025-01-14: Revocation of affected vulnerable UEFI applications by Microsoft.
• 2025-01-16: ESET blogpost published.

UEFI Secure Boot in the real world

Before jumping in to describing the vulnerability, let’s have a look at how UEFI Secure Boot verification works on real devices, and who is responsible for managing the UEFI Secure Boot databases on them.

The basic logic is quite simple and is depicted in Figure 1. When UEFI Boot Manager proceeds to load a boot application, such as Windows Boot Manager, shim, GRUB2, or similar, among other checks, it verifies the boot application binary against two Secure Boot databases:

• db – list of allowed certificates or PE Authenticode hashes, trusted by the platform firmware.
• dbx – list of forbidden certificates or PE Authenticode hashes.

The conditions are that the verified image has to be trusted by the db and, at the same time, the file’s hash or its certificate must not be listed in the dbx database. Based on the verification results, the UEFI boot manager either causes a security violation or executes the verified image.

To ensure that UEFI Secure Boot can secure the boot process of major operating systems on newly purchased UEFI devices (by default and without user interaction), most devices come with a set of specific UEFI certificates enrolled in their db database. While these certificates can vary based on the OEM and the specific device’s requirements and purpose, on most regular devices (such as laptops, desktops, servers…), Microsoft asks OEMs to include Microsoft’s own certificates. That’s why Microsoft plays an important role in securing most of such UEFI-based devices, as with Microsoft’s keys enrolled in db, Microsoft can manage what is allowed, and what is not allowed, to be executed during boot.

Microsoft UEFI certificates

As explained above, many UEFI devices come with Microsoft’s UEFI certificates enrolled. The following are two specific certificates that are usually present among the trusted ones on such devices:

• Microsoft Windows Production PCA 2011
• Microsoft Corporation UEFI CA 2011

Note that the Microsoft Windows Production PCA 2011 certificate should be revoked and replaced with the Windows UEFI CA 2023 certificate by Microsoft soon (more info), as a response to the vulnerable Windows bootloaders related to the infamous BlackLotus bootkit. New or updated Windows devices will already trust this new certificate. In the case of the Microsoft Corporation UEFI CA 2011 certificate, it still seems to be used for signing new UEFI applications; however, it should also be replaced in the future with a new certificate called Microsoft UEFI CA 2023. For anyone interested in Microsoft’s UEFI certificate rolling plan, have a look at the Evolving the Secure Boot Ecosystem slides presented at the UEFI Fall 2023 Developers Conference & Plugfest.

While the former certificate (the PCA one) is used by Microsoft to sign its own UEFI boot applications, the latter is used by Microsoft to sign UEFI boot software developed by third parties, which includes Linux shims, various specialized recovery, backup, disk encryption, or maintenance software, and so on…

This means that anyone interested in having their boot-time software UEFI Secure Boot-compatible by default can ask Microsoft to sign their binaries (through the Windows Hardware Dev Center dashboard), and if the binaries pass Microsoft’s internal review, Microsoft signs them with its third-party UEFI certificate and thus the files become compatible with the majority of UEFI systems, which trust Microsoft’s third-party certificate (on Windows 11 Secured-core PCs, Microsoft’s third-party UEFI certificate should not be considered as trusted by default).

From the Microsoft UEFI signing requirements available online, it’s unclear what the internal review process includes, even though it certainly evokes some deeper analysis instead of just walking through the listed requirements. While we believe that the manual review process is being improved over time with every new vulnerability discovered, greater transparency in what is actually being signed and in what checks this manual review process includes could increase the chances that such obviously vulnerable binaries as the one described in this report are discovered and fixed sooner.

CVE-2024-7344

When we encountered Howyar’s SysReturn software package last year, the first thing that immediately caught our attention was the presence of a file named cloak.dat deployed along with a Microsoft-signed UEFI application named reloader.efi. Following are the PE Authenticode hashes of the vulnerable reloader.efi application:

• cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48 (64-bit version)
• e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9 (32-bit version)

In this analysis, we use the 64-bit version of reloader.efi. As shown in Figure 2, the cloak.dat file contains a header-like data structure starting with the magic string ALRM. This header is followed by unknown data visually resembling the structure of a PE/COFF file header, encrypted using a simple XOR cipher. It is easy to guess the key based on the frequency of 0xB3 bytes, corresponding to the plethora of 0x00 bytes present in regular PE/COFF headers. Decrypting cloak.dat by using an XOR operation with the key 0xB3 reveals that it indeed contains a UEFI application – moreover, an unsigned one.

We quickly found out that the extracted binary isn’t malicious, but we wondered: is this binary somehow used by SysReturn’s bootloader during system start? If so, does it take UEFI Secure Boot into consideration and refuse to load this unsigned binary if enabled? After looking deeper into reloader.efi, we found code responsible for loading cloak.dat file into memory and decrypting the embedded image. As shown in Figure 3, the function tries to load the file from one of the following locations on the EFI system partition:

• \EFI\Microsoft\boot\cloak64.dat
• \EFI\boot\cloak64.dat
• \EFI\Microsoft\boot\cloak.dat
• \EFI\boot\cloak.dat

So far, there wouldn’t be anything wrong with that – the bootloader could still pass the buffer containing the decrypted PE image to the UEFI’s LoadImage function as an argument, which would ensure that the image meets the machine’s UEFI Secure Boot policy by the verification process described in Figure 1. Unfortunately, this isn’t the case. After decryption of a PE image from the cloak.dat file, the vulnerable bootloader calls its own function depicted in Figure 4, responsible for manually loading and executing the image without any Secure Boot-related integrity checks.

A proof of concept demonstrating exploitation of the vulnerability on a system with UEFI Secure Boot enabled is shown in the video below.

Exploitation of this vulnerability is not limited to systems with the affected recovery software installed, as attackers can bring their own copy of the vulnerable reloader.efi binary to any UEFI system with the Microsoft third-party UEFI certificate enrolled. Also, elevated privileges are required to deploy the vulnerable and malicious files to the EFI system partition (local administrator on Windows; root on Linux). To exploit the vulnerability, an attacker would need to:

1. Replace a default OS bootloader binary on the EFI system partition (ESP) with the vulnerable reloader.efi.
2. Copy a specially crafted cloak.dat file, containing a malicious UEFI application, to one of the paths on the ESP supported by the vulnerable bootloader.
3. Reboot the system.

After we confirmed the vulnerability by creating a working proof of concept, we noticed that the vulnerable reloader.efi application was used not only by Howyar’s SysReturn software, but also by several additional recovery software products. An exhaustive list of affected software packages can be found at the beginning of this blogpost. As more than one product developed by different vendors seemed to be affected, we contacted CERT/CC, who helped us reach out to the affected parties and coordinate the vulnerability disclosure process.

So far, we have not detected any real-world exploitation attempts in our telemetry data.

Protection and detection

The vulnerability can be mitigated by applying the latest UEFI revocations from Microsoft. Windows systems should be updated automatically. Microsoft’s advisory for the CVE-2024-7344 vulnerability can be found here. Use the following PowerShell commands (run with elevated permissions) to check whether you’re affected by the vulnerability and if the necessary revocations were installed on your system:

# UEFI systems; returns True if your system is affected by the CVE-2024-7344

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'

# 64-bit UEFI systems; returns True if you’re protected (the vulnerable driver is revoked on your system)

[BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'

# 32-bit UEFI systems; returns True if you’re protected (the vulnerable driver is revoked on your system)

[BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

For Linux systems, updates should be available through the Linux Vendor Firmware Service. Use the following commands to check whether the necessary revocations are installed on your system:

dbxtool --list | grep 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'

dbxtool --list | grep 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

While UEFI revocations effectively protect your system against CVE-2024-7344, there are other more or less effective ways of protecting against (or at least detecting) exploitation of unknown vulnerable signed UEFI bootloaders and deployment of UEFI bootkits, including:

• Managed access to files located on the EFI system partition. In most UEFI bootkit installation scenarios, an attacker needs to modify the contents of the EFI system partition in order to install a UEFI bootkit or to exploit a vulnerability in a signed UEFI bootloader on the targeted system. Most security products allow creation of custom user-defined file access rules that allow blocking access to specific files or directories on the system (e.g., here and here).
• UEFI Secure Boot customization. As detailed in the NSA’s UEFI Secure Boot Customization report, Secure Boot customization can be used to effectively protect against UEFI bootkits or, at least, to reduce the attack surface or allow faster revocations of vulnerable UEFI applications to system owners if official revocation updates take a longer time. While effective, it often requires experienced administrators (improper Secure Boot configurations can make systems temporarily unbootable) and it can be difficult to manage at scale. 
• Remote attestation with TPM, where measurements of UEFI boot components and configuration can be validated against their known good values by a trusted remote server, and thus used to detect unauthorized boot modifications.

Conclusion

The number of UEFI vulnerabilities discovered in recent years and the failures in patching them or revoking vulnerable binaries within a reasonable time window shows that even such an essential feature as UEFI Secure Boot should not be considered an impenetrable barrier.

However, what concerns us the most in the case of the vulnerability reported in this blogpost is not the time it took to fix and revoke the binary, which was quite good compared to similar cases, but the fact that this isn’t the first time that such an obviously unsafe signed UEFI binary has been discovered. In reality, a very similar Microsoft-signed vulnerable UEFI application (CVE-2022-34302), implementing its own unsafe PE loader, was discovered about two years ago by Eclypsium in One Bootloader to Load Them All.

This raises questions of how common the use of such unsafe techniques is among third-party UEFI software vendors, and how many other such obscure, but signed, bootloaders there might be out there. We reached out to Microsoft about the situation, hoping it could bring more transparency into what third-party UEFI applications they sign, so that anyone can quickly discover and report such obviously unsafe UEFI applications if they mistakenly pass (or passed a long time ago) Microsoft’s UEFI third-party code-signing review. We believe that Microsoft’s planned rollout of new UEFI certificates provides a great opportunity to make this happen, pushing UEFI third-party signing transparency and UEFI security one step forward.

For any inquiries about our research published on WeLiveSecurity, please contact us at threatintel@eset.com. 

ESET Research offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the ESET Threat Intelligence page.

IoCs

As the vulnerable loaders are part of legitimate software packages that are potentially present on thousands of systems that have never been compromised via these loaders, we are not providing indicators of compromise to avoid massive misidentification. Instead, defenders should follow the advice in the Protection and detection section.