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 14th, 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 14th, 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.
The Microsoft Corporation UEFI CA 2011 certificate is still in use for signing new UEFI applications, but it is expected to be replaced in the future by a new certificate called Microsoft UEFI CA 2023. Those interested in Microsoft’s UEFI certificate rolling plan can refer to the slides presented at the UEFI Fall 2023 Developers Conference & Plugfest titled Evolving the Secure Boot Ecosystem.
The former certificate (PCA) is used by Microsoft to sign its own UEFI boot applications, while the latter is used for signing UEFI boot software developed by third parties, such as Linux shims, specialized recovery tools, disk encryption software, and more. This allows third-party UEFI-compatible software to be signed by Microsoft through the Windows Hardware Dev Center dashboard, making them compatible with most UEFI systems that trust Microsoft’s third-party certificate (excluding Windows 11 Secured-core PCs).
The process for signing binaries with Microsoft’s UEFI certificate involves an internal review, although details about this review process are not fully disclosed. Transparency in the review process could help identify and address vulnerabilities in signed binaries sooner.
One particular vulnerability identified is identified as CVE-2024-7344, involving a Microsoft-signed UEFI application named reloader.efi deployed alongside a file called cloak.dat. The bootloader associated with this software does not perform UEFI Secure Boot integrity checks on the decrypted PE image from the cloak.dat file, potentially allowing for the execution of unsigned or malicious code.
This vulnerability could be exploited on systems with the affected software installed, but attackers could also introduce their own vulnerable binary to any UEFI system with Microsoft’s third-party UEFI certificate. Additionally, elevated privileges are required to manipulate files on the EFI system partition. To take advantage of this vulnerability, an attacker would need to follow these steps:
1. Replace the default OS bootloader binary on the EFI system partition (ESP) with the vulnerable `reloader.efi`.
2. Place a specially crafted `cloak.dat` file, containing a malicious UEFI application, in one of the supported paths on the ESP by the vulnerable bootloader.
3. Reboot the system.
After confirming the vulnerability with a working proof of concept, it was discovered that the vulnerable `reloader.efi` application was not only used by Howyar’s SysReturn software but also by several other recovery software products. A list of affected software packages can be detailed at the beginning of this blog post. As multiple products from different vendors were affected, CERT/CC was contacted to assist in reaching out to the affected parties and coordinating the vulnerability disclosure process.
No real-world exploitation attempts have been detected in telemetry data so far.
### Protection and Detection
The vulnerability can be mitigated by applying the latest UEFI revocations from Microsoft. Windows systems should receive automatic updates. Microsoft’s advisory for the CVE-2024-7344 vulnerability can be accessed [here](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-7344). Use the following PowerShell commands (run with elevated permissions) to check if you are affected by the vulnerability and if the necessary revocations have been installed on your system:
“`powershell
# 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](https://fwupd.org/). Use the following commands to check if the necessary revocations are installed on your system:
“`bash
dbxtool –list | grep ‘cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48’
dbxtool –list | grep ‘e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9’
“`
While UEFI revocations provide effective protection against CVE-2024-7344, there are other ways to protect against or detect exploitation of unknown vulnerable signed UEFI bootloaders and deployment of UEFI bootkits, including:
– Managed access to files on the EFI system partition.
– UEFI Secure Boot customization.
– Remote attestation with TPM.
### Conclusion
The discovery of UEFI vulnerabilities in recent years and the challenges in patching them highlight the importance of not relying solely on UEFI Secure Boot as an impenetrable barrier. The vulnerability discussed in this blog post, although promptly fixed, raises concerns about the prevalence of unsafe signed UEFI binaries in third-party software.
For further inquiries regarding our research, please contact us at threatintel@eset.com. ESET Research also offers private APT intelligence reports and data feeds. For more information on this service, visit the [ESET Threat Intelligence](https://www.eset.com/int/business/services/threat-intelligence/?utm_source=welivesecurity.com&utm_medium=referral&utm_campaign=wls-research&utm_content=under-cloak-uefi-secure-boot-introducing-cve-2024-7344/&sfdccampaignid=7011n0000017htTAAQ) page.
### IoCs
Due to the widespread presence of the vulnerable loaders in legitimate software packages, we are refraining from providing indicators of compromise to prevent misidentification. Defenders are advised to follow the guidance in the Protection and Detection section above. text using different words:
Please rewrite the paragraph in your own words.
