Bootkitty UEFI bootkit inserts malicious code into Linux kernel

[1.554]

Researchers from ESET have identified a new bootkit , Bootkitty, which is installed after a system is compromised instead of the GRUB bootloader and is used to substitute malicious components into the Linux kernel , which then allow the attacker to covertly control the system and perform their actions in it. It is claimed to be the first UEFI bootkit aimed at infecting Linux systems.

Bootkitty is located in the grubx64.efi file in the EFI system partition (/boot/efi/EFI/ubuntu) instead of the standard GRUB bootloader. After activation by the UEFI firmware, the bootkit loads the real GRUB2 bootloader into memory and makes changes to the GRUB2 code located in memory that disable the integrity check of components loaded in the future, and also adds a handler that is called after unpacking the Linux kernel image into memory. The specified handler modifies the kernel functions loaded into memory (disables digital signature verification of modules) and changes the initialization process launch string from "/init" to "LD_PRELOAD=/opt/injector.so /init)".

The injector.so library intercepts some SELinux operations and the init_module function, which is then used to load the /opt/dropper.ko kernel module. The dropper.ko kernel module creates and runs the /opt/observer executable, then hides itself in the list of kernel modules and exposes system call handlers such as getdents and tcp4_seq_show to hide the /opt/observer file and certain network traffic. The /opt/observer executable loads the /opt/rootkit_loader.ko kernel module, which is the /opt/rootkit rootkit loader.

The bootkit requires privileged access to the system to install, and typically these types of malware are used by attackers after successfully hacking or compromising the system to establish their presence and hide their malicious activity. The injector.so library and malicious kernel modules are placed in the initial RAM disk image or file system by the attacker. The grubx64.efi bootloader is placed in the partition with UEFI files.

In the Bootkitty variant that fell into the hands of the researchers, modifications to functions in the kernel memory were performed at pre-defined offsets without checking the correctness of these offsets for the loaded kernel version. The offsets used in Bootkitty were only applicable to the kernel and GRUB versions shipped with certain Ubuntu releases, and caused boot failures on other systems. A self-signed certificate was used to verify the Bootkitty bootloader (grubx64.efi), which prevented the bootkit from being used on systems with UEFI Secure Boot enabled without installing the attacker's certificate into the list of trusted certificates in UEFI. Such features led researchers to believe that Bootkitty was only a prototype bootkit that had not yet been used for real attacks.

After studying the information published by ESET, researchers from Binarly REsearch noticed BMP images among Bootkitty-related artifacts used to exploit the LogoFAIL vulnerability , which allows code to be executed at the UEFI firmware level and bypass the UEFI Secure Boot mechanism. In the context of Bootkitty, LogoFAIL was exploited to add a self-signed certificate of the attacker to the list of approved UEFI certificates, which certified the bootkit loader grubx64.efi, allowing the bootkit to be launched on systems with UEFI Secure Boot enabled without manually adding the certificate.

The attack is carried out by placing a specially crafted BMP image in the ESP (EFI System Partition) so that it can be displayed by the UEFI firmware as a manufacturer's logo. Due to the use of vulnerable image libraries in UEFI firmware, processing a specially crafted image can lead to a buffer overflow and code execution with the privileges of the UEFI firmware. The LogoFAIL vulnerability was identified a year ago and affected UEFI firmware used on laptops from Acer, HP, Fujitsu, and Lenovo, among others. Newer versions of UEFI firmware have fixed the issue, but many devices in use continue to run vulnerable firmware versions.

by @Nuttela

by @chatgptstore