ESET researchers recently disclosed CVE-2024-7344, a critical vulnerability that compromises UEFI Secure Boot, a cornerstone of firmware-level security for modern systems. This flaw affects a wide range of UEFI-based systems and enables the execution of untrusted code during the boot process, thus bypassing Secure Boot protections. Attackers exploiting this vulnerability can deploy persistent and stealthy threats like Bootkits (e.g., Bootkitty and BlackLotus) even on devices with Secure Boot enabled, irrespective of the operating system.
The root cause of the vulnerability lies in the improper use of a custom PE loader within certain UEFI applications. Instead of leveraging UEFI’s secure functions like LoadImage and StartImage, the application in question employs unsafe practices that allow the execution of unsigned binaries.
Scope of Impact
- Affected Applications:
- The vulnerable UEFI application, signed using Microsoft’s third-party UEFI certificate, is incorporated into multiple recovery software products from vendors such as Howyar Technologies, Greenware Technologies, and others.
- Specific products include SysReturn, GreenGuard, SmartRecovery, and others (full list detailed in the initial disclosure).
- Exploitation Mechanism:
- An attacker with elevated privileges (e.g., local administrator on Windows or root on Linux) can replace the default bootloader on the EFI system partition with the vulnerable
reloader.efibinary. - A specially crafted
cloak.datfile, containing an unsigned and potentially malicious UEFI application, is then loaded and executed during the boot process.
- An attacker with elevated privileges (e.g., local administrator on Windows or root on Linux) can replace the default bootloader on the EFI system partition with the vulnerable
- System Requirements for Exploitation:
- The affected system must trust Microsoft Corporation UEFI CA 2011, which is enrolled by default in most UEFI-enabled systems.
UEFI Secure Boot: How It Works and Where It Failed
UEFI Secure Boot is a firmware feature designed to ensure the integrity of the boot process. It uses two key databases:
- db (allow list): Stores certificates and hashes of trusted binaries.
- dbx (block list): Maintains blacklisted certificates and hashes.
For a binary to execute during boot:
- Its hash or signing certificate must be in
db. - It must not appear in
dbx.
In the case of CVE-2024-7344, the affected bootloader bypasses this mechanism entirely. The vulnerability resides in the custom loading process, where an unsigned binary is decrypted and executed without verification against Secure Boot policies.
Discovery and Remediation Timeline
- Discovery:
- ESET identified the vulnerability in July 2024 and reported it to the CERT Coordination Center (CERT/CC) for responsible disclosure.
- Vendor Coordination:
- CERT/CC engaged with impacted vendors, resulting in patch development and validation.
- Microsoft revoked the vulnerable binaries in its January 14, 2025 Patch Tuesday update.
- Key Milestones:
- 2024-07-08: Vulnerability discovered by ESET.
- 2024-08-20: Initial vendor patches issued; follow-up required due to additional issues.
- 2025-01-14: Microsoft revocation of affected binaries.
Strategic Insights and Mitigation Recommendations
- Apply Critical Updates:
- Ensure all systems are updated with the latest UEFI revocations from Microsoft. Use tools like PowerShell or dbxtool to verify the presence of updated certificates and revoked binaries.
- Secure Boot Customization:
- Disable Microsoft third-party UEFI certificate signing on systems where it is not required.
- Customize Secure Boot policies, as outlined by organizations like the NSA, to reduce attack surface and ensure stricter control over bootloader integrity.
- Enhance Detection and Prevention:
- Implement file access controls for the EFI system partition, preventing unauthorized modifications.
- Use remote attestation with TPM to validate UEFI boot components and configurations against trusted baselines.
- Vendor Accountability:
- Encourage transparency in UEFI signing processes to ensure only secure and validated binaries are trusted.
- Advocate for stricter scrutiny during the signing of third-party UEFI applications by vendors like Microsoft.
- Broader Ecosystem Improvements:
- Push for the adoption of Microsoft’s UEFI CA 2023 certificate to phase out reliance on older, vulnerable certificates.
- Promote automated security analysis for all UEFI applications to prevent unsafe practices, such as custom PE loaders, from entering production.
Critical Observations for the Cybersecurity Community
- Repeat Incidents:
- This vulnerability mirrors similar flaws from the past, such as CVE-2022-34302, where another Microsoft-signed UEFI application was found to bypass Secure Boot. Such patterns highlight systemic gaps in third-party software validation.
- Persistent Risks:
- Bootkits exploiting firmware-level vulnerabilities pose a significant threat due to their stealth and persistence. Traditional antivirus and endpoint solutions often fail to detect such low-level compromises.
- Call for Transparency:
- Greater transparency in UEFI signing processes is essential. Clear documentation and public accountability for signed binaries would empower the cybersecurity community to detect and address unsafe practices earlier.
- Future-Proofing UEFI Security:
- As UEFI adoption grows, the security community must focus on evolving standards, better patch management, and coordinated response mechanisms to minimize exploitation risks.
The discovery of CVE-2024-7344 underscores the importance of treating UEFI Secure Boot not as an impenetrable barrier but as a component requiring vigilant oversight. While prompt vendor response mitigated the immediate risk, this case serves as a cautionary tale about relying on opaque validation processes for foundational security features.
By addressing these challenges holistically—through vendor accountability, enhanced Secure Boot configurations, and transparent UEFI certificate management—the cybersecurity community can strengthen its defenses against similar threats in the future.
Information security specialist, currently working as risk infrastructure specialist & investigator.
15 years of experience in risk and control process, security audit support, business continuity design and support, workgroup management and information security standards.