goSecurity BLOG

Wer in der IT-Security arbeitet, weiss, dass alles irgendwann zum Scheitern verurteilt ist. Sicherheitsstandards werden durch neue Technologien ausgehebelt, Stichwort Quantencomputing. Oder bei einer Lösung wurden einfach noch nicht alle Aspekte durchdacht. Bei einer BitLocker-Verschlüsselung, gestützt auf ein TPM, sind die Probleme ja schon länger bekannt. Seit einiger Zeit gibt es Wege, durch einen Hardwareangriff in Kombination mit dem Wissen, welche physischen PINs auf dem Mainboard angezapft werden müssen, an den Volume Master Key (VMK) zu gelangen. Unsere Kollegen von Orange Cyberdefense haben dazu schon einige Blogs geschrieben.

Für die Security Researcher von Neodyme AG rund um ihren CEO Thomas war dies jedoch immer noch zu aufwändig. Sie sind bei ihren Recherchen auf eine Variante gestossen, wie BitLocker geknackt werden kann, ohne auch nur eine Schraube zu lösen.

Die Schwachstelle/n

Die Sicherheitslücke entsteht beim wahrscheinlich meist eingesetzten Szenario, wenn bei einem Windows-Rechner beim Booten automatisch das mit BitLocker verschlüsselte Betriebssystemlaufwerk mittels TPM entschlüsselt wird. Dabei entschlüsselt der TPM nicht direkt das Laufwerk, sondern als erstes den Volume Master Key (VMK). Mit dem VMK wird wiederum der Full Volume Encryption Key (FVEK) entschlüsselt, welcher zur Entschlüsselung des Laufwerkes benötigt wird. In diesem Szenario kann unter bestimmten Umständen der Volume Master Key (VMK) aus dem Arbeitsspeicher ausgelesen werden, ohne dass eine Anmeldung am System benötigt wird.

Die Schwachstelle ist dabei, wie das bootende System mit dem Arbeitsspeicher umgeht, wenn ein Fehler auftritt. Normalerweise erkennt das Windows System solche Fehler und bereinigt umgehend den Arbeitsspeicher, welcher den kritischen Volume Master Key (VMK) enthält. Wenn jedoch ein Windows-Rechner mittels PXE gestartet und der Prozess im richtigen Augenblick in einen Fehler gezwungen wird, bleibt der VMK im Arbeitsspeicher. Ein Bingo aus Sicht jedes Security Researchers. Diese Schwachstelle im Bootprozess bei PXE, auch bitpixie genannt, wurde innerhalb des Bootloaders bereits im Jahr 2022 durch Microsoft erkannt und geschlossen (CVE-2023-21563).

Nun kommt die zweite Schwachstelle, getreu nach dem Moto: Ein erfolgreicher Angriff unterliegt meistens mehreren kombinierbaren Schwachstellen! Die Sicherheitslücke wurde zwar durch Microsoft in allen neueren Bootloadern geschlossen, jedoch bestimmt nicht zwingend das System, welcher Bootloader eingesetzt wird. Wenn das Betriebssystem von der Harddisk geladen wird, wird auch der Bootloader von dieser geladen. Wenn jedoch das Betriebssystem über das Netzwerk mittels PXE gestartet wird, kommt auch der Bootloader vom PXE-Server. Ein Angreifer kann also einen top aktuellen Windows-Rechner mittels PXE-Boot anweisen, einen Bootloader vor 2022 zu verwenden, bei welchem die Schwachstelle CVE-2023-21563 noch vorhanden ist.

Angreifersystem

Windows System

Das Windows System wurde im Wiederherstellungsmodus gestartet, um auf eine Konsole (CMD) zu gelangen.

In diesem Szenario gingen wir davon aus, dass ein Angreifer nicht im Besitz des Recovery Passwortes ist. Daher haben wir das Betriebssystemlaufwerk nicht entschlüsselt und auf Skip this drive geklickt.

Über die Kommandozeile wurde das lokale Netzwerkinterface gestartet und ein Netzlaufwerk (S:) für die Freigabe auf dem Angreifersystem festgelegt, von welchem danach das Script geladen wurde, um die BCD Datei zu erstellen, zu manipulieren und an das Angreifersystem zu senden.

Danach musste das Windows System in den PXE-Boot gebracht werden, in unserem Beispiel über EFI Network.

Erster Rückschlag

An diesem Punkt haben wir bei den meisten getesteten Systemen den ersten Rückschlag erlitten. Es kam zum Fehler mit dem Status: 0xc00000ba. Recherchen haben gezeigt, dass hier das System zwar den veralteten Bootloader akzeptiert hat, jedoch mit der Signatur vom shimx64.efi nicht einverstanden ist.

Das shimx64.efi wird benötigt, um danach das Alpine-Linux (Debian) zu starten, über welches der Arbeitsspeicher ausgelesen werden kann. Da das shimx64.efi nicht durch Microsoft signiert wurde, wird dies aufgrund der Secure Boot Einstellung nicht akzeptiert. Bei den entsprechenden Systemen mussten wir also im BIOS / UEFI auch 3rd Party CAs akzeptieren. Im folgenden Beispiel bei einem Lenovo.

Dieser Wechsel der BIOS / UEFI Einstellung hat bei allen betroffenen Systemen (Lenovo / HPE / Dell) dazu geführt, dass das Recovery Passwort von BitLocker eingegeben werden musste. Nachdem wir das Recovery Passwort eingegeben und das System wieder mittels PXE gestartet haben, konnten wir das Alpine-Linux (Debian) starten.

Sobald das Linux komplett geladen wurde, musste nur noch das auf dem Laufwerk liegende Script ausgeführt werden, um nach dem VMK im Arbeitsspeicher zu suchen und das Laufwerk automatisch zu verbinden.

Mit dem Zugriff auf das unverschlüsselte Betriebssystemlaufwerk können nicht nur die Daten gelesen werden, es können sogar neue lokale Benutzer angelegt werden. Mehr dazu am Ende des nächsten Kapitels “Durch Microsoft signiert“.
Dieser Ansatz hat jedoch etwas Unbefriedigendes, da wir aktiv das Recovery Passwort eingeben mussten. Auch waren bei allen unseren Systemen (Lenovo / HPE / Dell) standardmässig die 3rd Party CAs deaktiviert. Zu denken, dass dies somit ein effektiver Schutz vor bitpixie ist, wäre zu kurz gedacht. Wie bereits im Kapitel Der Angriff beschrieben, bietet das zweite Git von martanne einen Ansatz, mittels WinPE den Arbeitsspeicher auszulesen. Da dies durch Microsoft signiert ist, müssen keine 3rd Party CAs akzeptiert werden.

Durch Microsoft signiert

Nachdem beim Git von martanne die beiden Dienste SMB und PXE (TFTP) gestartet wurden, wurde das Windows System in den Wiederherstellungsmodus gebracht und vom SMB ein Script heruntergeladen und ausgeführt.

Das Script exploit-winpe1.bat erstellte die BCD Dateien, welche zum SMB-Service gesendet wurden. Danach ging es wie beim ersten Durchgang weiter, indem das Windows System mit PXE gestartet wurde. Nachdem der reguläre PXE-Boot aufgrund von beabsichtigten Fehlern in PXE-Soft-Reboot Zustand gelangte, wurde das WinPE geladen und wir erhielten wieder eine Kommandozeile.

Über diese konnte wieder das Netzwerk aktiviert und das zweite fixfertige Script exploit-winpe2.bat vom SMB-Server heruntergeladen werden. Mit diesem wurden weitere Tools vom SMB-Server geladen und direkt ausgeführt. Dabei diente die angepasste winpmem.exe im ersten Moment dazu, den Arbeitsspeicher nach dem geladenen Volume Master Key (VMK) zu durchsuchen. Die Ausgabe wurde in eine .dat-Datei geschrieben.

Danach musste mittels diskpart das Offset gefunden werden, mit welchem das verschlüsselte Betriebssystemlaufwerk gemountet werden konnte.

Als nächstes konnten die beiden Informationen, die .dat-Datei und das Offset, kombiniert werden, um mit dem Tool dislocker-metadata.exe das Recovery Passwort zu erlangen.

Im Besitz des Recovery Passwortes konnte nun alles mögliche angestellt werden. Wir haben uns beim Test dazu entschieden, mit dem Tool NTPWEdit direkt die SAM zu bearbeiten, um den deaktivierten Administratoraccount zu aktivieren und ein neues Passwort zu setzen. Dazu musste das Windows Sytem wieder im Wiederherstellungsmodus gestartet werden, nur konnte diesmal das Betriebssystemlaufwerk verbunden werden, da wir im Besitz des Recovery Passwortes waren. Selbsterklärend hätte somit ein Angreifer nicht nur Zugriff auf das verschlüsselte Laufwerk, sondern könnte sich auch noch am System anmelden, wenn auch nur mit einem lokalen Benutzer.

BitLocker darf bleiben

Pre-boot PIN

Nun steht die Frage im Raum: Kann ich mich vor dieser Angriffsart schützen? Die Antwort lautet: Ja. Der einfachste umsetzbare und dabei sehr wirkungsvolle Schutzmechanismus ist das Aktivieren der pre-boot authentication mittels eines PINs (TPM + PIN). Wird dieser gesetzt, fordert BitLocker, dass beim Booten ein PIN eingegeben wird, um den TPM zu entschlüsseln. Ohne Eingabe des PINs wird der VMK durch den TPM nicht entschlüsselt. Standardmässig wird eine PIN-Länge von mindestens sechs Ziffern vorausgesetzt, jedoch können diese (und viele weitere) Einstellungen via GPO/CSP justiert werden. Dabei kann eine PIN-Länge von minimal 4 bis maximal 20 Ziffern eingestellt werden. Mehr Informationen dazu finden Sie bei Microsoft direkt.

Natürlich ist bekannt, dass ein PIN grundsätzlich gegenüber Brute-Force Attacken anfällig ist. Um dies zu verhindern, schützt Microsoft den TPM mit anti-hammering protection. Dabei wird nach 31 Versuchen der TPM gesperrt (lockoutMax). Diese Zahl lässt sich nicht ändern. Mit anti-hammering protection ist sichergestellt, dass selbst ein sechsstelliger PIN einen starken Schutz bietet, vorausgesetzt, dieser ist nicht einfach zu erraten wie z.B. 123456 oder 666666.

Wir finden es wichtig zu erwähnen, dass eine PIN Eingabe beim Booten für die User eine weitere Hürde darstellt, welche als mühsam empfunden werden kann. Auch bei weiteren systemadministrativen Aufgaben wie z.B. der automatisierten Softwareverteilung kann der pre-boot PIN ein Hindernis darstellen. Eine Einführung des pre-boot PINs muss entsprechend gut geplant und kommuniziert werden.

Was macht Microsoft

Wie anfangs erwähnt, ist sich Microsoft dieser Thematik bewusst und stellt bereits das KB5025885-Update zu Verfügung, welches das neue Secure Boot UEFI CA 2023 Zertifikat hinzufügt, den Bootloader ersetzt und alte Zertifikate widerruft. Mehr dazu finden Sie hier KB5025885 . Dieses Update würde zwar solch einen Angriff verhindern, kann aber zu grossen Problemen führen. Zum Zeitpunkt, als dieser Blog geschrieben wurde, hat Microsoft folgende Aussage zum KB5025885-Update getroffen:

„The Enforcement Phase will not begin before January 2026, and we will give at least six months of advance warning in this article before this phase begins.“

Entsprechend hat Microsoft zurzeit dieses Update noch nicht ausgerollt. Falls Sie sich entscheiden, dieses Update einzuspielen, empfehlen wir, mit einer gründlichen Abklärungs- und Testphase zu starten.