Details have emerged of a patched security vulnerability that could bypass the Secure Boot mechanism on Unified Extensible Firmware Interface (UEFI) systems.
A vulnerability assigned a CVE identifier CVE-2024-7344 (CVSS score: 6.7), resides in a UEFI application signed by a third-party UEFI certificate from Microsoft “Microsoft Corporation UEFI CA 2011” according to new report from ESET shared with The Hacker News.
Successful exploitation of the flaw could lead to the execution of untrusted code during system boot, thereby allowing attackers to deploy malicious UEFI bootkits on machines that have Secure Boot enabled, regardless of the installed operating system.
Secure boot is a firmware security standard which prevents malware from loading when the computer starts up, ensuring that the device boots using only software trusted by the original equipment manufacturer (OEM). A feature levers digital signatures to verify the authenticity, source and integrity of the code being downloaded.
The corrupted UEFI application is part of several real-time system recovery software packages 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 to version 10.2.023_20240919
- Greenware GreenGuard to version 10.2.023-20240927
- Radix SmartRecovery to version 11.2.023-20240927
- Sanfong EZ-back system to version 10.3.024-20241127
- WASAY eRecoveryRX to version 8.4.022-20241127
- CES NeoImpact to version 10.1.024-20241127
- SignalComputer HDD King to version 10.3.021-20241127
“The vulnerability is caused by using a custom PE bootloader instead of using standard and secure UEFI features Upload image and StartImage” said ESET researcher Martin Smolar. “As a result, the program allows any UEFI binary – even an unsigned one – to be loaded from a specially crafted file called cloak.dat during system startup, regardless of the UEFI secure boot state. “
Therefore, an attacker using CVE-2024-7344 as a weapon could bypass UEFI Secure Boot protections and execute unsigned code during the boot process in the UEFI context even before the operating system boots, giving them covert persistent access to the host.
“Code executed in this early boot phase can persist in the system, potentially loading malicious kernel extensions that survive both reboots and OS reinstalls,” CERT Coordination Center (CERT/CC) said. “In addition, it can avoid detection by OS-based security measures and endpoint detection and response (EDR).”
Attackers can further expand the scope of exploitation by transferring their own copy of the vulnerable “reloader.efi” binary to any UEFI system with a registered Microsoft third-party UEFI certificate. However, deploying vulnerable and malicious files to the EFI system partition requires elevated privileges: local administrator on Windows and root on Linux.
The Slovak cybersecurity firm said it responsibly disclosed the CERT/CC findings in June 2024, after which Howyar Technologies and its partners resolved the issue in their respective products. January 14, 2025 Microsoft has recalled older vulnerable binaries as part of its Tuesday patch update.
In addition to applying UEFI rollback, controlling access to files located on the EFI system partition, Setting up secure bootand distance certification with the trusted platform module (TPM) are among other ways to protect against the use of unknown vulnerable signed UEFI bootloaders and UEFI bootkit deployments.
“The number of UEFI vulnerabilities discovered in recent years and the failure to patch them or retract vulnerable binaries within a reasonable time window shows that even a feature as essential as UEFI Secure Boot should not be considered an impenetrable barrier,” Smolar said. .
“However, our biggest concern regarding the vulnerability is not the time it took to patch and retract the binary, which was quite good compared to similar cases, but the fact that this is not the first time such an apparently vulnerable binary has been discovered UEFI. This raises the question of how common such unsafe practices are among third-party UEFI software vendors, and how many others are similar. may be obscure, but signed loaders”.
