This is a cache of https://arstechnica.com/security/2024/11/found-in-the-wild-the-worlds-first-unkillable-uefi-bootkit-for-linux/. It is a snapshot of the page at 2024-11-28T01:13:22.293+0000.
Found in the wild: The world’s first unkillable UEFI bootkit for Linux &#x<strong>2</strong>d; Ars Technica
Skip to content
HARD TO DETECT. HARD TO DISINFECT

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

"Bootkitty" is likely a proof-of-concept, but may portend working UEFI malware for Linux.

Dan Goodin | 57
Credit: Getty Images
Credit: Getty Images
Story text

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.

The Bootkitty sample ESET found is unable to override a defense, known as UEFI Secure Boot, that uses cryptographic signatures to ensure that each piece of software loaded during startup is trusted by a computer's manufacturer. Secure Boot is designed to create a chain of trust that prevents attackers from replacing the intended bootup firmware with malicious firmware. When Secure Boot is enabled, if a single firmware link in that chain isn’t recognized, the device won't boot.

The Bootkitty execution flow Credit: ESET

The image above summarizes the key parts of the Bootkitty execution flow. They are:

• Execution of the bootkit and patching of the legitimate GRUB bootloader (points 4 and 5 in Figure 6)
• Patching of the Linux kernel’s EFI stub loader (points 6 and 7 in Figure 6)
• Patching of the decompressed Linux kernel image (points 8 and 9 in Figure 6).

Despite working on a handful of Ubuntu versions, Bootkitty contains flaws and limitations in crucial functionality required for it to run in real-world infections on a wider based on machines. One imperfection resides in the way the bootkit modifies the decompressed Linux kernel. As shown in the chunk of Bootkitty code displayed below, once the kernel image is decompressed, Bootkitty simply copies the malicious patches to the hardcoded offsets within the kernel image.

A chunk of Bootkitty code Credit: ESET

The result: “due to the lack of kernel-version checks in the function shown in [the figure above] Bootkitty can get to the point where it patches completely random code or data at these hardcoded offsets, thus crashing the system instead of compromising it,” ESET researchers explained.

Additionally, the inability to defeat Secure Boot limits infection opportunities to devices that (1) don’t enable the defense or (2) have already been compromised by the same attacker to install a self-signed cryptographic certificate. Further, Bootkitty leaves a trail of artifacts behind that make discovery relatively easy. That undermines a key bootkit advantage: stealth.

As ESET notes, the discovery is nonetheless significant because it demonstrates someone—most likely a malicious threat actor—is pouring resources and considerable know-how into creating working UEFI bootkits for Linux. Currently, there are few simple ways for people to check the integrity of the UEFI running on either Windows or Linux devices. The demand for these sorts of defenses will likely grow in the coming years.

Photo of Dan Goodin
Dan Goodin Senior Security Editor
Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82.
57 Comments