uefi

Code found online exploits LogoFAIL to install Bootkitty Linux backdoor

Biz & IT, bootkitty, Linux, logofail, Security, uefi, unified extensible firmware interface / Tim Belzer / November 29, 2024

Normally, Secure Boot prevents the UEFI from running all subsequent files unless they bear a digital signature certifying those files are trusted by the device maker. The exploit bypasses this protection by injecting shell code stashed in a malicious bitmap image displayed by the UEFI during the boot-up process. The injected code installs a cryptographic key that digitally signs a malicious GRUB file along with a backdoored image of the Linux kernel, both of which run during later stages of the boot process on Linux machines.

The silent installation of this key induces the UEFI to treat the malicious GRUB and kernel image as trusted components, and thereby bypass Secure Boot protections. The final result is a backdoor slipped into the Linux kernel before any other security defenses are loaded.

Diagram illustrating the execution flow of the LogoFAIL exploit Binarly found in the wild. Credit: Binarly

In an online interview, HD Moore, CTO and co-founder at runZero and an expert in firmware-based malware, explained the Binarly report this way:

The Binarly paper points to someone using the LogoFAIL bug to configure a UEFI payload that bypasses secure boot (firmware) by tricking the firmware into accepting their self-signed key (which is then stored in the firmware as the MOK variable). The evil code is still limited to the user-side of UEFI, but the LogoFAIL exploit does let them add their own signing key to the firmware’s allow list (but does not infect the firmware in any way otherwise).

It’s still effectively a GRUB-based kernel backdoor versus a firmware backdoor, but it does abuse a firmware bug (LogoFAIL) to allow installation without user interaction (enrolling, rebooting, then accepting the new MOK signing key).

In a normal secure boot setup, the admin generates a local key, uses this to sign their updated kernel/GRUB packages, tells the firmware to enroll the key they made, then after reboot, the admin has to accept this new key via the console (or remotely via bmc/ipmi/ilo/drac/etc bios console).

In this setup, the attacker can replace the known-good GRUB + kernel with a backdoored version by enrolling their own signing key without user interaction via the LogoFAIL exploit, but it’s still effectively a GRUB-based bootkit, and doesn’t get hardcoded into the BIOS firmware or anything.

Machines vulnerable to the exploit include some models sold by Acer, HP, Fujitsu, and Lenovo when they ship with a UEFI developed by manufacturer Insyde and run Linux. Evidence found in the exploit code indicates the exploit may be tailored for specific hardware configurations of such machines. Insyde issued a patch earlier this year that prevents the exploit from working. Unpatched devices remain vulnerable. Devices from these manufacturers that use non-Insyde UEFIs aren’t affected.

Code found online exploits LogoFAIL to install Bootkitty Linux backdoor Read More »

Found in the wild: The world’s first unkillable UEFI bootkit for Linux

Biz & IT, bootkit, malware, Security, uefi / Kris Guyer / November 27, 2024

Over the past decade, a new class of infections has threatened Windows users. By infecting the firmware that runs immediately before the operating system loads, these UEFI bootkits continue to run even when the hard drive is replaced or reformatted. Now the same type of chip-dwelling malware has been found in the wild for backdooring Linux machines.

Researchers at security firm ESET said Wednesday that Bootkitty—the name unknown threat actors gave to their Linux bootkit—was uploaded to VirusTotal earlier this month. Compared to its Windows cousins, Bootkitty is still relatively rudimentary, containing imperfections in key under-the-hood functionality and lacking the means to infect all Linux distributions other than Ubuntu. That has led the company researchers to suspect the new bootkit is likely a proof-of-concept release. To date, ESET has found no evidence of actual infections in the wild.

The ASCII logo that Bootkitty is capable of rendering. Credit: ESET

Be prepared

Still, Bootkitty suggests threat actors may be actively developing a Linux version of the same sort of unkillable bootkit that previously was found only targeting Windows machines.

“Whether a proof of concept or not, Bootkitty marks an interesting move forward in the UEFI threat landscape, breaking the belief about modern UEFI bootkits being Windows-exclusive threats,” ESET researchers wrote. “Even though the current version from VirusTotal does not, at the moment, represent a real threat to the majority of Linux systems, it emphasizes the necessity of being prepared for potential future threats.”

A rootkit is a piece of malware that runs in the deepest regions of the operating system it infects. It leverages this strategic position to hide information about its presence from the operating system itself. A bootkit, meanwhile, is malware that infects the boot-up process in much the same way. Bootkits for the UEFI—short for Unified Extensible Firmware Interface—lurk in the chip-resident firmware that runs each time a machine boots. These sorts of bootkits can persist indefinitely, providing a stealthy means for backdooring the operating system even before it has fully loaded and enabled security defenses such as antivirus software.

The bar for installing a bootkit is high. An attacker first must gain administrative control of the targeted machine, either through physical access while it’s unlocked or somehow exploiting a critical vulnerability in the OS. Under those circumstances, attackers already have the ability to install OS-resident malware. Bootkits, however, are much more powerful since they (1) run before the OS does and (2) are, at least practically speaking, undetectable and unremovable.

Found in the wild: The world’s first unkillable UEFI bootkit for Linux Read More »

Secure Boot is completely broken on 200+ models from 5 big device makers

Biz & IT, cryptography, Features, key compromise, rootkits, secure boot, Security, supply chain, uefi, unified extensible firmware interface / Mike M. / July 25, 2024

In 2012, an industry-wide coalition of hardware and software makers adopted Secure Boot to protect against a long-looming security threat. The threat was the specter of malware that could infect the BIOS, the firmware that loaded the operating system each time a computer booted up. From there, it could remain immune to detection and removal and could load even before the OS and security apps did.

The threat of such BIOS-dwelling malware was largely theoretical and fueled in large part by the creation of ICLord Bioskit by a Chinese researcher in 2007. ICLord was a rootkit, a class of malware that gains and maintains stealthy root access by subverting key protections built into the operating system. The proof of concept demonstrated that such BIOS rootkits weren’t only feasible; they were also powerful. In 2011, the threat became a reality with the discovery of Mebromi, the first-known BIOS rootkit to be used in the wild.

Keenly aware of Mebromi and its potential for a devastating new class of attack, the Secure Boot architects hashed out a complex new way to shore up security in the pre-boot environment. Built into UEFI—the Unified Extensible Firmware Interface that would become the successor to BIOS—Secure Boot used public-key cryptography to block the loading of any code that wasn’t signed with a pre-approved digital signature. To this day, key players in security—among them Microsoft and the US National Security Agency—regard Secure Boot as an important, if not essential, foundation of trust in securing devices in some of the most critical environments, including in industrial control and enterprise networks.

An unlimited Secure Boot bypass

On Thursday, researchers from security firm Binarly revealed that Secure Boot is completely compromised on more than 200 device models sold by Acer, Dell, Gigabyte, Intel, and Supermicro. The cause: a cryptographic key underpinning Secure Boot on those models that was compromised in 2022. In a public GitHub repository committed in December of that year, someone working for multiple US-based device manufacturers published what’s known as a platform key, the cryptographic key that forms the root-of-trust anchor between the hardware device and the firmware that runs on it. The repository was located at https://github.com/raywu-aaeon/Ryzen2000_4000.git, and it’s not clear when it was taken down.

The repository included the private portion of the platform key in encrypted form. The encrypted file, however, was protected by a four-character password, a decision that made it trivial for Binarly, and anyone else with even a passing curiosity, to crack the passcode and retrieve the corresponding plain text. The disclosure of the key went largely unnoticed until January 2023, when Binarly researchers found it while investigating a supply-chain incident. Now that the leak has come to light, security experts say it effectively torpedoes the security assurances offered by Secure Boot.

“It’s a big problem,” said Martin Smolár, a malware analyst specializing in rootkits who reviewed the Binarly research and spoke to me about it. “It’s basically an unlimited Secure Boot bypass for these devices that use this platform key. So until device manufacturers or OEMs provide firmware updates, anyone can basically… execute any malware or untrusted code during system boot. Of course, privileged access is required, but that’s not a problem in many cases.”

Binarly researchers said their scans of firmware images uncovered 215 devices that use the compromised key, which can be identified by the certificate serial number 55:fb:ef: 87: 81: 23: 00: 84: 47: 17:0b:b3:cd: 87:3a:f4. A table appearing at the end of this article lists each one.

The researchers soon discovered that the compromise of the key was just the beginning of a much bigger supply-chain breakdown that raises serious doubts about the integrity of Secure Boot on more than 300 additional device models from virtually all major device manufacturers. As is the case with the platform key compromised in the 2022 GitHub leak, an additional 21 platform keys contain the strings “DO NOT SHIP” or “DO NOT TRUST.”

Enlarge / Test certificate provided by AMI.

Binarly

Secure Boot is completely broken on 200+ models from 5 big device makers Read More »

Critical vulnerability affecting most Linux distros allows for bootkits

Biz & IT, bootkits, Linux, Security, shim, uefi, vulnerabilities / Paul Patrick / February 6, 2024

Linux developers are in the process of patching a high-severity vulnerability that, in certain cases, allows the installation of malware that runs at the firmware level, giving infections access to the deepest parts of a device where they’re hard to detect or remove.

The vulnerability resides in shim, which in the context of Linux is a small component that runs in the firmware early in the boot process before the operating system has started. More specifically, the shim accompanying virtually all Linux distributions plays a crucial role in secure boot, a protection built into most modern computing devices to ensure every link in the boot process comes from a verified, trusted supplier. Successful exploitation of the vulnerability allows attackers to neutralize this mechanism by executing malicious firmware at the earliest stages of the boot process before the Unified Extensible Firmware Interface firmware has loaded and handed off control to the operating system.

The vulnerability, tracked as CVE-2023-40547, is what’s known as a buffer overflow, a coding bug that allows attackers to execute code of their choice. It resides in a part of the shim that processes booting up from a central server on a network using the same HTTP that the Internet is based on. Attackers can exploit the code-execution vulnerability in various scenarios, virtually all following some form of successful compromise of either the targeted device or the server or network the device boots from.

“An attacker would need to be able to coerce a system into booting from HTTP if it’s not already doing so, and either be in a position to run the HTTP server in question or MITM traffic to it,” Matthew Garrett, a security developer and one of the original shim authors, wrote in an online interview. “An attacker (physically present or who has already compromised root on the system) could use this to subvert secure boot (add a new boot entry to a server they control, compromise shim, execute arbitrary code).”

Stated differently, these scenarios include:

Acquiring the ability to compromise a server or perform an adversary-in-the-middle impersonation of it to target a device that’s already configured to boot using HTTP
Already having physical access to a device or gaining administrative control by exploiting a separate vulnerability.

While these hurdles are steep, they’re by no means impossible, particularly the ability to compromise or impersonate a server that communicates with devices over HTTP, which is unencrypted and requires no authentication. These particular scenarios could prove useful if an attacker has already gained some level of access inside a network and is looking to take control of connected end-user devices. These scenarios, however, are largely remedied if servers use HTTPS, the variant of HTTP that requires a server to authenticate itself. In that case, the attacker would first have to forge the digital certificate the server uses to prove it’s authorized to provide boot firmware to devices.

The ability to gain physical access to a device is also difficult and is widely regarded as grounds for considering it to be already compromised. And, of course, already obtaining administrative control through exploiting a separate vulnerability in the operating system is hard and allows attackers to achieve all kinds of malicious objectives.

Critical vulnerability affecting most Linux distros allows for bootkits Read More »