Bootkitty: The First UEFI Bootkit for Linux

In November of 2024, a bootkit.efi hash was uploaded to the Virus Total database by an anonymous source (1), to which researchers at ESET uncovered that this binary pertained to the first of its kind: a UEFI Bootkit written not for Windows, but for Linux (2). Through their analysis, ESET determined that the application, titled Bootkitty, had likely been created as a proof-of-concept, and while the bootkit may not exfiltrate user information or drop malware onto infected computers, it has opened the flood gates as to the feasibility of bootkits on Linux (3). However, in the hierarchy of malware, bootkits are not only one of the most insidious, but also most difficult to understand. This posts seeks to answer not only how UEFI Bootkits work generally, alongside the eccentricities of Bootkitty in particular, but also—and perhaps more importantly—how to protect oneself from these threats.

Unified Extensible Firmware Interface

To discuss UEFI Bootkits, we must first discuss both constituent parts of the name, starting with UEFI or Unified Extensible Firmware Interface. When a computer is first turned on, there needs to be a general, platform agnostic “starting point” that computers can hard-code and point to. Such a location cannot merely point to a user’s operating system, which relies on disk drivers to read the drives and their file systems, and to which the OS can be routinely changed. This intermediary step from turning on the computer to loading the OS used to be taken up by the BIOS, or Basic Input Output System, which was a firmware component soldered onto the motherboard that would provide services to tho OS—such as providing interrupt calls for IO devices, perform hardware initialization, and perform the POST or Power-On Self Test to ensure that components on the system were working properly (4).

Limitations to the BIOS, alongside being a proprietary, de facto standard, ushered in the creation of UEFI as an open firmware specification, replacing the BIOS while providing a CSM, or Compatibility Support Module, for legacy, backward compatibility (4). Rather than relying on boot sectors and MBR disk labeling, UEFI uses an explicit Boot Manager, which then uses the systems Boot Loader located on a special EFI partition on the computer, which finally starts the Operating System. By separating the various duties of the monolithic BIOS into separate parts, user and operating systems can freely change the various components, with projects like Libreboot able to replace the factory UEFI firmware with an open-source alternative (6).

UEFI uses EFI binaries, which are stored in the EFI partition, to hand off control to the Operating System. These executable use a special format, using the PE Windows Application as a base, and the EFI partition can contain binaries for the bootloader, such as the Windows Boot Manager or GRUB, or systems can skip the need for a bootloader and boot the Operating System directly by using techniques like Unified Kernel Images thanks to the flexible UEFI specification.

Secure Boot

One of the most powerful features of UEFI is that of Secure Boot. Because we have a chain of programs from power-on to loading the OS, we can build a chain of trust to only allow authorized programs to run. This is done by defining a Root of Trust, which in Secure Boot is a set of certificates that are typically burned into the computer’s firmware as immutable (Although user generated certificates can be provided).

These certificates follow a public-private scheme, where the private key is kept secret and is used for signing an executable, to which the system can verify the signature while only needing the public portion, which can be shared freely. This creates a Chain of Trust, to which every part of the boot process is attested and verified, starting with the UEFI firmware itself (As well as update packages which users flash to the firmware) and the boot manager, signed by the OEM, loader signed by the Secure Boot Authority, and finally the operating system, who can enforce their own certificates, such as Linux Kernel Modules. In coordination with the TPM, or Trusted Platform Module, systems can achieve hardware backed root of trust. (7).

Secure Boot can be enabled and disabled in the firmware, to which the former case is called Secure Boot Enforced. In this mode, any part in the boot chain that fails to match the required certificates is rejected outright. In the case of EFI binaries, such as the bootloader, the manager will simply refuse to run the executable. Bootloaders like GRUB and systemd-boot continue this chain of trust, and will evaluate the kernel images that they are supposed to run, checking them against the Secure Boot Certificate. This chain continues down such that everything from power on is signed and verified to be trusted.

Windows Secure Boot and Linux Shim

One issue with having a root of trust on private/public certificates is that a standard set of certificates are needed to prevent the user from needing to tinker with their UEFI settings (Colloquially referred to “Booting into the BIOS/Firmware”). If the Windows PE foundation didn’t reveal it already, Microsoft championed Secure Boot and UEFI, which became a hot topic after they revealed the requirements for Windows 11, and given their market dominance on the Operating System Market were able to impose their Secure Boot Certificates as the de facto default.

Most computers, especially in the wake of Windows 11 and their Secure Boot requirement, come with the Microsoft Secure Boot certificate by default. Microsoft keeps their private certificates strictly hidden, using it to sign their boot loader, and to which vendors can embed the public component in their firmware. Users can boot Windows and its Installation Medium with Secure Boot without needing any modification to their system firmware.

Rather than forcing customers to provision their computers with special Linux Secure Boot Keys, companies like Canonical (Ubuntu) and Red Hat (Fedora) use a scheme known as Chain Loading where they use a shim signed with the Microsoft Secure Boot Key (Requiring the organization’s blessing), which then boots the actual bootloader like GRUB signed with a set of their own certificates that can be installed during OS installation. The shim contains its own list of Machine Owner Keys, and if the shim detects a EFI binary that is not signed by a key in the MOK List it will automatically launch the MOK Manager which allows users to select their own keys that the shim will remember and use, independent of the firmware, but while still enforcing that the shim itself is signed by Microsoft. This allows for Secure Boot to work seamlessly on Linux without the user needing to change their firmware settings. (8)

Bootkits

A bootkit is a type of malware which targets the victims firmware or other part of the boot chain, and is one of the most serious forms of malware. By writing itself to the firmware, such as by convincing the user to flash a malicious UEFI update, Firmware Bootkits have an absolute monopoly on control of the computer, surpassing even the kernel’s privileged Ring 0. Because the malware exists in the firmware, it is the first program that is executed on power on. It can silently bypass Secure Boot (Or just install its own certificates), modify the boot loader, operating system, and any subsequent program to inject malicious code, and can inject itself into the update process such that it can persist after the user flashes a firmware update from the OEM. Because the firmware is responsible for providing device syscalls like keyboards and disks, the malware has unconstrained access to all keystrokes, and can hide itself far better than a rootkit can by modifying what information it sends back to the kernel and user-space. Coupled with the fact that UEFI supports booting from the network, a bootkit can silently communicate to a C&C server without the user or even operating system aware of the activity.

Bootkits, particularly Firmware Bootkits, are likely the most severe form of malware given its absolute power and adamant persistence, and can be used as a means of dropping other kinds of malware, like conventional bootkits or ransomware, onto an infected computer—hiding such malware from antivirus scanners (Or just disabling such protections entirely), and granting the dropped malware the ability to run at greater privilege than even the operating system itself. Secure Boot was designed chiefly to try and combat this form of malware by requiring firmware be signed by a trusted authority, but while that prevents a malicious bootkit from installing itself, if the user is already infected, such as through vulnerabilities in the firmware itself like LogoFAIL (9), it has absolute control and often the only solution is physically replacing the ROM to which the firmware has been flashed onto.

A less severe, but still dangerous bootkit is malware which targets the next stage of the boot process: the bootloader. If malware can install itself into the system’s bootloader, or replace it entirely, than the malware has similar control over the operating system as a firmware bootkit, and can freely modify parts of the OS, conceal itself from both the user and OS by filtering syscalls, and drop malware onto the system while being able to communicate with a C&C. Like Firmware Bootkits, the remedy for a Bootloader Bootkit is proper enforcement of Secure Boot, preventing unsigned code from being run; while a Firmware Bootkit can be exceeding difficult to combat, malware targeting the bootloader—excluding possible escalation attacks against the firmware—must play according the the firmware’s rules.

Bootkitty

Now that we have an understanding of both UEFI and Bootkits, we can dive into the proof-of-concept Bootkitty, and how it functions.

Bootkitty targets the boot loader, specifically the ubiquitous GRUB, and names itself /EFI/ubuntu/grubx64.efi, which the shim loader defaults to booting from, while renaming GRUB itself to /EFI/ubuntu/grubx64-real.efi (3).

From there, Bootkitty checks the status of Secure Boot. If it is enabled, then it modifies two key functions in the UEFI protocols (3):

• EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication which is used to verify EFI signatures. Bootkitty’s modification make sure to only return EFI_SUCCESS, such that all files are considered trusted.
• EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState, which is used to determine the policy that should be run in accordance to the state of the system. Bootkitty ensures that this function always returns EFI_SUCCESS so that any file can be run regardless of system policy.

With these modifications made, Secure Boot has been effectively suppressed. The Bootkit can then load GRUB into memory and begin make changes to the executable; because of the above suppression, even though modifications should invalidate the binary’s signature, they will not be checked, validated, or enforced. It then makes the following modifications to the real GRUB bootloader (Now named grubx64-real.efi) (3):

• Hooks the initial decompression of the Linux Kernel Image, such that when the kernel is unpacked it makes changes at hard-coded addresses. These re-write the kernel banner, modifies the call to the init process, and hooks the module signature checker such that kernel modules can be loaded without needing a valid Kernel (Not Secure Boot) Signature.
• Modifies the code responsible for determining if files should be verified with Secure Boot signatures, such that it immediately returns; this continues the breakdown of security chain by allowing unmodified kernel images to be loaded.

With these modifications made, Bootkitty then hands off control of to the modified GRUB, who’s now invalid signature is not checked, which decompressed the Kernel Image and makes the changes specified. Once the Kernel is given control, its modifications, which, while invalidating its signature, is also not checked, and it runs the init process which on most systems defaults to systemd, which is renamed init in the initial ram image (initramfs). The modification abuses the notorious LD_PRELOAD, which allows libraries to replace functions, such that a /opt/injector.so is pre-loaded into the init program. This allows the malware to effectively take control of the init process (3). The /opt/injector.so doesn’t actually exist, again giving credence to a proof-of-concept, but because the init process is the parent of all processes on the system a hypothetical injected library would have vast control over the system.

Impact

While Bootkitty was just a proof of concept, it reveals an alarming vector of attack on Linux Systems. What is the impact of this attack, and more importantly, how can we counter it? Unsurprisingly, the answer has been discussed numerous times already: Secure Boot.

Bootkitty must be loaded by the firmware, and without a valid signature—either in the firmware itself or the MOK if the user is using the shim—the system would refuse to load it, stopping them in their tracks. While the attackers could employ social engineering to convince the user to enroll the malware’s own keys into the MOK list, the Firmware Interface is in outside the realm of what a remote attacker can reach without existing vulnerabilities like LogoFAIL which supersede this attack entirely. It would be a difficult task.

Additionally, placing the bootkit on the EFI partition such that it will be run by the firmware requires local root privilege, again increasing the difficulty in infecting the system. If Secure Boot were disabled, and Bootkitty could exploit privilege escalation on the device, it could silently place itself on the EFI partition, replacing GRUB, and the user would be oblivious to the bootkit’s existence save for the very explicit change to the kernel banner to reveal its presence; a real bootkit would not be so forward.

So, if there is one take away from this blog, it is this: Enable Secure Boot. If you use Windows, it is no more difficult than ensuring the firmware has the setting enabled (7). If you use Linux, either use the shim, or generate and use your own keys (8).

References

1. https://www.virustotal.com/gui/file/f1f84819bdf395d42c36adb36ded0e7de338e2036e174716b5de71abc56f5d40/detection
2. https://news.itsfoss.com/bootkitty-linux/
3. https://www.welivesecurity.com/en/eset-research/bootkitty-analyzing-first-uefi-bootkit-linux/
4. https://en.wikipedia.org/wiki/BIOS
5. https://en.wikipedia.org/wiki/UEFI
6. https://libreboot.org/
7. https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot
8. https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot
9. https://www.tomshardware.com/pc-components/motherboards/logofail-exploit-bypasses-hardware-and-software-security-measures-and-is-nearly-impossible-to-detect-or-remove

Image References (In Order of Appearance):

1. https://www.welivesecurity.com/en/eset-research/bootkitty-analyzing-first-uefi-bootkit-linux/
2. https://en.wikipedia.org/wiki/UEFI
3. https://www.keyfactor.com/blog/what-is-secure-boot-its-where-iot-security-starts/
4. https://www.linux-magazine.com/Issues/2018/206/Linux-Secure-Boot-with-Shim
5. https://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/