Details have emerged about a now-patched security vulnerability that could allow a bypass of the Secure Boot mechanism in Unified Extensible Firmware Interface (UEFI) systems.
The vulnerability, assigned the CVE identifier CVE-2024-7344 (CVSS score: 6.7), resides in a UEFI application signed by Microsoft’s “Microsoft Corporation UEFI CA 2011” third-party UEFI certificate, according to a new report from ESET shared with The Hacker News.
Successful exploitation of the flaw can lead to the execution of untrusted code during system boot, thereby enabling attackers to deploy malicious UEFI bootkits on machines that have Secure Boot on, irrespective of the operating system installed.
Secure Boot is a firmware security standard that prevents malware from loading when a computer starts up by ensuring that the device boots using only software that is trusted by the Original Equipment Manufacturer (OEM). The feature leverages digital signatures to validate the authenticity, source, and integrity of the code that is loaded.
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 –
- 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,” ESET researcher Martin Smolár said. “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.”
An attacker who weaponizes CVE-2024-7344 could, therefore, sidestep UEFI Secure Boot protections and execute unsigned code during the boot process in the UEFI context even before the operating system loads, granting them covert, persistent access to the host.
“Code executed in this early boot phase can persist on the system, potentially loading malicious kernel extensions that survive both reboots and OS reinstallation,” the CERT Coordination Center (CERT/CC) said. “Additionally, it may evade detection by OS-based and endpoint detection and response (EDR) security measures.”
Malicious actors could further expand the scope of exploitation by bringing their own copy of the vulnerable “reloader.efi” binary to any UEFI system with the Microsoft third-party UEFI certificate enrolled. However, elevated privileges are required to deploy the vulnerable and malicious files to the EFI system partition: local administrator on Windows and root on Linux.
The Slovakian cybersecurity firm said it responsibly disclosed the findings to the CERT/CC in June 2024, following which Howyar Technologies and their partners addressed the issue in the concerned products. On January 14, 2025, Microsoft revoked the old, vulnerable binaries as part of its Patch Tuesday update.
Outside of applying UEFI revocations, managing access to files located on the EFI system partition, Secure Boot customization, and remote attestation with a Trusted Platform Module (TPM) are some of the other ways of protecting against exploitation of unknown vulnerable signed UEFI bootloaders and deployment of UEFI bootkits.
“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,” Smolár said.
“However, what concerns us the most with respect to the vulnerability 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. This raises questions of how common the use of such unsafe techniques is among third-party UEFI software vendors, and how many other similar obscure, but signed, bootloaders there might be out there.”
