Summary for CISOs: A critical vulnerability (CVE-2024-7344) in UEFI Secure Boot allows attackers to bypass security checks and execute unsigned code during system boot. Affecting multiple recovery software suites, this flaw leverages a Microsoft-signed UEFI application to load malicious payloads. Patches were released in Microsoft’s January 2025 Patch Tuesday update, but systems must apply revocations to mitigate the risk.
TL;DR:
- Vulnerability: Bypasses UEFI Secure Boot via a signed UEFI application (
reloader.efi). - Impact: Enables execution of untrusted bootkits (e.g., BlackLotus) even on Secure Boot-enabled systems.
- Affected Systems: Most UEFI-based devices with Microsoft’s third-party UEFI CA 2011 certificate enrolled.
- Fix: Microsoft revoked vulnerable binaries; updates available via Windows Update and Linux Vendor Firmware Service.
Technical Analysis
Vulnerability Overview
CVE-2024-7344 stems from a UEFI application (reloader.efi) signed by Microsoft’s Microsoft Corporation UEFI CA 2011 certificate. The application, developed by Howyar Technologies and bundled in recovery software from vendors like Greenware and Radix, uses a custom PE loader instead of secure UEFI functions (LoadImage/StartImage). This allows loading unsigned binaries from a file named cloak.dat during boot, circumventing Secure Boot checks1.
Exploitation Details
Attackers can exploit this by:
- Replacing the OS bootloader with
reloader.efion the EFI System Partition (ESP). - Placing a malicious
cloak.dat(containing an unsigned UEFI binary) in/EFI/boot/or/EFI/Microsoft/boot/. - Rebooting the system to execute the payload1.
Proof of Concept: A video demonstrating exploitation is available in ESET’s report1. The attack requires administrative/root privileges to modify the ESP.
Affected Software
The following recovery software versions are vulnerable18:
- Howyar SysReturn (<10.2.023_20240919)
- Greenware GreenGuard (<10.2.023-20240927)
- Radix SmartRecovery (<11.2.023-20240927)
Detection and Mitigation
For Windows Systems
Verify protections using PowerShell:
# Check if Microsoft UEFI CA 2011 is trusted (vulnerable if 'True')
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'
# Confirm revocation (returns 'True' if patched)
[BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'For Linux Systems
Check revocations via:
dbxtool --list | grep 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'Additional Measures:
- Restrict ESP access using file integrity monitoring or HIPS rules.
- Enable TPM-based remote attestation to detect bootkit modifications1.
Relevance to Security Teams
- Red Teams: Demonstrates a persistence vector for bypassing Secure Boot.
- Blue Teams: Highlights the need for firmware monitoring and prompt revocation updates.
- Threat Intel: Links to known bootkits (BlackLotus) and prior UEFI flaws (CVE-2022-34302)15.
Conclusion
CVE-2024-7344 underscores ongoing challenges in UEFI security, particularly with third-party signed binaries. While patches are available, organizations must prioritize firmware updates and monitor ESP modifications. Microsoft’s planned transition to UEFI CA 2023 may improve transparency, but proactive defense remains critical15.
