Cyber security news for all

More

    A New Vulnerability Unveiled in UEFI Secure Boot: An Avenue for Malicious Bootkits

    Details have surfaced concerning a critical, albeit now-resolved, security loophole capable of bypassing the Secure Boot protocol embedded in Unified Extensible Firmware Interface (UEFI) systems.

    Tagged with the identifier CVE-2024-7344 and awarded a CVSS score of 6.7, this vulnerability pertains to a UEFI application digitally signed under Microsoft’s “Microsoft Corporation UEFI CA 2011” third-party certificate, as revealed in an ESET report shared with The Hacker News.

    Exploitation Pathways and Implications

    Successful exploitation of this flaw enables the execution of untrusted code during the boot sequence, facilitating the deployment of malignant UEFI bootkits—even on systems with Secure Boot active, regardless of the operating system.

    Secure Boot, a pivotal firmware integrity mechanism, ensures that only software authenticated by the Original Equipment Manufacturer (OEM) executes during startup. This functionality leverages cryptographic signatures to ascertain the legitimacy, origin, and integrity of loaded code.

    However, the afflicted UEFI application, utilized in various real-time recovery solutions from vendors such as Howyar Technologies, Greenware Technologies, and others, demonstrated a significant lapse.

    Impacted software versions include:

    • Howyar SysReturn: Pre-10.2.023_20240919
    • Greenware GreenGuard: Pre-10.2.023-20240927
    • Radix SmartRecovery: Pre-11.2.023-20240927
    • Sanfong EZ-back System: Pre-10.3.024-20241127
    • WASAY eRecoveryRX: Pre-8.4.022-20241127
    • CES NeoImpact: Pre-10.1.024-20241127
    • SignalComputer HDD King: Pre-10.3.021-20241127

    Root Cause and Exploit Mechanics

    ESET researcher Martin Smolár identified the vulnerability’s origin in the application’s use of a custom PE loader, bypassing UEFI’s robust LoadImage and StartImage functions. Consequently, this oversight permits the initiation of unsigned UEFI binaries, concealed within a specially crafted file named cloak.dat, irrespective of Secure Boot’s enforcement status.

    Exploitation could enable threat actors to circumvent Secure Boot safeguards, introducing unsigned code during the boot stage. This intrusion establishes a foothold in the system pre-OS load, paving the way for stealthy, persistent malware. Such deeply embedded code could survive reboots and even operating system reinstalls.

    The CERT Coordination Center (CERT/CC) elaborated, stating, “Malicious code deployed in this foundational boot phase risks evading detection by OS-level and endpoint security solutions while retaining the capability to load rogue kernel extensions.”

    Broader Exploitation Scenarios

    Adversaries might amplify exploitation by introducing compromised versions of the vulnerable reloader.efi binary into any UEFI system with Microsoft’s third-party certificate enrolled. Notably, elevated privileges, such as local admin access on Windows or root access on Linux, are prerequisites for this deployment.

    Timelines and Mitigation

    ESET responsibly disclosed these findings to CERT/CC in June 2024, prompting Howyar Technologies and partners to address vulnerabilities in their software. Microsoft followed suit, revoking compromised binaries in its January 14, 2025 Patch Tuesday updates.

    To further fortify against analogous vulnerabilities, organizations are advised to adopt additional defenses such as:

    • UEFI revocation updates
    • Limiting access to EFI system partition files
    • Customizing Secure Boot configurations
    • Implementing remote attestation using Trusted Platform Modules (TPMs)

    Persistent Concerns and Industry Implications

    Despite prompt remedial action, Smolár expressed unease over recurring discoveries of unsafe signed UEFI binaries, remarking, “While the response to fix and revoke the binary was commendable, the prevalence of such insecurely signed UEFI applications raises disconcerting questions. It underscores the pressing need for a meticulous review of third-party UEFI software development practices.”

    In summation, the recurring identification of UEFI vulnerabilities—alongside delays in addressing them—highlights that even fundamental security features like Secure Boot are fallible, warranting vigilant oversight and proactive defense mechanisms.

    Recent Articles

    Related Stories