BlackLotus UEFI Bootkit ist kein Mythos mehr

Die Anzahl der in den letzten Jahren entdeckten UEFI-Schwachstellen und die Tatsache, dass es nicht gelungen ist, sie innerhalb eines angemessenen Zeitfensters zu patchen oder anfällige Binärdateien zu widerrufen, ist mehreren Bedrohungsakteuren nicht verborgen geblieben. Infolgedessen ist das erste öffentlich bekannte UEFI-Bootkit, das die wesentliche Sicherheitsfunktion der Plattform - UEFI Secure Boot - umgeht, nun Realität. In diesem Blogpost präsentieren wir die erste öffentliche Analyse dieses UEFI-Bootkits, das sogar auf aktuellen Windows 11-Systemen mit aktiviertem UEFI Secure Boot ausgeführt werden kann. Die Funktionalität des Bootkits und seine einzelnen Merkmale lassen vermuten, dass es sich um ein Bootkit mit dem Namen BlackLotus handelt, das UEFI-Bootkit, das seit mindestens Oktober 2022 in Hackerforen für 5.000 US-Dollar verkauft wird.

UEFI-Bootkits sind sehr mächtige Bedrohungen, da sie die volle Kontrolle über den Boot-Prozess des Betriebssystems haben und somit in der Lage sind, verschiedene Sicherheitsmechanismen des Betriebssystems zu deaktivieren und ihre eigenen Nutzdaten im Kernel- oder Benutzermodus in den frühen Startphasen des Betriebssystems zu verteilen. Dadurch können sie sehr heimlich und mit hohen Privilegien operieren. Bisher wurden nur einige wenige in freier Wildbahn entdeckt und öffentlich beschrieben (z. B. mehrere bösartige EFI-Samples, die wir im Jahr 2020 entdeckt haben, oder voll funktionsfähige UEFI-Bootkits wie das von uns im letzten Jahr entdeckte ESPecter-Bootkit oder das von Forschern von Kaspersky entdeckte FinSpy-Bootkit).

UEFI-Bootkits können im Vergleich zu Firmware-Implantaten - wie LoJax, dem ersten UEFI-Firmware-Implantat in freier Wildbahn, das 2018 von unserem Team entdeckt wurde - an Heimlichkeit einbüßen, da sich Bootkits auf einer leicht zugänglichen FAT32-Festplattenpartition befinden. Wenn sie jedoch als Bootloader ausgeführt werden, haben sie fast die gleichen Möglichkeiten wie Firmware-Implantate, ohne jedoch die mehrstufigen SPI-Flash-Verteidigungsmechanismen wie die BWE-, BLE- und PRx-Schutzbits oder die von der Hardware bereitgestellten Schutzmechanismen (wie Intel Boot Guard) überwinden zu müssen. Sicherlich steht UEFI Secure Boot den UEFI-Bootkits im Weg, aber es gibt eine nicht zu vernachlässigende Anzahl von bekannten Schwachstellen, die eine Umgehung dieses wichtigen Sicherheitsmechanismus ermöglichen. Und das Schlimmste daran ist, dass einige dieser Schwachstellen selbst zum Zeitpunkt der Erstellung dieses Artikels auf aktuellen Systemen noch leicht ausgenutzt werden können - einschließlich der von BlackLotus ausgenutzten Schwachstelle.

Unsere Untersuchung begann mit einigen Treffern in unserer Telemetrie Ende 2022, die sich als BlackLotus-Benutzermoduskomponente - ein HTTP-Downloader - herausstellten. Nach einer ersten Bewertung führten uns die in den Proben gefundenen Codemuster zur Entdeckung von sechs BlackLotus-Installationsprogrammen (sowohl auf VirusTotal als auch in unserer eigenen Telemetrie). Dies ermöglichte es uns, die gesamte Ausführungskette zu untersuchen und zu erkennen, dass wir es hier nicht nur mit normaler Malware zu tun haben.

Nachfolgend finden Sie die wichtigsten Informationen über BlackLotus und eine Zeitleiste, die die Ereignisse im Zusammenhang mit BlackLotus zusammenfasst:

• Es ist in der Lage, auf den neuesten, vollständig gepatchten Windows 11-Systemen mit aktiviertem UEFI Secure Boot zu laufen.
• Er nutzt eine mehr als ein Jahr alte Sicherheitslücke (CVE-2022-21894) aus, um UEFI Secure Boot zu umgehen und Persistenz für das Bootkit einzurichten. Dies ist der erste öffentlich bekannte Missbrauch dieser Sicherheitslücke in freier Wildbahn.
• Obwohl die Schwachstelle mit dem Microsoft-Update vom Januar 2022 behoben wurde, ist ihre Ausnutzung immer noch möglich, da die betroffenen, gültig signierten Binärdateien immer noch nicht zur UEFI-Sperrliste hinzugefügt wurden. BlackLotus nutzt dies aus und bringt seine eigenen Kopien legitimer - aber anfälliger - Binärdateien auf das System, um die Schwachstelle auszunutzen.
• Er ist in der Lage, Sicherheitsmechanismen des Betriebssystems wie BitLocker, HVCI und Windows Defender zu deaktivieren.
• Nach der Installation besteht das Hauptziel des Bootkits in der Bereitstellung eines Kernel-Treibers (der unter anderem das Bootkit vor der Entfernung schützt) und eines HTTP-Downloaders, der für die Kommunikation mit dem C&C zuständig ist und zusätzliche Nutzdaten für den Benutzermodus oder den Kernel-Modus laden kann.
• BlackLotus wird mindestens seit dem 6. Oktober 2022 in Untergrundforen beworben und verkauft. In diesem Blogpost präsentieren wir Beweise dafür, dass das Bootkit echt ist und die Werbung nicht nur ein Betrug ist.
• Interessanterweise fahren einige der BlackLotus-Installationsprogramme, die wir analysiert haben, nicht mit der Bootkit-Installation fort, wenn der kompromittierte Host eines der folgenden Gebietsschemata verwendet:
  • Rumänisch (Moldawien), ro-MD
  • Russisch (Moldawien), ru-MD
  • Russisch (Russland), ru-RU
  • Ukrainisch (Ukraine) , uk-UA
  • Weißrussisch (Belarus), be-BY
  • Armenisch (Armenien), hy-AM

Die Zeitleiste der einzelnen Ereignisse im Zusammenhang mit BlackLotus ist in folgender Abbildung dargestellt.

Abbildung 1. Zeitleiste der wichtigsten Ereignisse im Zusammenhang mit dem BlackLotus UEFI-Bootkit

Wie bereits erwähnt, wird das Bootkit seit mindestens 6. Oktober^th , 2022 in Untergrundforen verkauft. Zum jetzigen Zeitpunkt konnten wir anhand unserer Telemetrie-Daten den genauen Vertriebskanal, über den das Bootkit an die Opfer verteilt wurde, nicht identifizieren. Die geringe Anzahl von BlackLotus-Samples, die wir sowohl aus öffentlichen Quellen als auch aus unseren Telemetriedaten gewinnen konnten, lässt vermuten, dass noch nicht viele Bedrohungsakteure mit dem Einsatz des Kits begonnen haben. Bis zum Widerruf der anfälligen Bootloader, von denen BlackLotus abhängt, sind wir jedoch besorgt, dass sich die Dinge schnell ändern werden, sollte dieses Bootkit in die Hände der bekannten Crimeware-Gruppen gelangen, und zwar aufgrund der einfachen Bereitstellung des Bootkits und der Fähigkeiten der Crimeware-Gruppen zur Verbreitung von Malware über ihre Botnets.

Ist das wirklich BlackLotus?

Es gibt mehrere Artikel oder Beiträge, die Informationen über BlackLotus zusammenfassen (hier, hier und hier und viele mehr...), die alle auf den Informationen des Bootkit-Entwicklers in Untergrund-Hacking-Foren basieren. Bislang hat noch niemand diese Behauptungen bestätigt oder widerlegt.

Hier ist unsere Zusammenfassung der Behauptungen aus den verfügbaren Veröffentlichungen im Vergleich zu dem, was wir beim Reverse Engineering der Bootkit-Samples entdeckt haben:

• In der Werbung von BlackLotus in Hackerforen wird behauptet, dass es eine integrierte Umgehung von Secure Boot bietet. Das Hinzufügen anfälliger Treiber zur UEFI-Sperrliste ist derzeit nicht möglich, da die Sicherheitslücke Hunderte von Bootloadern betrifft, die heute noch verwendet werden.
  • Wahr: Er nutzt CVE-2022-21894 aus, um Secure Boot zu umgehen und Persistenz auf UEFI-Secure-Boot-fähigen Systemen zu erreichen. Anfällige Treiber, die er verwendet, sind in der neuesten dbx zum Zeitpunkt der Erstellung dieses Artikels noch nicht widerrufen.
• In der Werbung von BlackLotus in Hackerforen wird behauptet, dass das Bootkit über einen eingebauten Ring0/Kernel-Schutz gegen Entfernung verfügt.
  • Wahr: Sein Kernel-Treiber schützt Handles, die zu seinen Dateien auf der EFI-Systempartition (ESP) gehören, vor dem Schließen. Als zusätzliche Schutzmaßnahme werden diese Handles kontinuierlich überwacht und ein Blue Screen Of Death (BSOD) ausgelöst, wenn eines dieser Handles geschlossen wird, wie im Abschnitt Schutz der bootkitBootkit-Dateien auf der ESP vor dem EntfernenAbschnitt beschrieben.
• In der Werbung von BlackLotus in Hackerforen wird behauptet, dass das Programm über Anti-Virtual-Machine- (Anti-VM), Anti-Debug- und Code-Verschleierungsfunktionen verfügt, um Malware-Analyseversuche zu verhindern.
  • Wahr: Es enthält verschiedene Anti-VM-, Anti-Debug- und Verschleierungstechniken, um die Replikation oder Analyse zu erschweren. Allerdings handelt es sich hier definitiv nicht um bahnbrechende oder fortgeschrittene Anti-Analyse-Techniken, da diese mit geringem Aufwand überwunden werden können.
• In der Werbung von BlackLotus in Hackerforen wird behauptet, dass der Zweck des Programms darin besteht, als HTTP-Downloader zu fungieren.
  • Wahr: Seine letzte Komponente fungiert als HTTP-Downloader, wie im Abschnitt HTTP-Downloader Abschnitt beschrieben.
• In der Werbung von BlackLotus in Hackerforen wird behauptet, dass der HTTP-Downloader unter dem SYSTEM-Konto innerhalb eines legitimen Prozesses läuft.
  • Wahr: Der HTTP-Downloader wird im Kontext des Prozesses ausgeführt.
• In der Werbung von BlackLotus in Hacking-Foren wird behauptet, dass es sich um ein winziges Bootkit mit einer Größe von nur 80 kB auf der Festplatte handelt.
  • Wahr: Die Samples, die wir erhalten konnten, sind tatsächlich rund 80 kB groß.
• In der Werbung von BlackLotus in Hackerforen wird behauptet, dass es integrierte Windows-Sicherheitsfunktionen wie HVCI, Bitlocker und Windows Defender deaktivieren und die Benutzerkontensteuerung (UAC) umgehen kann.
  • Wahr: Es kann HVCI, Windows Defender und BitLocker deaktivieren und die UAC

Aufgrund dieser Fakten glauben wir mit großer Sicherheit, dass es sich bei dem von uns entdeckten Bootkit um das BlackLotus UEFI-Bootkit handelt.

Angiffsübersicht

Ein vereinfachtes Schema der BlackLotus-Kompromisskette ist in folgender Abbildung dargestellt Abbildung 2. Sie besteht aus drei Hauptteilen:

1. Es beginnt mit der Ausführung eines Installationsprogramms (Schritt 1 in Abbildung 2), der die Dateien des Bootkits auf der EFI-Systempartition bereitstellt, HVCI und BitLocker deaktiviert und dann den Rechner neu startet.
2. Nach dem ersten Neustart erfolgt die Ausnutzung von CVE-2022-21894 und die anschließende Registrierung des Machine Owner Key (MOK) des Angreifers, um selbst auf Systemen mit aktiviertem UEFI Secure Boot eine Persistenz zu erreichen. Der Rechner wird dann neu gestartet (Schritte 2-4 in Abbildung 2) neu gestartet.
3. Bei allen nachfolgenden Bootvorgängen wird das selbstsignierte UEFI-Bootkit ausgeführt und stellt sowohl seinen Kernel-Treiber als auch die Nutzlast für den Benutzermodus, den HTTP-Downloader, bereit. Zusammen sind diese Komponenten in der Lage, zusätzliche Benutzermodus- und Treiberkomponenten vom C&C-Server herunterzuladen und auszuführen und das Bootkit vor der Entfernung zu schützen (Schritte 5-9 in Abbildung 2).

Abbildung 2. BlackLotus - vereinfachte Ausführungsübersicht

Interessante Artefakte

Obwohl wir glauben, dass es sich um das BlackLotus UEFI-Bootkit handelt, haben wir in den von uns analysierten Samples keinen Hinweis auf diesen Namen gefunden. Stattdessen ist der Code voller Verweise auf die Anime-Serie Higurashi When They Cry, zum Beispiel in einzelnen Komponentennamen wie higurashi_installer_uac_module.dll und higurashi_kernel.sys sowie im selbstsignierten Zertifikat, mit dem das Bootkit-Binary signiert wurde (siehe Abbildung 3).

Abbildung 3. Vom BlackLotus-Bootkit verwendetes selbstsigniertes Zertifikat

Außerdem entschlüsselt der Code verschiedene Zeichenketten, die Nachrichten des BlackLotus-Autors enthalten, verwendet diese aber nie (wie in Abbildung 4 - Beachten Sie, dass hasherezade eine bekannte Forscherin und Autorin verschiedener Malware-Analyse-Tools ist), oder einfach nur einige zufällige Zitate aus verschiedenen Liedern, Spielen oder Serien.

Abbildung 4. Beispiel für Nachrichten, die der BlackLotus-Autor im Code hinterlassen hat

Installationsprozess

Wir beginnen mit der Analyse der BlackLotus-Installationsprogramme. Das Bootkit scheint in Form von Installationsprogrammen verbreitet zu werden, die es in zwei Versionen gibt - offline und online. Der Unterschied zwischen diesen beiden liegt in der Art und Weise, wie sie legitime (aber anfällige) Windows-Binärdateien erhalten, die später zur Umgehung von Secure Boot verwendet werden.

• Bei Offline-Versionen sind die Windows-Binärdateien in das Installationsprogramm eingebettet.
• In den Online-Versionen werden die Windows-Binärdateien direkt aus dem Microsoft Symbols Store heruntergeladen. Bislang haben wir gesehen, dass die folgenden Windows-Binärdateien vom BlackLotus-Bootkit missbraucht werden:
  • https://msdl.microsoft.com/download/symbols/bootmgfw.efi/7144BCD31C0000/bootmgfw.efi
  • https://msdl.microsoft.com/download/symbols/bootmgr.efi/98B063A61BC000/bootmgr.efi
  • https://msdl.microsoft.com/download/symbols/hvloader.efi/559F396411D000/hvloader.efi

Das Ziel des Installationsprogramms ist klar: Es ist für die Deaktivierung von Windows-Sicherheitsfunktionen wie BitLocker-Festplattenverschlüsselung und HVCI sowie für die Bereitstellung mehrerer Dateien, einschließlich des bösartigen Bootkits, auf dem ESP verantwortlich. Sobald er fertig ist, startet er den kompromittierten Computer neu, damit die abgelegten Dateien ihre Arbeit tun können - um sicherzustellen, dass das selbstsignierte UEFI-Bootkit bei jedem Systemstart unbemerkt ausgeführt wird, unabhängig vom UEFI Secure Boot-Schutzstatus.

Schritt 0 – Initialisierung und (potentielle) Rechteausweitung

Wenn das Installationsprogramm ausgeführt wird, prüft es, ob es über ausreichende Rechte verfügt (mindestens Administratorrechte erforderlich), um den Rest der Dateien auf dem ESP zu installieren und andere Aktionen durchzuführen, die einen erweiterten Prozess erfordern - wie das Deaktivieren von HVCI oder BitLocker. Wenn dies nicht der Fall ist, versucht er, die Berechtigungen zu erhöhen, indem er das Installationsprogramm erneut ausführt und dabei die hier ausführlich beschriebene Methode zur Umgehung der Benutzerkontensteuerung verwendet: UAC-Umgehung über den Programmkompatibilitätsassistenten.

Mit den erforderlichen Rechten fährt es fort und prüft den UEFI Secure Boot-Status, indem es den Wert der UEFI-Variablen SecureBoot mit einer verfügbaren Windows-API-Funktion liest und die Windows-Version durch direkten Zugriff auf die Felder der Struktur KUSER_SHARED_DATA NtMajorVersion und NtMinorVersion im Speicher bestimmt. Auf diese Weise wird entschieden, ob die Umgehung von UEFI Secure Boot notwendig ist, um das Bootkit auf dem System des Opfers bereitzustellen (da die Secure Boot-Unterstützung erst in Windows 8 hinzugefügt wurde und auf einem bestimmten Computer möglicherweise nicht aktiviert ist).

Bevor es mit den nächsten Schritten fortfährt, benennt es die legitime Windows Boot Manager (bootmgfw.efi) Binärdatei im Verzeichnis ESP:\EFI\Microsoft\Boot\ in winload.efi um. Dieses umbenannte bootmgfw.efi-Backup wird später vom Bootkit verwendet, um das Betriebssystem zu starten oder die ursprüngliche Bootkette wiederherzustellen, wenn der Befehl "Deinstallieren" vom C&C-Server empfangen wird - mehr dazu im Abschnitt C&C-Kommunikation.

Schritt 1 – Dateien verteilen

Wenn UEFI Secure Boot aktiviert ist, legt das Installationsprogramm mehrere Dateien in den Verzeichnissen ESP:/EFI/Microsoft/Boot/ und ESP:/system32/ ab. Während das erste Verzeichnis ein von Windows verwendetes Standardverzeichnis ist, ist das zweite ein vom Installationsprogramm erstellter benutzerdefinierter Ordner.

Eine Liste der vom Installationsprogramm abgelegten Dateien mit einer kurzen Erläuterung der Rolle jeder Datei in der Ausführungskette finden Sie in Tabelle 1. Die Funktionsweise der Ausführungskette wird später im Detail erläutert; jetzt sei nur darauf hingewiesen, dass neben den bösartigen Dateien auch einige legitime, von Microsoft signierte Dateien abgelegt werden.

Tabelle 1. Vom BlackLotus-Installationsprogramm auf Systemen mit aktiviertem UEFI Secure Boot bereitgestellte Dateien

In Fällen, in denen das Opfer eine Windows-Version verwendet, die UEFI Secure Boot nicht unterstützt, oder in denen es deaktiviert ist, ist die Bereitstellung recht einfach. Das Einzige, was für die Bereitstellung des bösartigen Bootkits erforderlich ist, ist das Ersetzen der vorhandenen Windows-Bootmanager-Binärdatei (bootmgfw.efi) im Verzeichnis ESP:\EFI\Microsoft\Boot\ durch die eigene selbstsignierte bösartige UEFI-Anwendung der Angreifer. Da UEFI Secure Boot deaktiviert ist (und somit während des Bootens keine Integritätsprüfung durchgeführt wird), ist eine Ausnutzung nicht erforderlich, und die UEFI-Firmware führt den bösartigen Bootmanager einfach aus, ohne Sicherheitsverletzungen zu verursachen.

Schritt 2 - Deaktivieren von Hypervisor-geschütztem Code-Integritätsschutz (HVCI)

Um später benutzerdefinierten, unsignierten Kernelcode ausführen zu können, muss das Installationsprogramm sicherstellen, dass HVCI auf dem System deaktiviert ist. Einer unserer ESET-Kollegen hat im Jahr 2022 einen sehr informativen Blogpost zu diesem Thema geschrieben (Signierte Kernel-Treiber - Unbewachter Zugang zum Windows-Kern):

Virtualisierungsbasierte Sicherheit (VBS) bietet mehrere Schutzfunktionen, von denen die bekannteste Hypervisor-Protected Code Integrity (HVCI) ist, die auch als eigenständige Funktion angeboten wird. HVCI erzwingt Code-Integrität im Kernel und erlaubt nur die Ausführung von signiertem Code. Es verhindert effektiv, dass anfällige Treiber missbraucht werden, um unsignierten Kernelcode auszuführen oder bösartige Treiber zu laden (unabhängig von der verwendeten Ausbeutungsmethode). Es scheint, dass Malware, die anfällige Treiber zum Laden von bösartigem Code missbraucht, eine der Hauptmotivationen für die Implementierung dieser Funktion durch Microsoft war.

Wie in Abbildung 5 dargestellt, setzt das Installationsprogramm den Registrierungswert Enabled unter dem Registrierungsschlüssel HypervisorEnforcedCodeIntegrity auf Null, um diese Funktion zu deaktivieren.

Abbildung 5. Hex-Rays dekompilierter Code der Funktion des BlackLotus-Installationsprogramms, die für die Deaktivierung von HVCI verantwortlich ist

Schritt 3 - Deaktivieren von BitLocker

Die nächste Funktion, die vom Installationsprogramm deaktiviert wird, ist BitLocker Drive Encryption. Der Grund dafür ist, dass BitLocker in Kombination mit dem Trusted Platform Module (TPM) verwendet werden kann, um sicherzustellen, dass verschiedene Startdateien und Konfigurationen, einschließlich Secure Boot, nicht manipuliert wurden, seit die BitLocker-Laufwerksverschlüsselung auf dem System konfiguriert wurde. In Anbetracht der Tatsache, dass das Installationsprogramm die Windows-Bootkette auf einem kompromittierten Computer ändert, würde das Beibehalten von BitLocker bei Systemen mit TPM-Unterstützung beim nächsten Start zu einem BitLocker-Wiederherstellungsbildschirm führen und das Opfer darauf hinweisen, dass das System kompromittiert wurde.

Um diesen Schutz zu deaktivieren, muss das BlackLotus-Installationsprogramm folgendes tun:

• durchläuft alle Volumes im WMI-Namensraum Root\CIMV2\Security\MicrosoftVolumeEncryption und überprüft ihren Schutzstatus durch Aufruf der Methode GetProtectionStatus der WMI-Klasse Win32_EncryptableVolume
• für die durch BitLocker geschützten Schlüssel wird die Methode DisableKeyProtectors mit dem Parameter DisableCount auf Null gesetzt, was bedeutet, dass der Schutz ausgesetzt wird, bis er manuell aktiviert wird

Nachdem die erforderlichen Schutzmaßnahmen deaktiviert und alle Dateien bereitgestellt wurden, registriert sich das Installationsprogramm, um beim nächsten Systemneustart gelöscht zu werden, und startet den Rechner neu, um mit der Ausnutzung von CVE-2022-21894 fortzufahren.

Umgehung von Secure Boot und Herstellung von Persistenz

In diesem Teil sehen wir uns genauer an, wie BlackLotus die Persistenz auf Systemen mit aktiviertem UEFI Secure Boot erreicht. Da die Ausführungskette, die wir beschreiben werden, recht komplex ist, werden wir zunächst die grundlegenden Prinzipien erklären und dann tiefer in die technischen Details einsteigen.

Kurz gesagt, besteht dieser Prozess aus zwei wichtigen Schritten:

1. Ausnutzung von CVE-2022-21894 zur Umgehung der Secure Boot-Funktion und Installation des Bootkits. Dies ermöglicht die Ausführung von beliebigem Code in frühen Boot-Phasen, in denen die Plattform noch im Besitz der Firmware ist und die Funktionen der UEFI-Boot-Dienste noch verfügbar sind. Dadurch können Angreifer viele Dinge tun, die auf einem Rechner mit aktiviertem UEFI Secure Boot nicht möglich sein sollten, ohne physischen Zugriff darauf zu haben, wie z. B. das Ändern von NVRAM-Variablen, die nur für Boot-Services bestimmt sind. Und genau das machen sich Angreifer zunutze, um im nächsten Schritt die Persistenz des Bootkits einzurichten. Weitere Informationen zur Ausnutzung finden Sie im Abschnitt "Ausnutzen von CVE-2022-21894".
2. Einstellung der Persistenz durch Schreiben eines eigenen MOK in die NVRAM-Variable MokList, die nur für Boot-Dienste gilt. Auf diese Weise kann er ein legitimes, von Microsoft signiertes Shim zum Laden seines selbstsignierten (mit dem privaten Schlüssel, der zu dem in MokList geschriebenen Schlüssel gehört, signierten) UEFI-Bootkits verwenden, anstatt die Sicherheitslücke bei jedem Start auszunutzen. Mehr dazu im Abschnitt "BootkitBootkit-Beständigkeit".

Um die detaillierte Analyse in den nächsten beiden Abschnitten zu erleichtern, folgen wir den im Ausführungsdiagramm dargestellten Schritten in Abbildung 6.

Abbildung 6. Umgehen von Secure Boot und Einrichten der Persistenz mit MOK

Ausnutzung von CVE-2022-21894

Zur Umgehung von Secure Boot verwendet BlackLotus den Baton Drop (CVE-2022-21894): Umgehung der Sicherheitsfunktion von Secure Boot. Trotz ihrer großen Auswirkungen auf die Systemsicherheit hat diese Sicherheitslücke nicht so viel öffentliche Aufmerksamkeit erhalten, wie sie verdient hätte. Obwohl die Schwachstelle im Microsoft-Update vom Januar 2022 behoben wurde, ist ihre Ausnutzung immer noch möglich, da die betroffenen Binärdateien noch immer nicht zur UEFI-Sperrliste hinzugefügt wurden. Infolgedessen können Angreifer ihre eigenen Kopien anfälliger Binärdateien auf die Rechner ihrer Opfer bringen, um diese Sicherheitslücke auszunutzen und Secure Boot auf aktuellen UEFI-Systemen zu umgehen.

Außerdem ist seit August 2022 ein Proof of Concept (PoC) für diese Schwachstelle öffentlich verfügbar. In Anbetracht des Datums des ersten BlackLotus VirusTotal Eintrags (siehe Abbildung 1), hat der Malware-Entwickler das verfügbare PoC wahrscheinlich nur an seine Bedürfnisse angepasst, ohne dass er die Funktionsweise dieses Exploits genau verstanden hätte.

Beginnen wir mit einer kurzen Einführung in die Schwachstelle, wobei wir die wichtigsten Punkte aus dem Bericht zusammenfassen, der zusammen mit dem PoC auf GitHub veröffentlicht wurde:

• Betroffene Windows-Boot-Anwendungen (wie bootmgr.efi, hvloader.efi, winload.efi...) ermöglichen das Entfernen einer serialisierten Secure Boot-Richtlinie aus dem Speicher - bevor sie von der Anwendung geladen wird - durch Verwendung der BCD-Boot-Option truncatememory.
• Dies ermöglicht es Angreifern, andere gefährliche BCD-Optionen wie bootdebug, testsigning oder nointegritychecks zu verwenden und damit Secure Boot zu umgehen.
• Es gibt verschiedene Möglichkeiten, diese Sicherheitslücke auszunutzen - drei davon sind im PoC-Repository veröffentlicht.
• So zeigt einer der PoCs, wie er ausgenutzt werden kann, um das legitime hvloader.efi dazu zu bringen, eine beliebige, selbstsignierte mcupdate_<platform>.dll-Binärdatei zu laden (wobei <platform> je nach CPU des Rechners GenuineIntel oder AuthenticAMD sein kann).

Wir fahren nun damit fort, zu beschreiben, wie BlackLotus diese Schwachstelle ausnutzt (die Zahlen in der folgenden Liste beschreiben die entsprechenden Schritte in Abbildung 6):

1. Nachdem das Installationsprogramm den Rechner neu gestartet hat, fährt die UEFI-Firmware mit dem Laden einer ersten Boot-Option fort. Bei Windows-Systemen ist die erste Boot-Option standardmäßig bootmgfw.efi, die sich im Ordner ESP:/EFI/Microsoft/Boot auf dem ESP befindet. Diesmal führt die Firmware statt der ursprünglichen bootmgfw.efi des Opfers (die zuvor vom Installationsprogramm in winload.efi umbenannt wurde) die verwundbare Option aus, die vom Installationsprogramm bereitgestellt wurde.
2. Nach der Ausführung werden die BCD-Bootoptionen geladen, die zuvor vom Installationsprogramm geändert wurden. Abbildung 7 zeigt einen Vergleich zwischen der legitimen BCD und der modifizierten BCD.
3. Wie Sie in Abbildung 7 (Pfad grün unterstrichen), würde der legitime Windows Boot Manager normalerweise den Windows OS Loader (\WINDOWS\system32\winload.efi) als Standard-Boot-Anwendung laden. Mit der modifizierten BCD fährt er jedoch mit dem Laden der anfälligen ESP:\system32\bootmgr.efi fort, wobei das BCD-Element avoidlowmemory auf den Wert 0x10000000 gesetzt ist und das BCD-Element custom:22000023 auf eine andere BCD des Angreifers verweist, die in ESP:\system32\bcd gespeichert ist. Die Erklärung für die Verwendung dieser Elemente ist im veröffentlichten PoC zu finden:

Der Angreifer muss sicherstellen, dass die serialisierte Secure Boot Policy über eine bekannte physikalische Adresse zugewiesen wird.

[…]

Das Element avoidlowmemory kann verwendet werden, um sicherzustellen, dass alle Zuweisungen von physischem Speicher über einer bestimmten physischen Adresse liegen.

• Seit Windows 10 ist dieses Element nicht mehr zulässig, wenn VBS aktiviert ist. Da es jedoch während der Initialisierung der Boot-Anwendung verwendet wird, bevor die serialisierte Secure-Boot-Richtlinie aus dem Speicher gelesen wird, kann dies umgangen werden, indem bootmgr geladen und ein benutzerdefinierter BCD-Pfad angegeben wird (mit dem Element bcdfilepath aka custom:22000023).

Abbildung 7. Legitimer BCD-Speicher (VORHER) im Vergleich zu dem vom BlackLotus-Installationsprogramm verwendeten (NACHHER)

4. Im nächsten Schritt lädt das ausgeführte ESP:\system32\bootmgr.efi die zusätzliche BCD, die sich in ESP:\system32\bcd befindet. Der geparste Inhalt dieser zusätzlichen BCD wird in Abbildung 8 gezeigt.

Abbildung 8. Zweiter BCD, der vom BlackLotus-Installationsprogramm abgeworfen wird - verwendet, um CVE-2022-21894 auszunutzen

5. Aufgrund der aus der BCD-Datei geladenen Optionen, die in Abbildung 8 gezeigt werden, fährt bootmgr.efi mit dem Laden einer anderen anfälligen Windows-Boot-Anwendung fort, die vom Installationsprogramm bereitgestellt wird - ESP:\system32\hvloader.efi - bei der es sich um den Windows Hypervisor Loader handelt. Noch wichtiger ist, dass zusätzliche BCD-Optionen in derselben BCD-Datei angegeben sind (siehe Abbildung 8):
   1. truncatememory mit Wert auf 0x10000000 gesetzt
   2. nointegritychecks auf Yes gesetzt
   3. und testsigning auch auf Yes

Und genau hier passiert die Magie. Da die serialisierte Secure Boot-Policy in physikalische Adressen oberhalb von 0x10000000 geladen werden sollte (wegen avoidlowmemory, das in den vorherigen Schritten verwendet wurde), wird die Angabe des Elements truncatememory es effektiv entfernen - und damit den Secure Boot unterbrechen und die Verwendung gefährlicher BCD-Optionen wie nointegritychecks oder testsigning ermöglichen. Durch die Verwendung dieser Optionen können die Angreifer die hvloader.efi dazu bringen, ihren eigenen, selbstsignierten Code auszuführen.

6. Dazu wird derselbe Trick wie im PoC beschrieben angewandt: Während seiner Ausführung lädt das legitime hvloader.efi die native Binärdatei mcupdate_{GenuineIntel| AuthenticAMD}.dll aus dem Verzeichnis <Device>:\<SystemRoot>\system32\. Kommentierter Hex-Rays dekompilierter Code der Funktion aus hvloader.efi, die für das Laden dieser mcupdate*.dll-Binärdatei verantwortlich ist, wird in Abbildung 9 gezeigt. Beachten Sie, dass hvloader.efi diese legitime mcupdate*.dll-Binärdatei normalerweise aus dem Verzeichnis <OS_partition>:\Windows\system32 laden würde, aber dieses Mal wird die selbstsignierte mcupdate*.dll der Angreifer aus einem benutzerdefinierten ESP-Verzeichnis ausgeführt, das zuvor vom Installationsprogramm erstellt wurde (ESP:\system32). Dies wird durch die BCD-Optionen device und systemroot verursacht, die in der BCD von Abbildung 8 die das aktuelle Gerät als Boot-Gerät angeben - also den ESP - und außerdem SystemRoot als das Root-Verzeichnis (\) auf diesem Gerät angeben.

Abbildung 9. Hex-Rays Dekompilierung der Funktion BtLoadUpdateDll aus der legitimen Datei hvloader.efi, die für das Laden von mcupdate_*.dll verantwortlich ist

7. Jetzt, da die selbstsignierte mcupdate*.dll des Angreifers geladen und ausgeführt wird, fährt er mit der Ausführung der letzten Komponente in dieser Kette fort - einem eingebetteten MokInstaller (UEFI-Anwendung) - siehe Abbildung 10 für Details zur Vorgehensweise.

Abbildung 10. Hex-Rays dekompilierter Code der bösartigen, selbstsignierten Binärdatei mcupdate*.dll

Bootkit-Persistenz

Nun kann der MokInstaller mit der Einrichtung der Persistenz fortfahren, indem er das MOK des Angreifers in die NVRAM-Variable einträgt und das legitime, von Microsoft signierte shim-Binary als Standard-Bootloader einrichtet. Bevor wir zu den Details kommen, noch eine kleine Theorie zu shim und MOK.

shim ist ein UEFI-Bootloader der ersten Stufe, der von Linux-Entwicklern entwickelt wurde, damit verschiedene Linux-Distributionen mit UEFI Secure Boot funktionieren. Es handelt sich um eine einfache Anwendung, deren Zweck es ist, eine andere Anwendung zu laden, zu überprüfen und auszuführen - im Falle von Linux-Systemen ist dies normalerweise der GRUB-Bootloader. Es funktioniert so, dass Microsoft nur einen Shim signiert und der Shim sich um den Rest kümmert - er kann die Integrität eines Second-Stage-Bootloaders mit Hilfe von Schlüsseln aus der db UEFI-Variable überprüfen und bettet auch seine eigene Liste von "erlaubten" oder "widerrufenen" Schlüsseln oder Hashes ein, um sicherzustellen, dass Komponenten, denen beide Seiten - Plattform und Shim-Entwickler (z. B. Canonical, RedHat usw.) - vertrauen, ausgeführt werden dürfen. Zusätzlich zu diesen Listen erlaubt shim auch die Verwendung einer externen Schlüsseldatenbank, die vom Benutzer verwaltet wird und als MOK-Liste bekannt ist. Abbildung 11 veranschaulicht sehr schön, wie UEFI Secure Boot mit MOK funktioniert.

Diese MOK-Datenbank ist in einer reinen Boot-NVRAM-Variable namens MokList gespeichert. Ohne Ausnutzung einer Schwachstelle wie der oben beschriebenen ist physischer Zugriff erforderlich, um sie auf einem System mit aktiviertem UEFI Secure Boot zu ändern (sie ist nur während des Bootens verfügbar, bevor der Betriebssystemlader die UEFI Boot Services-Funktion ExitBootServices aufruft). Durch Ausnutzung dieser Schwachstelle sind Angreifer jedoch in der Lage, UEFI Secure Boot zu umgehen und ihren eigenen selbstsignierten Code vor dem Aufruf von ExitBootServices auszuführen, so dass sie leicht ihren eigenen Schlüssel registrieren können (indem sie die MokList-NVRAM-Variable ändern), um den Shim dazu zu bringen, eine beliebige - mit diesem registrierten Schlüssel signierte - Anwendung auszuführen, ohne eine Sicherheitsverletzung zu verursachen.

Abbildung 11. Übersicht über den MOK-Boot-Prozess (Bildquelle)

8. Weiter geht es mit der Beschreibung des Flusses von Abbildung 6 - Schritt 8... Die MokInstaller UEFI-Anwendung fährt mit der Einrichtung der Persistenz für das BlackLotus UEFI-Bootkit fort und verwischt die Spuren der Ausnutzung durch:
   1. Wiederherstellung des ursprünglichen BCD-Speichers des Vicitm aus dem vom Installationsprogramm erstellten Backup und Ersetzen der Datei bootmgfw.efi durch das legitime, von Microsoft signierte Shim, das zuvor vom Installationsprogramm in ESP:\system32\bootload.efi abgelegt wurde.
   2. Erstellen einer MokList-NVRAM-Variable, die das selbstsignierte öffentliche Schlüsselzertifikat des Angreifers enthält. Beachten Sie, dass diese Variable genauso formatiert ist wie alle anderen UEFI-Signaturdatenbankvariablen (z. B. db oder dbx) und aus null oder mehr Signaturlisten des Typs EFI_SIGNATURE_LIST bestehen kann - wie in der UEFI-Spezifikation definiert.
   3. Löschen aller an der Ausnutzung beteiligten Dateien aus dem ESP:\system32\-Ordner des Angreifers.
9. Am Ende wird der Rechner neu gestartet, damit das eingesetzte Shim das selbstsignierte Bootkit ausführt, das vom Installationsprogramm in \EFI\Microsoft\Boot\grubx64.efi abgelegt wurde (grubx64.efi ist normalerweise der Standard-Bootloader der zweiten Stufe, der von einem Shim auf x86-64-Systemen ausgeführt wird).

Der Code, der die in den letzten beiden Schritten beschriebenen Aktionen ausführt, ist in Abbildung 12.

Abbildung 12. Hex-Rays dekompilierter Code - MokInstaller UEFI-App zum Einrichten der Persistenz für das BlackLotus-Bootkit

BlackLotus UEFI Bootkit

Sobald die Persistenz konfiguriert ist, wird das BlackLotus-Bootkit bei jedem Systemstart ausgeführt. Ziel des Bootkits ist es, einen Kernel-Treiber und eine letzte Komponente für den Benutzermodus - den HTTP-Downloader - zu installieren. Während seiner Ausführung versucht es, zusätzliche Windows-Sicherheitsfunktionen - Virtualization-Based Security (VBS) und Windows Defender - zu deaktivieren, um die Wahrscheinlichkeit einer erfolgreichen Bereitstellung und eines unbemerkten Betriebs zu erhöhen. Bevor wir auf die Details eingehen, fassen wir zunächst die Grundlagen des Kernel-Treibers und des HTTP-Downloaders zusammen:

• Der Kernel-Treiber ist zuständig für
  • Bereitstellung der nächsten Komponente der Kette - eines HTTP-Downloaders.
  • Aufrechterhaltung des Ladevorgangs im Falle eines Abbruchs.
  • Schutz der Bootkit-Dateien vor dem Entfernen aus dem ESP.
  • Ausführung zusätzlicher Kernel-Payloads, wenn der HTTP-Downloader dies anordnet.
  • Deinstallation des Bootkits, wenn der HTTP-Downloader dies anweist.
• Der HTTP-Downloader ist verantwortlich für:
  • Kommunikation mit seinem C&C.
  • Ausführen von Befehlen, die vom C&C empfangen wurden.
  • Herunterladen und Ausführen von Payloads, die vom C&C empfangen wurden (unterstützt sowohl Kernel-Payloads als auch User-Mode-Payloads).

Der vollständige Ausführungsablauf (vereinfacht), vom Installationsprogramm bis zum HTTP-Downloader, ist in Abbildung 13 dargestellt. Diese einzelnen Schritte werden im nächsten Abschnitt ausführlicher beschrieben.

Abbildung 13. Diagramm zur Ausführung des BlackLotus UEFI-Bootkits

BlackLotus Ausführungsablauf

Die Ausführungsschritte sind wie folgt (siehe auch Abbildung 13):

1. Als ersten Schritt führt die UEFI-Firmware die Standard-Windows-Boot-Option aus, die normalerweise in der Datei \EFI\Microsoft\Boot\bootmgfw.efi gespeichert ist. Wie wir bereits beschrieben haben ("BootkitBootkit-Persistenz" Abschnitt, 8.a), hat die MokInstaller-Binärdatei diese Datei durch ein legitimes signiertes Shim ersetzt.
2. Wenn das Shim ausgeführt wird, liest es die MokList-NVRAM-Variable und verwendet das zuvor von den Angreifern darin gespeicherte Zertifikat, um den Bootloader der zweiten Stufe zu überprüfen - das selbstsignierte BlackLotus UEFI-Bootkit, das sich in \EFI\Microsoft\Boot\grubx64.efi befindet.
3. Nach der Überprüfung führt das Shim das Bootkit aus.
4. Das Bootkit beginnt mit der Erstellung der Boot-only VbsPolicyDisable NVRAM-Variable. Wie in e beschrieben, wird diese Variable vom Windows OS-Lader während des Bootens ausgewertet. Wenn sie definiert ist, werden die wichtigsten VBS-Funktionen, wie HVCI und Credential Guard, nicht initialisiert.
5. In den folgenden Schritten (5. a-e) folgt das Bootkit einem üblichen Muster, das von UEFI-Bootkits verwendet wird. Es fängt die Ausführung von Komponenten ab, die zum typischen Windows-Bootablauf gehören, wie Windows Boot Manager, Windows OS Loader und Windows OS Kernel, und hakt einige ihrer Funktionen im Speicher ab. Als Bonus versucht er auch, Windows Defender zu deaktivieren, indem er einige seiner Treiber patcht. All dies, um die Ausführung seiner Nutzlast in den frühen Phasen des Betriebssystem-Startvorgangs zu erreichen und eine Entdeckung zu vermeiden. Die folgenden Funktionen werden gehooked oder gepatcht:
   1. ImgArchStartBootApplication in bootmgfw.efi oder bootmgr.efi:
      Diese Funktion wird häufig von Bootkits verwendet, um den Moment abzufangen, in dem der Windows OS Loader (winload.efi) zwar in den Speicher geladen, aber noch nicht ausgeführt wurde - der richtige Moment, um weitere speicherinterne Patches durchzuführen.
   2. BlImgAllocateImageBuffer in winload.efi:
      Wird verwendet, um einen zusätzlichen Speicherpuffer für den bösartigen Kernel-Treiber zuzuweisen.
   3. OslArchTransferToKernel in winload.efi:
      Dieser Hook fängt den Moment ab, in dem der OS-Kernel und einige der Systemtreiber bereits in den Speicher geladen, aber noch nicht ausgeführt wurden - ein perfekter Moment, um weitere Patches im Speicher auszuführen. Die unten genannten Treiber werden in diesem Hook gepatcht. Der Code dieses Hooks, der für die Suche nach geeigneten Treibern im Speicher verantwortlich ist, wird in Abbildung 14.
   4. WdBoot.sys und WdFilter.sys:
      BlackLotus ändert den Einstiegspunkt von WdBoot.sys und WdFilter.sys - dem Windows Defender ELAM-Treiber bzw. dem Windows Defender Dateisystem-Filtertreiber - so, dass er sofort zurückkehrt.
   5. disk.sys:
      Das Bootkit hakt den Einstiegspunkt des disk.sys-Treibers ein, um den BlackLotus-Kernel-Treiber in den frühen Phasen der Systeminitialisierung auszuführen.

Abbildung 14. Hex-Rays dekompilierter Code des OslArchTransferToKernel-Hooks - Patchen der Windows Defender-Treiber und Suche nach dem disk.sys-Einstiegspunkt

6. Wenn dann der Betriebssystemkern den Einstiegspunkt des disk.sys-Treibers ausführt, springt der installierte Hook zum Einstiegspunkt des bösartigen Kernel-Treibers. Der bösartige Code stellt seinerseits die ursprüngliche disk.sys wieder her, damit das System ordnungsgemäß funktioniert, und wartet, bis der Prozess winlogon.exe startet.
7. Wenn der bösartige Treiber erkennt, dass der Prozess winlogon.exe gestartet wurde, injiziert er die letzte Komponente des Benutzermodus - den HTTP-Downloader - in diesen und führt sie aus.

Kernel-Treiber

Der Kernel-Treiber ist für vier Hauptaufgaben zuständig:

• Injizieren des HTTP-Downloaders in winlogon.exe und erneutes Injizieren, falls der Thread abbricht.
• Schutz der auf dem ESP bereitgestellten Bootkit-Dateien vor dem Entfernen.
• Entschärfen des Windows Defender-Prozesses MsMpEngine.exe im Benutzermodus.
• Kommunikation mit dem HTTP-Downloader und ggf. Ausführung von Befehlen.

Schauen wir sie uns nacheinander an.

Persistenz des HTTP-Downloaders

Der Kernel-Treiber ist für die Bereitstellung des HTTP-Downloaders verantwortlich. Wenn der Treiber startet, wartet er, bis der Prozess winlogon.exe startet, bevor er weitere Aktionen durchführt. Sobald der Prozess gestartet ist, entschlüsselt der Treiber das HTTP-Downloader-Binary, injiziert es in den Adressraum von winlogon.exe und führt es in einem neuen Thread aus. Anschließend überprüft der Treiber in regelmäßigen Abständen, ob der Thread noch läuft, und wiederholt die Injektion, falls erforderlich. Der HTTP-Downloader wird nicht ausgeführt, wenn der Treiber einen Kernel-Debugger erkennt.

Schutz der Bootkit-Dateien auf dem ESP vor Entfernung

Um die Dateien des Bootkits auf dem ESP zu schützen, verwendet der Kernel-Treiber einen einfachen Trick. Er öffnet alle zu schützenden Dateien, dupliziert und speichert ihre Handles und verwendet die Kernel-Funktion ObSetHandleAttributes, indem er das Flag ProtectFromClose im Parameter HandleFlags (OBJECT_HANDLE_FLAG_INFORMATION) auf 1 setzt - und damit die Handles vor dem Schließen durch andere Prozesse schützt. Dadurch werden alle Versuche, die geschützten Dateien zu entfernen oder zu ändern, vereitelt. Die folgenden Dateien sind geschützt:

• ESP:\EFI\Microsoft\Boot\winload.efi
• ESP:\EFI\Microsoft\Boot\bootmgfw.efi
• ESP:\EFI\Microsoft\Boot\grubx64.efi

Sollte ein Benutzer versuchen, diese geschützten Dateien zu löschen, wird etwas angezeigt, wie es in Abbildung 15 gezeigt wird.

Abbildung 15. Versuch, die vom BlackLotus-Treiber geschützten Dateien zu löschen

Als weitere Schutzmaßnahme für den Fall, dass der Benutzer oder eine Sicherheitssoftware das Schutzflag aufheben und die Handles schließen könnte, überwacht der Kernel-Treiber diese kontinuierlich und löst einen BSOD aus, indem er die Funktion KeBugCheck(INVALID_KERNEL_HANDLE) aufruft, wenn eines der Handles nicht mehr existiert.

Entschärfen des Hauptprozesses von Windows Defender

Der Kernel-Treiber versucht auch, den Hauptprozess von Windows Defender - MsMpEng.exe - zu deaktivieren. Er tut dies, indem er allen Prozessen die Token-Privilegien entzieht, indem er das Attribut SE_PRIVILEGE_REMOVED für jeden von ihnen setzt. Infolgedessen sollte der Defender-Prozess nicht in der Lage sein, seine Aufgaben - wie das Scannen von Dateien - ordnungsgemäß auszuführen. Da diese Funktion jedoch schlecht implementiert ist, kann sie durch einen Neustart des Prozesses MsMpEng.exe unwirksam gemacht werden.

Kommunikation mit dem HTTP-Downloader

Der Kernel-Treiber ist in der Lage, mit dem HTTP-Downloader zu kommunizieren, indem er ein benanntes Ereignis und einen Abschnitt verwendet. Die Namen der verwendeten benannten Objekte werden auf der Grundlage der MAC-Adresse des Netzwerkadapters des Opfers (Ethernet) generiert. Wenn der Wert eines Oktetts kleiner als 16 ist, wird 16 dazu addiert. Das Format der generierten Objektnamen kann in verschiedenen Beispielen variieren. In einem der analysierten Beispiele lauten die generierten Namen für die MAC-Adresse 00-1c-0b-cd-ef-34 beispielsweise wie folgt:

• \BaseNamedObjects\101c1b: für den benannten Abschnitt (nur die ersten drei Oktette der MAC werden verwendet)
• \BaseNamedObjects\Z01c1b: für das benannte Ereignis - wie für den Abschnitt, aber die erste Ziffer der MAC-Adresse wird durch Z ersetzt

Falls der HTTP-Downloader einen Befehl an den Kernel-Treiber weitergeben möchte, erstellt er einfach einen benannten Abschnitt, schreibt einen Befehl mit zugehörigen Daten hinein und wartet auf die Verarbeitung des Befehls durch den Treiber, indem er ein benanntes Ereignis erstellt und wartet, bis der Treiber es auslöst (oder signalisiert).

Der Treiber unterstützt die folgenden selbsterklärenden Befehle:

• Install kernel driver
• Uninstall BlackLotus

Ein aufmerksamer Leser wird hier die Schwachstelle von BlackLotus bemerken - obwohl das Bootkit seine Komponenten vor dem Entfernen schützt, kann der Kernel-Treiber dazu gebracht werden, das Bootkit vollständig zu deinstallieren, indem er die oben genannten Objekte erstellt und den Deinstallationsbefehl an ihn sendet.

HTTP-Downloader

Die letzte Komponente ist für die Kommunikation mit einem C&C-Server und die Ausführung der von ihm empfangenen C&C-Befehle zuständig. Alle Payloads, die wir entdecken konnten, enthalten drei Befehle. Diese Befehle sind sehr einfach und wie der Name des Abschnitts vermuten lässt, geht es hauptsächlich um das Herunterladen und Ausführen zusätzlicher Nutzdaten mit verschiedenen Techniken.

C&C-Kommunication

Zur Kommunikation mit seinem C&C verwendet der HTTP-Loader das HTTPS-Protokoll. Alle für die Kommunikation erforderlichen Informationen sind direkt in die Downloader-Binärdatei eingebettet - einschließlich der C&C-Domänen und der verwendeten HTTP-Ressourcenpfade. Das Standardintervall für die Kommunikation mit einem C&C-Server ist auf eine Minute eingestellt, kann aber auf der Grundlage der Daten des C&C geändert werden. Jede Kommunikationssitzung mit einem C&C beginnt mit dem Senden einer Beacon-HTTP-POST-Nachricht an diesen. In den von uns analysierten Beispielen können die folgenden HTTP-Ressourcenpfade in den HTTP-POST-Headern angegeben werden:

• /network/API/hpb_gate[.]php
• /API/hpb_gate[.]php
• /gate[.]php
• /hpb_gate[.]php

Den Daten der Beacon-Nachricht wird eine checkin=-Zeichenkette vorangestellt, die grundlegende Informationen über den kompromittierten Computer enthält, darunter eine benutzerdefinierte Maschinenkennung (HWID), den UEFI Secure Boot-Status, verschiedene Hardware-Informationen und einen Wert, der eine BlackLotus-Build-Nummer zu sein scheint. Die HWID wird aus der MAC-Adresse des Rechners (Ethernet) und einer Seriennummer des Systemvolumens generiert. Das Format der Nachricht vor der Verschlüsselung ist wie in Abbildung 16 gezeigt.

{
    "HWID":"%s", 
    "Session":"%lu", 
    "Owner":"%s", 
    "IP":"%s", 
    "OS":"%s", 
    "Edition":"%s", 
    "CPU":"%s", 
    "GPU":"%s", 
    "RAM":"%lu", 
    "Integrity":"%lu", 
    "SecureBoot":"%i", 
    "Build":"%lu"
}

Abbildung 16. Format der Beacon-Nachricht

Bevor die Nachricht an den C&C gesendet wird, werden die Daten zunächst mit einem eingebetteten RSA-Schlüssel verschlüsselt und dann URL-sicher in Base64 codiert. Während der Analyse fanden wir zwei verschiedene RSA-Schlüssel, die in den Beispielen verwendet wurden. Ein Beispiel für eine solche HTTP-Beacon-Anfrage ist in Abbildung 17.

Abbildung 17. Beispiel einer Beacon-HTTP-POST-Nachricht (generiert von einem Sample aus VirusTotal - demjenigen mit lokalen IPs anstelle von echten C&C-Adressen)

Die vom C&C als Antwort auf die Beacon-Nachricht empfangenen Daten sollten mit dem zwei Byte langen magischen Wert HP beginnen; andernfalls wird die Antwort nicht weiter verarbeitet. Wenn der magische Wert korrekt ist, werden die auf den magischen Wert folgenden Daten mit 256-Bit-AES im CBC-Modus entschlüsselt, wobei die oben genannte HWID-Zeichenfolge als Schlüssel verwendet wird.

Nach der Entschlüsselung ist die Nachricht ähnlich wie der Beacon eine JSON-formatierte Zeichenkette und enthält eine Befehlskennung (Typ) und verschiedene zusätzliche Parameter wie z. B.:

• C&C-Kommunikationsintervall
• Zu verwendende Ausführungsmethode
• Payload Dateiname
• Payload basierend auf der Dateierweiterung (unterstützt werden .sys, .exe oder .dll)
• Authentifizierungstoken, mit dem der Download von Payload-Daten angefordert werden soll
• AES-Schlüssel, der für die Entschlüsselung der Payload-Daten verwendet wird

Alle unterstützten Befehle und ihre Beschreibungen sind in Tabelle 2 aufgeführt.

Tabelle 2. C&C-Befehle

In diesen Befehlen kann der C&C-Server angeben, ob die Payload zuerst auf der Festplatte abgelegt werden soll, bevor sie ausgeführt wird, oder ob sie direkt im Speicher ausgeführt werden soll. In Fällen, in denen die Datei auf der Festplatte abgelegt wird, wird der Ordner ProgramData auf dem Betriebssystemvolume als Zielordner verwendet, und Dateiname und Erweiterung werden vom C&C-Server angegeben. Im Falle der direkten Ausführung von Dateien im Speicher wird svchost.exe als Injektionsziel verwendet. Wenn der C&C-Server einen Befehl sendet, der die Zusammenarbeit mit dem Kernel-Treiber erfordert, oder wenn ein Anwender Code im Kernel-Modus ausführen möchte, wird der im Abschnitt "Kommunikation mit dem HTTP-Downloader" beschriebenen Mechanismus verwendet.

Anti-Analyse Tricks

Um die Erkennung und Analyse dieser Malware zu erschweren, hat ihr Autor versucht, die Sichtbarkeit von Standard-Dateiartefakten wie Textstrings, Importe oder andere unverschlüsselte eingebettete Daten auf ein Minimum zu beschränken. Im Folgenden finden Sie eine Zusammenfassung der verwendeten Techniken.

• String- und Datenverschlüsselung
  • Alle in den Beispielen verwendeten Zeichenfolgen werden mit einer einfachen Chiffre verschlüsselt.
  • Alle eingebetteten Dateien werden mit 256-Bit-AES im CBC-Modus verschlüsselt.
  • Die Verschlüsselungsschlüssel für einzelne Dateien können von Probe zu Probe variieren.
• Laufzeitabhängige API-Auflösung
  • In allen Beispielen (sofern zutreffend) werden Windows-APIs immer ausschließlich während der Laufzeit aufgelöst, und es werden Funktionshashes anstelle von Funktionsnamen verwendet, um die gewünschten API-Funktionsadressen im Speicher zu finden.
  • In einigen Fällen wird ein direkter Syscall-Befehl verwendet, um die gewünschte Systemfunktion aufzurufen.
• Netzwerkkommunikation
  • Kommuniziert über HTTPS.
  • Alle vom HTTP-Downloader an den C&C gesendeten Nachrichten werden mit einem eingebetteten öffentlichen RSA-Schlüssel verschlüsselt.
  • Alle vom C&C an den HTTP-Downloader gesendeten Nachrichten werden mit einem Schlüssel verschlüsselt, der aus der Rechnerumgebung des Opfers abgeleitet wird, oder mit einem vom C&C bereitgestellten AES-Schlüssel.
• Anti-Debug- und Anti-VM-Tricks - falls verwendet, in der Regel direkt am Anfang des Einstiegspunkts. Es werden nur gelegentlich Sandbox- oder Debugger-Erkennungstricks verwendet.

Vorbeugung und Gegenmaßnahmen

• Zuallererst ist es natürlich ein Muss, Ihr System und sein Sicherheitsprodukt auf dem neuesten Stand zu halten - um die Chance zu erhöhen, dass eine Bedrohung gleich zu Beginn gestoppt wird, bevor sie in der Lage ist, Pre-OS-Persistenz zu erreichen.
• Der wichtigste Schritt, der unternommen werden muss, um die Verwendung bekannter anfälliger UEFI-Binärdateien zur Umgehung von UEFI Secure Boot zu verhindern, ist ihr Widerruf in der UEFI-Sperrdatenbank (dbx) - auf Windows-Systemen sollten dbx-Updates über Windows Updates verteilt werden.
• Das Problem ist, dass die Sperrung von weit verbreiteten Windows UEFI-Binärdateien dazu führen kann, dass Tausende von veralteten Systemen, Wiederherstellungsimages oder Backups nicht mehr gebootet werden können - und deshalb dauert die Sperrung oft zu lange.
• Beachten Sie, dass ein Widerruf der von BlackLotus verwendeten Windows-Anwendungen die Installation des Bootkits verhindern würde. Da das Installationsprogramm jedoch den Bootloader des Opfers durch den widerrufenen Bootloader ersetzen würde, könnte das System dadurch nicht mehr gestartet werden. In diesem Fall würde eine Neuinstallation des Betriebssystems oder eine einfache ESP-Wiederherstellung das Problem beheben.
• Wenn der Widerruf erfolgt, nachdem die BlackLotus-Persistenz hergestellt wurde, würde das Bootkit funktionsfähig bleiben, da es ein legitimes Shim mit einem benutzerdefinierten MOK-Schlüssel für die Persistenz verwendet. In diesem Fall bestünde die sicherste Lösung darin, Windows neu zu installieren und den vom Angreifer registrierten MOK-Schlüssel mit dem Dienstprogramm mokutil zu entfernen (aufgrund der notwendigen Benutzerinteraktion mit dem MOK-Manager während des Bootens ist zur Durchführung dieses Vorgangs physische Anwesenheit erforderlich).

Fazit

In den letzten Jahren wurden viele kritische Schwachstellen entdeckt, die die Sicherheit von UEFI-Systemen beeinträchtigen. Leider sind aufgrund der Komplexität des gesamten UEFI-Ökosystems und der damit verbundenen Probleme in der Lieferkette viele dieser Schwachstellen auch noch lange nach der Behebung der Schwachstellen - oder zumindest nachdem uns gesagt wurde, dass sie behoben wurden - auf vielen Systemen zu finden. Zur besseren Veranschaulichung finden Sie hier einige Beispiele für Patches oder Widerrufe, die die Umgehung von UEFI Secure Boot ermöglichen, nur aus dem letzten Jahr:

• Zuallererst natürlich CVE-2022-21894 - die von BlackLotus ausgenutzte Sicherheitslücke. Ein Jahr, nachdem die Schwachstelle behoben wurde, werden anfällige UEFI-Binärdateien immer noch nicht widerrufen, was es Bedrohungen wie BlackLotus ermöglicht, heimlich auf Systemen mit aktiviertem UEFI Secure Boot zu operieren und den Opfern so ein falsches Gefühl von Sicherheit zu vermitteln.
• Anfang 2022 haben wir mehrere UEFI-Schwachstellen bekannt gegeben, die unter anderem die Deaktivierung von UEFI Secure Boot ermöglichen. Viele der betroffenen Geräte werden von den OEMs nicht mehr unterstützt und sind daher nicht behoben (obwohl diese Geräte noch nicht so alt waren - etwa 3-5 Jahre zum Zeitpunkt der Veröffentlichung der Schwachstelle). Lesen Sie mehr in unserem Blogpost: Verwundbare UEFI Backdoors in Lenovo Laptops entdeckt
• Später, im Jahr 2022, entdeckten wir einige andere UEFI-Schwachstellen, deren Ausnutzung es Angreifern ebenfalls ermöglichen würde, UEFI Secure Boot sehr einfach zu deaktivieren. Wie die Forscherkollegen von Binarly feststellten, wurden mehrere in der Empfehlung aufgeführte Geräte auch noch einige Monate nach der Empfehlung nicht oder nicht korrekt gepatcht, so dass die Geräte anfällig blieben. Unnötig zu sagen, dass, ähnlich wie im vorherigen Fall, einige Geräte für immer verwundbar bleiben werden, da sie ihr End-Of-Support-Datum erreicht haben.

Es war nur eine Frage der Zeit, bis jemand diese Fehler ausnutzen und ein UEFI-Bootkit entwickeln würde, das auf Systemen mit aktiviertem UEFI Secure Boot funktioniert. Wie wir letztes Jahr in unserer RSA-Präsentation angedeutet haben, macht all dies den Wechsel zum ESP für Angreifer praktikabler und zu einem möglichen Weg nach vorne für UEFI-Bedrohungen - die Existenz von BlackLotus bestätigt dies.

IoCs

Files

Certificates

Network

MITRE ATT&CK techniques

This table was built using version 12 of the MITRE ATT&CK framework.