Particulars have emerged a few now-patched safety vulnerability that might enable a bypass of the Safe Boot mechanism in Unified Extensible Firmware Interface (UEFI) techniques.
The vulnerability, assigned the CVE identifier CVE-2024-7344 (CVSS rating: 6.7), resides in a UEFI utility signed by Microsoft’s “Microsoft Company UEFI CA 2011” third-party UEFI certificates, in line with a brand new report from ESET shared with The Hacker Information.
Profitable exploitation of the flaw can result in the execution of untrusted code throughout system boot, thereby enabling attackers to deploy malicious UEFI bootkits on machines which have Safe Boot on, no matter the working system put in.
Safe Boot is a firmware safety commonplace that forestalls malware from loading when a pc begins up by making certain that the machine boots utilizing solely software program that’s trusted by the Unique Tools Producer (OEM). The characteristic leverages digital signatures to validate the authenticity, supply, and integrity of the code that’s loaded.
The affected UEFI utility is a part of a number of real-time system restoration software program suites developed by Howyar Applied sciences Inc., Greenware Applied sciences, Radix Applied sciences Ltd., SANFONG Inc., Wasay Software program Know-how Inc., Laptop Training System Inc., and Sign Laptop GmbH –
- Howyar SysReturn earlier than model 10.2.023_20240919
- Greenware GreenGuard earlier than model 10.2.023-20240927
- Radix SmartRecovery earlier than model 11.2.023-20240927
- Sanfong EZ-back System earlier than model 10.3.024-20241127
- WASAY eRecoveryRX earlier than model 8.4.022-20241127
- CES NeoImpact earlier than model 10.1.024-20241127
- SignalComputer HDD King earlier than model 10.3.021-20241127
“The vulnerability is brought on by way of a customized PE loader as an alternative of utilizing the usual and safe UEFI capabilities LoadImage and StartImage,” ESET researcher Martin Smolár mentioned. “In consequence, the appliance permits the loading of any UEFI binary – even an unsigned one – from a specifically crafted file named cloak.dat, throughout system begin, whatever the UEFI Safe Boot state.”
An attacker who weaponizes CVE-2024-7344 may, subsequently, sidestep UEFI Safe Boot protections and execute unsigned code in the course of the boot course of within the UEFI context even earlier than the working system hundreds, granting them covert, persistent entry to the host.
“Code executed on this early boot part can persist on the system, probably loading malicious kernel extensions that survive each reboots and OS reinstallation,” the CERT Coordination Middle (CERT/CC) mentioned. “Moreover, it might evade detection by OS-based and endpoint detection and response (EDR) safety measures.”
Malicious actors may additional develop the scope of exploitation by bringing their very own copy of the susceptible “reloader.efi” binary to any UEFI system with the Microsoft third-party UEFI certificates enrolled. Nevertheless, elevated privileges are required to deploy the susceptible and malicious recordsdata to the EFI system partition: native administrator on Home windows and root on Linux.
The Slovakian cybersecurity agency mentioned it responsibly disclosed the findings to the CERT/CC in June 2024, following which Howyar Applied sciences and their companions addressed the difficulty within the involved merchandise. On January 14, 2025, Microsoft revoked the outdated, susceptible binaries as a part of its Patch Tuesday replace.
Outdoors of making use of UEFI revocations, managing entry to recordsdata positioned on the EFI system partition, Safe Boot customization, and distant attestation with a Trusted Platform Module (TPM) are among the different methods of defending towards exploitation of unknown susceptible signed UEFI bootloaders and deployment of UEFI bootkits.
“The variety of UEFI vulnerabilities found lately and the failures in patching them or revoking susceptible binaries inside an affordable time window exhibits that even such an important characteristic as UEFI Safe Boot shouldn’t be thought-about an impenetrable barrier,” Smolár mentioned.
“Nevertheless, what issues us probably the most with respect to the vulnerability just isn’t the time it took to repair and revoke the binary, which was fairly good in comparison with related instances, however the truth that this is not the primary time that such an clearly unsafe signed UEFI binary has been found. This raises questions of how frequent the usage of such unsafe methods is amongst third-party UEFI software program distributors, and what number of different related obscure, however signed, bootloaders there could be on the market.”
