Skip to content
Microsoft patches Windows to eliminate Secure Boot bypass threat

Microsoft patches Windows to eliminate Secure Boot bypass threat

For the past seven months—and likely longer—an industry-wide standard that protects Windows devices from firmware infections could be bypassed using a simple technique. On Tuesday, Microsoft finally patched the vulnerability. The status of Linux systems is still unclear.

Tracked as CVE-2024-7344, the vulnerability made it possible for attackers who had already gained privileged access to a device to run malicious firmware during bootup. These types of attacks can be particularly pernicious because infections hide inside the firmware that runs at an early stage, before even Windows or Linux has loaded. This strategic position allows the malware to evade defenses installed by the OS and gives it the ability to survive even after hard drives have been reformatted. From then on, the resulting “bootkit” controls the operating system start.

In place since 2012, Secure Boot is designed to prevent these types of attacks by creating a chain-of-trust linking each file that gets loaded. Each time a device boots, Secure Boot verifies that each firmware component is digitally signed before it’s allowed to run. It then checks the OS bootloader’s digital signature to ensure that it’s trusted by the Secure Boot policy and hasn’t been tampered with. Secure Boot is built into the UEFI—short for Unified Extensible Firmware Interface—the successor to the BIOS that’s responsible for booting modern Windows and Linux devices.

An unsigned UEFI app lurks

Last year, researcher Martin Smolár with security firm ESET noticed something curious about SysReturn, a real-time system recovery software suite available from Howyar Technologies. Buried deep inside was an XOR-encoded UEFI application named reloader.efi, which was digitally signed after somehow passing Microsoft’s internal review process for third-party UEFI apps.

Rather than invoking the UEFI functions LoadImage and StartImage for performing the Secure Boot process, reloader.efi used a custom PE loader. This custom loader didn’t perform the required checks. As Smolár dug further, he found that reloader.efi was present not only in Howyar’s SysReturn, but also in recovery software from six other suppliers. The complete list is:

Source link