Unveiling CVE-2024-7344: The Secrets Behind UEFI Secure Boot’s Vulnerability

ESET’s experts have identified a weakness permitting the circumvention of UEFI Secure Boot, impacting the majority of UEFI-compatible systems. This flaw, designated as CVE-2024-7344, was discovered in a UEFI application endorsed by Microsoft’s Microsoft Corporation UEFI CA 2011 third-party UEFI certificate. Exploiting this vulnerability enables the execution of unverified code during system startup, allowing potential hackers to effortlessly employ malicious UEFI bootkits (like Bootkitty or BlackLotus), even on systems where UEFI Secure Boot is active, independent of the operating system in use.

The compromised UEFI application is included in various real-time system recovery software solutions produced by Howyar Technologies Inc., Greenware Technologies, Radix Technologies Ltd., SANFONG Inc., Wasay Software Technology Inc., Computer Education System Inc., and Signal Computer GmbH. Below is the compilation of vulnerable software products:

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

This vulnerability arises from utilizing a custom PE loader rather than the secure and standard UEFI functions LoadImage and StartImage. Consequently, the application permits loading any UEFI binary – even unsigned ones – from a specially engineered file named cloak.dat, during system boot, regardless of the UEFI Secure Boot status.

Our findings were communicated to the CERT Coordination Center (CERT/CC) in June 2024, which adeptly contacted the affected vendors. The issue has now been rectified in their products, and Microsoft revoked the outdated, susceptible binaries in the Patch Tuesday update on January 14^th, 2025.

Essential points from this blog post:

• ESET’s researchers uncovered a new vulnerability, CVE-2024-7344, enabling the bypassing of UEFI Secure Boot on the majority of UEFI-compatible systems.
• Exploitation of this flaw permits the running of untrusted code during system startup, paving the way for the deployment of malicious UEFI bootkits.
• All UEFI systems with Microsoft third-party UEFI signing enabled are impacted (Windows 11 Secured-core PCs should have this option turned off by default).
• The vendors affected have resolved the issue, and Microsoft revoked the older, vulnerable binaries in the January 14^th, 2025 Patch Tuesday update.

Below is the timeline for coordinated disclosure. We express our gratitude to CERT/CC for its assistance in coordinating the vulnerability disclosure process and to the affected vendors for their smooth, transparent communication and collaboration throughout the vulnerability disclosure and remediation efforts.

Coordinated disclosure timeline:

• 2024-07-08: ESET identified the vulnerability.
• 2024-07-09: ESET notified CERT/CC about the vulnerability.
• 2024-07-23: CERT/CC agreed to assist us in coordinating the vulnerability disclosure, with the public disclosure date set for 2024-10-21.
• 2024-08-05: CERT/CC effectively reached out to the affected vendors.
• 2024-08-20: Vendors submitted an initial patch for evaluation.
• 2024-08-20: ESET confirmed that the stated issue was properly addressed but discovered another newly introduced problem stemming from the same root cause.
• 2024-08-28: Vendors provided a second patch for evaluation.
• 2024-09-23: We reached an agreement with Microsoft on a new public disclosure date of 2025-01-14.
• 2025-01-14: Microsoft revoked the affected vulnerable UEFI applications.
• 2025-01-16: ESET published the blog post.

UEFI Secure Boot in real-world scenarios

Before delving into the description of the vulnerability, let’s examine how UEFI Secure Boot verification operates on actual devices and who oversees the management of UEFI Secure Boot databases on them.

The fundamental logic is straightforward and is illustrated in Figure 1. When the UEFI Boot Manager initiates the loading of a boot application, such as Windows Boot Manager, shim, GRUB2, or similar, it performs several checks, including verifying the boot application binary against two Secure Boot databases:

• db – a list of permitted certificates or PE Authenticode hashes, which are trusted by the platform firmware.
• dbx – a compilation of disallowed certificates or PE Authenticode hashes.

The requirements stipulate that the verified image must be trusted by the db, and concurrently, its hash or certificate should not appear on the dbx database. Based on the outcomes of the verification, the UEFI boot manager either triggers a security violation or executes the validated image.

To ensure that UEFI Secure Boot can safeguard the boot procedure of significant operating systems on newly acquired UEFI devices (by default and without user involvement), most devices come preloaded with a specific collection of UEFI certificates enrolled in theirdb database. Although these certificates may differ depending on the OEM and the particular device’s specifications and functions, for the majority of standard devices (like laptops, desktops, servers, etc.), Microsoft requires OEMs to incorporate Microsoft’s certificates. This is the reason Microsoft has a crucial part in securing most UEFI-enabled devices; with Microsoft’s keys added to db, Microsoft can oversee what can be executed during boot and what cannot.

Microsoft UEFI certificates

As mentioned earlier, numerous UEFI devices are equipped with Microsoft’s UEFI certificates. Below are two specific certificates that are typically found among the trusted ones on such devices:

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

It is important to note that the Microsoft Windows Production PCA 2011 certificate is expected to be revoked and substituted with the Windows UEFI CA 2023 certificate shortly (more info), in response to the vulnerabilities in Windows bootloaders linked to the notorious BlackLotus bootkit. New or updated Windows devices will already recognize this new certificate. Regarding the Microsoft Corporation UEFI CA 2011 certificate, it continues to be utilized for signing fresh UEFI applications; however, it is anticipated that it will also be replaced in the future by a new certificate named Microsoft UEFI CA 2023. For those interested in Microsoft’s UEFI certificate rolling strategy, check out the Evolving the Secure Boot Ecosystem slides presented at the UEFI Fall 2023 Developers Conference & Plugfest.

While the first certificate (the PCA) is utilized by Microsoft for signing its own UEFI boot applications, the latter is employed by Microsoft for signing UEFI boot software created by third-party developers, which includes Linux shims, various specialized recovery, backup, disk encryption, and maintenance software, among others…

This indicates that any individual interested in ensuring their boot-time software is compatible with UEFI Secure Boot by default can request Microsoft to sign their binaries (via the Windows Hardware Dev Center dashboard). If the binaries pass Microsoft’s internal analysis, Microsoft signs them with its third-party UEFI certificate, thereby making the files 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 trusted by default).

From the Microsoft UEFI signing requirements available online, it remains unclear what the internal review process entails, although it certainly suggests some form of deeper evaluation rather than merely checking against the listed requirements. While we believe that the manual review process improves with each new vulnerability identified, greater transparency regarding what is being signed and what checks are part of this manual review could enhance the likelihood that such evidently vulnerable binaries, like the one discussed in this report, are discovered and remedied faster.

CVE-2024-7344

When we encountered Howyar’s SysReturn software package last year, the first thing that immediately attracted our notice was the existence of a file named cloak.dat deployed alongside a Microsoft-signed UEFI application called reloader.efi. Below are the PE Authenticode hashes of the vulnerable reloader.efi application:

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

In this examination, we utilize the 64-bit version of reloader.efi. As illustrated in Figure 2, the cloak.dat file comprises a header-like data structure that begins with the magic string ALRM. This header is succeeded by unidentified data that visually resembles the structure of a PE/COFF file header, encrypted with a simple XOR cipher. It is straightforward to deduce the key based on the frequency of 0xB3 bytes, which corresponds to the numerous 0x00 bytes found in standard PE/COFF headers. Decrypting cloak.dat using an XOR operation with the key 0xB3 reveals that it indeed contains a UEFI application – furthermore, it is unsigned.

We soon discovered that the extracted binary is not malicious, but we questioned: is this binary somehow engaged by SysReturn’s bootloader during system initialization? If it is, does it account for UEFI Secure Boot and refuse to load this unsigned binary if it is enabled? Upon a deeper investigation of reloader.efi, we located code tasked with loading the cloak.dat file into memory and decrypting the embedded image. As illustrated in Figure 3, the function attempts to load the file from one of the following locations on the EFI system partition:

• EFIMicrosoftbootcloak64.dat
• EFIbootcloak64.dat
• EFIMicrosoftbootcloak.dat
• EFIbootcloak.dat

“`html

Up until now, nothing appears to be amiss – the bootloader could convey the buffer holding the decrypted PE image to the UEFI’s LoadImage function as a parameter, which would verify that the image complies with the UEFI Secure Boot guidelines of the machine through the validation process outlined in Figure 1. Regrettably, this is not the situation. Following the decryption of a PE image from the cloak.dat file, the susceptible bootloader invokes its own function illustrated in Figure 4, which is accountable for manually loading and executing the image devoid of any integrity checks related to Secure Boot.

A demonstration of exploitation of the vulnerability in a system with UEFI Secure Boot activated is presented in the video below.

This vulnerability’s exploitation is not confined to systems that have the affected recovery software installed, as attackers can introduce their own version of the vulnerable reloader.efi binary to any UEFI system that has the Microsoft third-party UEFI certificate enrolled. Additionally, elevated permissions are necessary to place the vulnerable and harmful files in the EFI system partition (local administrator on Windows; root on Linux). To exploit the vulnerability, an attacker would need to:

1. Substitute a standard OS bootloader binary on the EFI system partition (ESP) with the vulnerable reloader.efi.
2. Transfer a specially crafted cloak.dat file, containing a harmful UEFI application, to one of the directories on the ESP supported by the susceptible bootloader.
3. Reboot the system.

After verifying the vulnerability by developing a functioning proof of concept, we discovered that the vulnerable reloader.efi application was utilized not solely by Howyar’s SysReturn software but also by several other recovery software applications. A comprehensive list of affected software packages can be found at the beginning of this blog post. Since multiple products from different vendors appeared to be impacted, we reached out to CERT/CC, who assisted us in contacting the affected parties and coordinating the vulnerability disclosure process.

Thus far, we have not identified any actual exploitation efforts in our telemetry data.

Protection and detection

The vulnerability can be alleviated by implementing the latest UEFI revocations from Microsoft. Windows systems should be updated automatically. Microsoft’s advisory regarding the CVE-2024-7344 vulnerability can be accessed here. Execute the following PowerShell commands (run with elevated privileges) to determine if you are affected by the vulnerability and if the necessary revocations were installed on your system:

# UEFI systems; returns True if your system is impacted 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 safeguarded (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 safeguarded (the vulnerable driver is revoked on your system)

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

For Linux systems, updates should be obtainable through the Linux Vendor Firmware Service. Implement the following commands to ascertain whether the necessary revocations are present on your system:

dbxtool –list | grep ‘cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48’

dbxtool –list | grep ‘e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9’

Although UEFI revocations effectively safeguard your system against CVE-2024-7344, alternative methods, varying in effectiveness, can help protect against (or at least detect) the exploitation of unknown vulnerable signed UEFI bootloaders and the deployment of UEFI bootkits, including:

• Managed access to files located on the EFI system partition. In most scenarios for UEFI bootkit installation, an attacker requires modifying the contents of the EFI system partition to install a UEFI bootkit or exploit a vulnerability in a signed UEFI bootloader on the targeted system. Most security solutions permit the creation of custom user-defined file access regulations which enable blocking access to specific files or directories on the system (e.g., here and here).
• Customization of UEFI Secure Boot. As elucidated in the NSA’s UEFI Secure Boot Customization report, Secure Boot customization can be employed to effectively defend against UEFI bootkits or, at the very least, to minimize the attack surface or allow for swift revocations of vulnerable UEFI applications to system owners if official revocation updates take longer. While effective, it often necessitates skilled administrators (incorrect Secure Boot configurations can result in temporary unbootability of systems), and it can be challenging to manage on a large scale. 
• Remote attestation with TPM, wherein measurements of UEFI boot components and configurations can be confirmed against their verified values by a trusted remote server, and thus used
  “`

• to identify unauthorized boot alterations.

Conclusion

The quantity of UEFI vulnerabilities uncovered in recent years, along with the inadequacies in addressing them or rescinding compromised binaries within an acceptable timeframe, indicates that even a critical feature such as UEFI Secure Boot should not be deemed an unassailable safeguard.

Nevertheless, what troubles us the most regarding the vulnerability mentioned in this blog post is not the duration it took to remedy and withdraw the binary, which was relatively swift compared to other instances, but the reality that this is not the initial occasion a clearly unsafe signed UEFI binary has been detected. In fact, a remarkably similar Microsoft-signed vulnerable UEFI application (CVE-2022-34302), featuring its own perilous PE loader, was identified approximately two years ago by Eclypsium in One Bootloader to Load Them All.

This prompts inquiries about the prevalence of such hazardous practices among third-party UEFI software vendors, as well as how many other such obscure, yet signed, bootloaders may exist. We contacted Microsoft regarding this situation, hoping it could enhance transparency regarding which third-party UEFI applications they endorse, allowing users to swiftly identify and report such evidently unsafe UEFI applications if they mistakenly pass (or have passed long ago) Microsoft’s UEFI third-party code-signing assessment. We believe that Microsoft’s upcoming rollout of new UEFI certificates represents an excellent opportunity to achieve this, advancing UEFI third-party signing transparency and UEFI security by a notch.

For any questions concerning our research published on WeLiveSecurity, please reach out to us at [email protected]. 

ESET Research provides private APT intelligence summaries and data feeds. For any inquiries about this service, visit the ESET Threat Intelligence webpage.

Indicators of Compromise (IoCs)

Given that the vulnerable loaders are integrated into legitimate software packages that may be found on countless systems that have never been breached via these loaders, we are refraining from providing indicators of compromise to prevent widespread misidentifications. Instead, defenders ought to adhere to the guidance in the Protection and detection segment.