{"id":1053,"date":"2024-12-03T21:49:10","date_gmt":"2024-12-03T21:49:10","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=1053"},"modified":"2024-12-03T21:49:10","modified_gmt":"2024-12-03T21:49:10","slug":"first-ever-linux-uefi-bootkit-turns-out-to-be-student-project","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=1053","title":{"rendered":"First-ever Linux UEFI bootkit turns out to be student project"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

Bootkitty, a recently discovered boot-level UEFI rootkit for Linux, was evidently created by students participating in a cybersecurity training program at the South Korean Information Technology Research Institute (KITRI).<\/p>\n

The bootkit, found and analyzed by researchers<\/a> from antivirus vendor ESET last week, showed signs of being a proof of concept rather than production-ready malware. Nevertheless, the prototype, which ESET described as the first-ever UEFI bootkit for Linux, could be used as inspiration for attackers who until now have developed UEFI bootkits only for Windows, at least as far as it\u2019s publicly known.<\/p>\n

\u201cWe believe this bootkit is merely an initial proof of concept, and based on our telemetry, it has not been deployed in the wild,\u201d the ESET researchers wrote in their original report. \u201cThat said, its existence underscores an important message: UEFI bootkits are no longer confined to Windows systems alone.\u201d<\/p>\n

On Monday, ESET said it was contacted by students participating in KITRI\u2019s Best of the Best<\/a> (BoB) cybersecurity training program, who clarified that the bootkit is their creation and part of a project intended to be presented at a conference.<\/p>\n

\u201cThe primary aim of this project is to raise awareness within the security community about potential risks and to encourage proactive measures to prevent similar threats,\u201d the students reportedly said. \u201cUnfortunately, few bootkit samples were disclosed prior to the planned conference presentation.\u201d<\/p>\n

Bootkitty disables Linux kernel\u2019s signature verification<\/h2>\n

The goal of a boot-level rootkit, or bootkit, is to inject malicious code into the early stages of the computer\u2019s boot-up process before the operating system kernel is loaded. This gives malware a highly privileged position compared to any security software that might be installed on the OS because it can leverage kernel privileges to hide its files and processes during operation.<\/p>\n

One way to achieve this is to inject a malicious module into the computer\u2019s firmware, known as UEFI on modern systems or BIOS on older ones, that interferes with the normal boot chain. The protection against such attacks is the Secure Boot feature in UEFI<\/a> that cryptographically verifies the signature of all code loaded during the boot-up process.<\/p>\n

The rogue EFI module injected by the bootkit is signed with a self-generated certificate so it can\u2019t bypass Secure Boot unless the user agrees to add its certificate to the approved list. That\u2019s why after deploying the bootkit, which involves replacing the legitimate grubx64.efi bootloader, the attackers will force the computer to be rebooted, prompting the user to add their certificate to the trusted list.<\/p>\n

If the user confirms this action, the next time the system starts, a shim bootloader digitally signed by Microsoft will attempt to execute the rogue grubx64.efi injected by the attackers on the special EFI partition. GRUB is the standard bootloader for Linux systems and the attackers make a copy of the original one and its configuration under the name grubx64-real.efi to execute it later.<\/p>\n

The goal of the rogue grubx64.efi code is to check whether Secure Boot is enabled and to patch two UEFI authentication functions in memory to always return success. The goal of these functions is to check the integrity and authentication status of EFI executables.<\/p>\n

The code then loads the legitimate \/EFI\/ubuntu\/grubx64-real.efi in memory, but doesn\u2019t execute it. Instead, it hooks into the code and patches some functions responsible for verifying and loading subsequent components of the booting process, such as the Linux kernel\u2019s EFI stub binary, known as vmlinuz, which then decompresses the Linux kernel image.<\/p>\n

The code then hooks into the vmlinuz function used for decompression and patches the decompressed kernel code loaded in memory to patch the module_sig_check function, which is responsible for signature enforcement for kernel modules and other components. It also patches the first environment variable of the init process, which is the first process started on a Linux system.<\/p>\n

\u201cOn Linux systems with UEFI Secure Boot enabled, kernel modules need to be signed if they are meant to be loaded,\u201d the ESET researchers explained. \u201cThis is also the case when the kernel is built with CONFIG_MODULE_SIG_FORCE enabled or when module.sig_enforce=1 is passed as a kernel command line argument, as described in the Linux kernel documentation. The likely scenario is that at least one malicious kernel module is loaded at a later phase.\u201d<\/p>\n

The patched environment variable is LD_PRELOAD=\/opt\/injector.so, LD_PRELOAD being responsible for specifying the path of shared objects (.so) binaries. It is a common technique of injecting malicious binaries on Linux systems.<\/p>\n

Rogue kernel module<\/h2>\n

The researchers also found a malicious kernel module uploaded to VirusTotal by the same user who uploaded the bootkit. It contains similar developer strings suggesting it could be part of the same attack toolkit.<\/p>\n

This module, called BCDropper, contains a file-hiding function that hides specific entries from directory listings, namely files that include the name \u201cinjector,\u201d which happens to be in the name of the binary file listed in the patched LD_PRELOAD environment variable by Bootkitty.<\/p>\n

BCDropper also hides its entity in the kernel module list and includes the capabilities to hide files, processes and open ports. It drops another ELF binary file called \/opt\/observer that waits until the gdm3 display manager is running then loads another kernel module called \/opt\/rootkit_loader.ko. The researchers didn\u2019t manage to recover this module, so its functionality is not known.<\/p>\n

Right now, Bootkitty has some limitations and leaves various footprints on systems. It impacts only a few versions of Ubuntu Linux and only in certain configurations because it uses hardcoded byte patterns to find functions it wants to patch in memory; those patterns do not cover many kernel and GRUB versions.<\/p>\n

These limitations, however, can be corrected and the proof-of-concept bootkit could serve as a future blueprint for malicious attackers.<\/p>\n

\u201cWhether 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,\u201d the researchers said. \u201cEven 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.\u201d<\/p>\n

The ESET report includes various indicators of compromise such as file hashes for the Bootkitty and BCDropper components as well as a list of various ways to check if a system has been infected.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Bootkitty, a recently discovered boot-level UEFI rootkit for Linux, was evidently created by students participating in a cybersecurity training program at the South Korean Information Technology Research Institute (KITRI). The bootkit, found and analyzed by researchers from antivirus vendor ESET last week, showed signs of being a proof of concept rather than production-ready malware. Nevertheless, […]<\/p>\n","protected":false},"author":0,"featured_media":1054,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-1053","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/1053"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1053"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/1053\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/1054"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1053"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1053"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1053"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}