In den letzten Jahren hat sich die UEFI-Bedrohungslandschaft, insbesondere die der UEFI-Bootkits, erheblich weiterentwickelt. Alles begann mit dem ersten UEFI-Bootkit-Proof-of-Concept (PoC), der 2012 von Andrea Allievi beschrieben wurde und als Demonstration für den Einsatz von Bootkits auf modernen UEFI-basierten Windows-Systemen diente. Dem folgten viele weitere PoCs (EfiGuard, Boot Backdoor, UEFI-bootkit). Es dauerte mehrere Jahre, bis die ersten beiden echten UEFI-Bootkits in freier Wildbahn entdeckt wurden (ESPecter, 2021 ESET; FinSpy-Bootkit, 2021 Kaspersky), und es dauerte zwei weitere Jahre, bis das berüchtigte BlackLotus - das erste UEFI-Bootkit, das UEFI Secure Boot auf aktuellen Systemen umgehen kann - auftauchte (2023, ESET).

Ein gemeinsamer Nenner dieser öffentlich bekannten Bootkits war, dass sie ausschließlich auf Windows-Systeme abzielten. Heute stellen wir unsere neueste Entdeckung vor: das erste UEFI-Bootkit, das für Linux-Systeme entwickelt wurde und von seinen Schöpfern Bootkitty genannt wird. Wir gehen davon aus, dass es sich bei diesem Bootkit lediglich um einen anfänglichen Konzeptnachweis handelt, und unseren Telemetriedaten zufolge wurde es noch nicht in der freien Wildbahn eingesetzt. Dennoch unterstreicht seine Existenz eine wichtige Botschaft: UEFI-Bootkits sind nicht mehr nur auf Windows-Systeme beschränkt.

Das Hauptziel des Bootkits besteht darin, die Signaturprüfungsfunktion des Kernels zu deaktivieren und zwei noch unbekannte ELF-Binärdateien über den Linux-Init-Prozess (den ersten Prozess, der vom Linux-Kernel beim Systemstart ausgeführt wird) vorzuladen. Während unserer Analyse entdeckten wir ein möglicherweise damit zusammenhängendes unsigniertes Kernelmodul - inklusive Anzeichen, die darauf hindeuten, dass es vom selben Autor/von denselben Autoren wie das Bootkit entwickelt worden sein könnte -, das eine ELF-Binärdatei bereitstellt, die für das Laden eines weiteren, während unserer Analyse unbekannten Kernelmoduls verantwortlich ist.

Die wichtigsten Punkte dieses Blogposts:
  • Im November 2024 wurde eine bisher unbekannte UEFI-Anwendung mit dem Namen bootkit.efi auf VirusTotal hochgeladen.
  • Unsere erste Analyse bestätigte, dass es sich um ein UEFI-Bootkit handelt, das von seinen Entwicklern Bootkitty genannt wird und überraschenderweise das erste UEFI-Bootkit ist, das auf Linux abzielt, insbesondere auf einige Ubuntu-Versionen.
  • Bootkitty ist mit einem selbstsignierten Zertifikat signiert und kann daher nicht auf Systemen mit aktiviertem UEFI Secure Boot ausgeführt werden, es sei denn, die Zertifikate des Angreifers wurden installiert.
  • Bootkitty wurde entwickelt, um den Linux-Kernel nahtlos zu booten, unabhängig davon, ob UEFI Secure Boot aktiviert ist oder nicht, da es im Speicher die notwendigen Funktionen patcht, die für die Integritätsüberprüfung verantwortlich sind, bevor GRUB ausgeführt wird.
  • bootkit.efi enthält viele Artefakte, die darauf hindeuten, dass es sich eher um einen Proof of Concept als um die Arbeit eines aktiven Bedrohungsakteurs handelt.
  • Wir entdeckten ein möglicherweise verwandtes Kernelmodul, das wir BCDropper nannten und das ein ELF-Programm bereitstellt, das für das Laden eines anderen Kernelmoduls verantwortlich ist.

Überblick über Bootkitty

Wie in der Einleitung erwähnt, enthält Bootkitty viele Artefakte, die darauf hindeuten, dass es sich um einen Proof of Concept und nicht um aktiv genutzte Malware handelt. In diesem Abschnitt werden diese Artefakte sowie weitere grundlegende Informationen über das Bootkit näher betrachtet.

Bootkitty enthält zwei ungenutzte Funktionen, die während der Ausführung spezielle Zeichenfolgen auf dem Bildschirm ausgeben können. Die erste Funktion, deren Ausgabe in Abbildung 1 zu sehen ist, kann ASCII-Zeichen ausgeben, von denen wir glauben, dass sie einen möglichen Namen des Bootkits darstellen: Bootkitty.

Figure 1. ASCII art embedded in the bootkit
Abbildung 1. In das Bootkit eingebettete ASCII-Grafik

Die zweite Funktion kann den in Abbildung 2 dargestellten Text ausgeben, der eine Liste möglicher Bootkit-Autoren und anderer Personen enthält, die vielleicht irgendwie an der Entwicklung des Bootkits beteiligt waren. Einer der im Bild genannten Namen ist auf GitHub zu finden, aber das Profil hat kein öffentliches Repository, das ein UEFI-Bootkit-Projekt enthalten oder erwähnen würde; daher können wir die Authentizität der im Bootkit genannten Namen weder bestätigen noch verneinen.

Figure 2. List of names embedded in the bootkit (redacted)
Abbildung 2. Liste der in das Bootkit eingebetteten Namen (redigiert)

Bei jedem Bootvorgang gibt Bootkitty die in Abbildung 3 dargestellten Zeichenfolgen auf dem Bildschirm aus.

Figure 3. Bootkitty’s welcome message
Abbildung 3. Bootkitty's Willkommensnachricht

Beachten Sie, dass der Name BlackCat auch in dem später beschriebenen ladbaren Kernelmodul referenziert wird. Trotz des Namens besteht unserer Meinung nach keine Verbindung zur ALPHV/BlackCat-Ransomware-Gruppe. Das liegt daran, dass BlackCat ein von Forschern verwendeter Name ist und Bootkitty in C entwickelt wurde, während sich die Gruppe ALPHV nennt und ihre Malware ausschließlich in Rust entwickelt.

Wie bereits erwähnt, unterstützt Bootkitty derzeit nur eine begrenzte Anzahl von Systemen. Der Grund dafür ist, dass Bootkitty zum Auffinden der Funktionen, die es im Speicher verändern will, hart kodierte Byte-Muster verwendet. Obwohl der Abgleich von Byte-Mustern eine gängige Technik bei Bootkits ist, haben die Autoren nicht die besten Muster verwendet, um mehrere Kernel- oder GRUB-Versionen abzudecken; daher ist das Bootkit nur für eine begrenzte Anzahl von Konfigurationen voll funktionsfähig. Was die Verwendung des Bootkits noch mehr einschränkt, ist die Art und Weise, wie es den dekomprimierten Linux-Kernel patcht: Wie in Abbildung 4 dargestellt, kopiert Bootkitty nach der Dekomprimierung des Kernel-Images einfach die bösartigen Patches an die fest kodierten Offsets innerhalb des Kernel-Images.

Figure 4. Bootkitty’s code responsible for patching the decompressed kernel before it is executed
Abbildung 4. Der Code von Bootkitty, der für das Patchen des dekomprimierten Kernels verantwortlich ist, bevor dieser ausgeführt wird

Bootkitty kann aufgrund der fehlenden Kernel-Versionsprüfungen in der in Abbildung 4 gezeigten Funktion an den Punkt gelangen , an dem es völlig zufälligen Code oder Daten an diesen hartkodierten Offsets patcht und so das System zum Absturz bringt, anstatt es zu kompromittieren. Dies ist eine der Tatsachen, die den Proof of Concept unterstützen. Andererseits könnte es sich auch um eine erste, noch nicht produktionsreife Version von Malware handeln, die von böswilligen Bedrohungsakteuren erstellt wurde.

Zu guter Letzt ist die Bootkit-Binärdatei mit dem in Abbildung 5 gezeigten selbstsignierten Zertifikat signiert.

Figure 5. Self-signed certificate used to sign the bootkit
Abbildung 5. Selbstsigniertes Zertifikat, das zur Signierung des Bootkits verwendet wird

Eine tiefergehende technische Analyse finden Sie im englischen Orginal-Blogpost.