BitLocker unter Windows 11 per Speicher-Dump umgehen
(noinitrd.github.io)- Demonstration, wie in einer Windows-11-24H2-Umgebung mit Memory-Dump-UEFI der RAM ausgelesen wird, um den FVEK (Full Volume Encryption Key) zu finden und auf ein BitLocker-geschütztes Volume zuzugreifen
- Hat ein Angreifer physischen Zugriff auf das Gerät, kann er direkt nach einem Neustart auf im RAM verbliebene Schlüssel abzielen; je länger die Stromversorgung unterbrochen ist, desto größer wird jedoch das Risiko einer Beschädigung des RAM-Inhalts
- In der Demonstration wurden die Reset-Pins des Mainboards kurzgeschlossen, um ohne Stromverlust neu zu starten; Fälle zur Umgehung von Secure Boot lagen außerhalb des Demo-Umfangs
- In Windows-11-Dumps wurde der FVEK nicht wie früher unter
FVEcbei Windows 7 oderCngbbei Windows 8.1/10 gefunden, sondern unter den TagsdFVEundNone - Auch wenn Microsoft versucht, Schlüssel über Funktionen wie
SymCryptSessionDestroyzu zerstören, können Schlüssel im Heap verbleiben; für die Analyse der BitLocker-Implementierung ist Kernel-Level-Debugging der direkteste Ansatz
Umfang der Demonstration zur Umgehung von BitLocker unter Windows 11
- Ziel ist Windows 11 Version 24H2; der Ansatz extrahiert den FVEK, den Full Volume Encryption Key von BitLocker, aus dem Speicher
- Verwendet wird die UEFI-Anwendung Memory-Dump-UEFI zum Auslesen des RAM-Inhalts
- Zentrale Voraussetzung ist, dass der Angreifer physischen Zugriff auf das Gerät hat
Bedingungen, unter denen ein RAM-Dump funktioniert
- Im RAM einer kürzlich laufenden Windows-Instanz können sensible Informationen wie der FVEK verbleiben
- Wird die Stromversorgung unterbrochen, wird der RAM-Inhalt schnell beschädigt; daher muss die Zeit, in der der Computer während des Neustarts vollständig ausgeschaltet ist, minimiert werden
- Möglichkeiten zur Reduzierung von RAM-Beschädigung sind physische Kühlung oder das Aufrechterhalten einer externen Stromversorgung; in der Demonstration wurden die Reset-Pins des Mainboards kurzgeschlossen, um ohne Stromverlust neu zu starten
- Secure Boot ist ein Sicherheitsstandard, der einschränkt, was beim Start eines Geräts ausgeführt werden kann; es gibt jedoch Fälle, in denen es etwa über shim umgangen wurde, und diese Demo behandelt das nicht im Detail
Boot-USB vorbereiten und Dump erzeugen
- Für den Boot-USB wird ein Speichermedium benötigt, das größer ist als die RAM-Kapazität des Zielsystems
- Das Skript
flashimage.shvereinfacht die Vorbereitung einer bootfähigen Anwendung - Die Schritte zum Erstellen und Verwenden der Boot-Anwendung sind in MemoryDumpUEFI dokumentiert
- Die höchste Chance, den FVEK zu finden, bestand, wenn Windows bereits geladen wurde, aber noch vor dem Erscheinen des Login-Bildschirms neu gestartet wurde
- Anschließend wird sofort vom USB-Gerät in Memory-Dump-UEFI gebootet und in der UEFI-Shell
app.efiausgeführt- Weitere Schritte zur Ausführung finden sich im README der Anwendung
- Die Dump-Dauer hängt von der RAM-Kapazität und der Geschwindigkeit des USB-Geräts ab
- Um zu vermeiden, dass auf das falsche Laufwerk geschrieben wird, sollten andere USB-Speichermedien besser getrennt werden
Dump-Dateien verarbeiten und Suchwerkzeuge
- Memory-Dump-UEFI kann mehrere Dump-Dateien erzeugen
- Um der UEFI-Spezifikation zu entsprechen, muss ein FAT32-Dateisystem verwendet werden; FAT32 hat eine Dateigrößenbegrenzung von 4 GB
concatDumpsim Verzeichnistoolsfügt mehrere Dumps in zeitlicher Reihenfolge zu einer Datei zusammen- Da der Dump aus Rohdaten besteht, die sich damals im Speicher befanden, lässt er sich mit Tools wie
xxdbesser lesbar prüfen searchMemsucht im Dump nach Hex-Mustern und ermöglicht den Sprung zu den Offsets der Fundstellen
Pool-Tags und Position des FVEK
- Ein Pool-Tag ist ein vierstelliges Kennzeichen, das anzeigt, wo sich ein Windows-Kernel-Speicherpool befindet
- Vom Windows-Kernel zugewiesene Speicherpools können gute Orte sein, um sensible Informationen zu finden
pooltag.txtenthält eine Liste von Pool-Tags sowie Informationen zu deren jeweiligem Zweck- In früheren Windows-Versionen lag der BitLocker-Schlüssel an anderen Stellen
- Unter Windows 7 konnte der Schlüssel aus dem Pool-Tag
FVEcwiederhergestellt werden, der zu Verschlüsselungszuweisungen vonfvevol.sysgehört - Unter Windows 8.1 und Windows 10 ließ sich der Schlüssel im Speicherpool mit dem Tag
Cngbfinden, der zum Modulksecdd.sysgehört
- Unter Windows 7 konnte der Schlüssel aus dem Pool-Tag
- In Windows-11-Dumps wurde der Schlüssel nicht unter
FVEcoderCngbgefunden; stattdessen wurde der FVEK an zwei Stellen entdeckt- Die erste lag unter dem Pool-Tag
dFVE, der vondumpfve.syszugewiesenen Speicher kennzeichnet dumpfve.syssteht im Zusammenhang mit dem Full Volume Encryption Crash Dump Filter von BitLocker Drive Encryption- Die
dFVE-Position war die Stelle, an der der Schlüssel am einfachsten und konsistentesten gefunden wurde - Vor dem Schlüssel an dieser Position stand
0x0480, was den Verschlüsselungstyp angibt und in der Demo-Umgebung XTS-AES-128 bedeutet - Die zweite lag unter dem Tag
None, der mit einemExAllocatePool-Aufruf zusammenhängt - An dieser Stelle war die vordere Hälfte des Schlüssels zweimal und die hintere Hälfte einmal zu sehen
- Die erste lag unter dem Pool-Tag
Mit dem FVEK auf ein BitLocker-Volume zugreifen
- Dem gewonnenen Schlüssel muss der Wert des verwendeten Verschlüsselungsalgorithmus vorangestellt werden
- Im Beispiel wird dem Schlüssel der Algorithmuswert
0x8004in Little-Endian-Form als0480vorangestellt - Der so erzeugte Wert kann in einer Datei gespeichert und etwa als
output.fvekverwendet werden - Die Tool-Sammlung dislocker wird empfohlen, um den benötigten Algorithmus und die Werte zu prüfen und eine BitLocker-geschützte Partition zu entsperren
- Wenn die Schritte korrekt sind, kann mit
output.fvekauf die Daten des BitLocker-geschützten Volumes zugegriffen werden
Analyse der BitLocker-Implementierung und im Heap verbliebene Schlüssel
- Der direkteste Weg, die BitLocker-Implementierung zu verstehen, ist Kernel-Level-Debugging mit
windbg - Kernel-Debugging lässt sich relativ einfach mit einer virtuellen Maschine oder einem crossed-over USB-3.0-A/A-Kabel durchführen
- Das schrittweise Nachverfolgen des Windows-Bootvorgangs und das Beobachten des BitLocker-Verhaltens half beim Finden des Schlüssels
- Microsoft versucht zwar, Schlüssel mit Funktionen wie
SymCryptSessionDestroyzu zerstören, doch können Schlüssel im Heap verbleiben, sodass nicht alle Schlüssel entfernt werden
Referenzlinks
- recovering-bitlocker-keys-on-windows-8-1-and-10: Material zur Wiederherstellung von BitLocker-Schlüsseln unter Windows 8.1 und Windows 10
- dislocker: Tool-Sammlung, die für den Zugriff auf BitLocker-Volumes verwendet wurde
- SymCrypt: Kryptografiebibliothek von Microsoft
- libbde: Bibliothek zu BitLocker Drive Encryption
- pooltag.txt: Liste der Windows-Pool-Tags
- An Introduction to Pool Tags: Einführung von Microsoft zu Pool-Tags
1 Kommentare
Hacker-News-Kommentare
Ich denke, BitLocker bietet den größten Vorteil, wenn man TPM (PCR 7+11)+PIN verwendet
Ohne PIN sollte sich der FVEK nicht auslesen lassen, wodurch dieser Angriff abgemildert werden kann, und wenn BitLocker korrekt implementiert ist, sollte das TPM nach zu vielen falschen PIN-Eingaben in den Dictionary-Attack-Lockout-Modus wechseln
Seit einigen Monaten versuche ich, unter Linux dieselbe Konfiguration umzusetzen, aber systemd-cryptsetup/cryptenroll ist für LUKS gedacht, und ich befinde mich in der Situation, auf langsamem eingebettetem eMMC mit fscrypt einige sensible Verzeichnisse zu verschlüsseln (Secure-Boot-Schlüssel und /home)
Sobald man über die Grundlagen hinausgeht, wirkt TPM-Programmierung extrem schwierig: an PCR 7 binden, an PCR 11 binden, das sich bei jedem Kernel-/init-/cmdline-Update ändert, eine PIN statt AuthValue verwenden, dieselbe Autorisierungsrichtlinie auch zum Zurücksetzen des DA-Lockout-Zählers beim Login nutzen und zusätzlich ein langes Passwort/AuthValue für manuelles Zurücksetzen haben, und dann noch die von systemd-stub bereitgestellte PCR-11-Signatur und den öffentlichen Schlüssel passend hinbekommen
Abgesehen von den grundlegenden TPM-Leitfäden gibt es fast kein Material, daher würde ich mich über Hilfe von jemandem freuen, der sich damit auskennt. Es ist ein persönliches Projekt, aber wenn ich es irgendwann fertig bekomme, will ich es in einem Artikel festhalten
Als Wiederherstellungsmechanismus wäre das vielleicht eine Überlegung wert
Einer der Gründe, warum nur wenige Leute als Hobby an Open-Source-TPM arbeiten, ist wohl, dass es viele Alternativen gibt, die ähnliche Bedürfnisse sehr viel einfacher lösen
Wenn man wichtige Verschlüsselungsschlüssel an Hardware binden will, kann man einfach einen Yubikey kaufen, und wenn ein Festplattenpasswort auf dem Laptop lästig ist, kann man statt eines vollständigen Herunterfahrens auch einfach beim Zuklappen den Ruhezustand verwenden
Wenn das Login-Passwort unbequem ist, gibt es Fingerabdruckleser oder Yubikeys mit biometrischer Authentifizierung, und wenn etwas wie ein unbeaufsichtigter Kiosk oder ein Schulcomputerraum ohne Passwort booten muss, kann man es in einen stabilen Metallkasten sperren und an die Wand ketten
Wenn ein Server im Rechenzentrum unbeaufsichtigt booten muss, sollte man ihn in ein Rechenzentrum mit vertrauenswürdiger physischer Sicherheit verlagern, und wenn man sich trotzdem Sorgen macht, kann man mit Dropbear oder Tang dafür sorgen, dass er nur im richtigen Netzwerk bootet
Wenn man im Homelab-Hobby gerade mit TPM herumspielt, sollte man wirklich prüfen, ob TPM-Arbeit Spaß macht, und wahrscheinlich wird man feststellen, dass das eher nicht der Fall ist
Andernfalls müsste man nicht bei jedem Entschlüsseln eines Festplattenblocks die PIN eingeben? Auch die Performance-Auswirkungen, bei jedem Festplattenzugriff das TPM aufzurufen, wären groß
Dieser Angriff liest den Schlüssel aus dem RAM, daher verstehe ich nicht, inwiefern eine TPM-PIN hier als Gegenmaßnahme hilft
Wenn man vor dem Booten ein Passwort eingibt und das Laufwerk sich nur öffnen lässt, wenn dieses Passwort mit dem TPM-Schlüssel kombiniert wird, dann hilft das in Situationen, in denen der TPM-Schlüssel später gefunden wird
Allerdings ist schwer sicher zu sagen, wie sehr irgendeine Gegenmaßnahme bei diesem Angriff hilft. Damit das OS Lese-/Schreibzugriff auf das Laufwerk behalten kann, muss es den Schlüssel irgendwo halten, sodass sich durch bloßes Verlegen des Speicherorts in den meisten Szenarien weiterhin solche RAM-Datenwiederherstellungen durchführen lassen werden
Soweit ich weiß, verlassen bei Apple-Geräten Schlüssel den sicheren Bereich (Enclave) nicht, daher dürften sie für diese Art von Angriff nicht anfällig sein. TPM 3.0 müsste offenbar deutlich näher in diese Richtung gehen
Auf ThinkPads kann man statt des Einschaltpassworts einen Fingerabdruck verwenden, und ich bevorzuge diese Konfiguration gegenüber einer BitLocker-PIN, weil das Gerät für einen Dieb dadurch fast unbenutzbar wird
Natürlich sind Einschaltpasswort und Fingerabdruckauthentifizierung auch nur so stark wie das TPM, aber gilt das nicht genauso für BitLocker TPM+PIN
Der Übergang zu TPM nach erfolgreicher Open-Source-Verschlüsselungssoftware fühlt sich seltsam an. Es wirkt, als würde man sagen: Hier ist ein ultrasicherer Speicher aus dem Hause eines Großkonzerns, also keine Sorge und keine Fragen
Ich habe den Verdacht, dass es sicher eine Hintertür geben muss, mit der Geheimdienste alle PINs und Passwörter abrufen und auf die Daten zugreifen können
Ich verstehe das Sicherheitsmodell von BitLocker grundlegend nicht wirklich.
Bei den meisten Installationen scheint es so zu sein, dass man den Power-Button drückt und Windows einfach startet.
Wenn also jemand ein Gerät mit verschlüsselter Festplatte stiehlt, muss er es dann nur einschalten? Das kann wohl nicht alles sein, aber gleichzeitig verstehe ich nicht, wie genau dieser spezielle Angriff verhindert werden soll.
Ich nehme an, man muss darauf setzen, dass der SPI-Bus-Verkehr verschlüsselt ist, sodass sich der Schlüssel nicht auf diese Weise dumpen lässt, aber wie auch immer, es sieht so aus, als gäbe die Maschine den Schlüssel ziemlich leicht preis.
LUKS hat zumindest eine Passwortabfrage zum Entsperren des Laufwerks.
Seltsamerweise verwendet Microsoft keine TPM-Parameterverschlüsselung, und deshalb baut alle 1–2 Jahre wieder ein Sicherheitsforscher ein TPM-Sniffing-Gerät als Demo.
Bei LUKS hängt es ebenfalls von der Konfiguration ab. Linux kann hier genauso wie Windows konfiguriert werden, und ich habe es auf meinem Home-Video-Sicherheitsserver auch so eingerichtet, weil er still neu starten können muss. Mir ist klar, dass das anfällig für Warm-/Cold-Boot-Angriffe und die Software-Angriffsfläche ist, aber wenn jemand nur das Laufwerk herauszieht, ist es sicher.
Auch Windows kann so konfiguriert werden, dass ein Passwort verlangt wird oder ein TPM-versiegelter Schlüssel mit PIN-Authentifizierung verwendet wird.
Wenn man Parameterverschlüsselung und das Problem mit dem Bus-Sniffing ausklammert, verschiebt BitLocker die Grenze von „jeder kann das Laufwerk lesen“ zu „man muss einen Plattformangriff durchführen, um an den Speicherinhalt zu kommen, oder einen Dienst kompromittieren, der am Anmeldebildschirm läuft“.
Situationen wie das Stehlen von Finanzdaten von beliebig wiederverwerteten Festplatten verhindert es sehr gut, daher ist es in der Praxis durchaus eine ordentliche Sicherheitsverbesserung.
Man braucht eine Umgehung wie eine Remote-Code-Execution-Schwachstelle oder das Booten eines alten, verwundbaren Windows-Bootloaders. Die häufige Umgehung „Bildschirmtastatur durch cmd.exe ersetzen“ funktioniert nicht, weil das Laufwerk gesperrt ist.
Ohne BitLocker kann man das Windows-Laufwerk in einen anderen PC stecken und alle Dateien ansehen. Mit BitLocker muss man sich mit verwundbarer Microsoft-Software, Exploits oder gedumptem Speicher herumschlagen, und selbst dann klappt es nicht immer.
Wenn BitLocker im TPM+PIN-Modus konfiguriert ist, geht selbst das nicht, weil es kein Passwort gibt, um das TPM zu öffnen. Man kann BitLocker auch im Nur-Passwort-Modus betreiben, aber das ist deutlich anfälliger für Brute-Force-Angriffe.
Bei LUKS ist es ähnlich; die meisten aktuellen Linux-Distributionen unterstützen TPM und TPM+PIN.
winlogon) praktisch nichts tun kann, wenn man nicht die Kontoanmeldedaten dieses Computers hat oder biometrisch registriert ist.Wenn man versucht, im abgesicherten Modus neu zu starten oder in ein anderes OS, ein Firmware-Update-Utility oder Ähnliches zu booten, muss man den BitLocker-Wiederherstellungsschlüssel eingeben.
Ich weiß allerdings nicht genau, wie es intern funktioniert, wenn jemand einen Fingerabdrucksensor oder eine Webcam zur Gesichtserkennung „hackt“.
Man muss dabei annehmen, dass das TPM keine Schwachstelle zur Schlüsselgewinnung hat.
Entscheidend ist der Zustand bei ausgeschaltetem Strom.
Bei allgemeiner Laufwerksverschlüsselung ist das TPM zu langsam, um die eigentlichen Massendaten zu entschlüsseln, also besitzt das OS am Ende doch einen extrahierbaren Schlüssel.
In der Pro-Edition kann man per Gruppenrichtlinie auch eine Interaktionsstufe beim Start verlangen. Es funktioniert auch ohne TPM; in diesem Fall wird bei jedem Start nach einem Passwort gefragt.
Das lässt sich durch https://trustedcomputinggroup.org/resource/pc-client-work-gr... vollständig verhindern.
Wenn das aktiviert ist, hält die Firmware vor dem nächsten Boot an und löscht den RAM, falls das OS nicht sauber heruntergefahren wurde und deshalb keine Gelegenheit hatte, die Verschlüsselungsschlüssel zu löschen.
Ich frage mich, ob Windows das nicht nutzt oder ob das getestete System es nicht implementiert hat.
Dort steht: „BitLocker verwendet TCG Reset Attack Mitigation, auch MOR bit (Memory Overwrite Request) genannt, bevor Schlüssel in den Speicher extrahiert werden.“
Allerdings traue ich den meisten Plattformimplementierungen überhaupt nicht. Ich habe noch keine UEFI-Plattform gesehen, die auch nur annähernd korrekt implementiert war, in welcher Form auch immer.
Es wäre interessant zu wissen, welche Plattform dieser Forscher verwendet hat und ob diese Plattform behauptet, MOR-bit-Unterstützung zu bieten.
Man muss sich nur ansehen, wie Team Tweezers ursprünglich die Wii angegriffen hat.
Die echte Gegenmaßnahme sind Speicherverschlüsselungs-Features moderner CPUs. Da sie im Die sitzen, kommt man mit der Pinzette nicht heran, und weil nur der Schlüssel gelöscht werden muss, geschieht das sofort; selbst wenn ein Power-Cycle überstanden wurde, ist es sehr schwer, das zu stören.
Idealerweise sollten Schlüssel nur im SRAM-Cache der CPU verbleiben und niemals den CPU-Die verlassen.
Ich bin der Autor des Beitrags. Wenn ihr Fragen habt, könnt ihr mir über dieses Konto eine Nachricht schicken.
Die Arbeit hat wirklich Spaß gemacht, und danke für das große Interesse.
38C3-Vortrag zum Umgehen von Windows 11 BitLocker: https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou...
Es ist ziemlich gut bekannt, dass BitLocker nur ausgeschaltete Computer wirklich schützt, und selbst dann nur, wenn BitLocker so konfiguriert ist, dass beim Booten ein Passwort verlangt wird
[0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...
Windows hat zusammen mit der Speicherkomprimierung auch eine vorgeschlagene Option für Speicherverschlüsselung
Sowohl Intel als auch AMD arbeiten daran, diese Funktion in ihre CPUs einzubauen
Das Ziel scheinen allerdings eher Server zu sein, auf denen mehrere virtuelle Maschinen laufen, nicht Laptops
Es wäre nicht überraschend, wenn bald verschlüsselte „virtuelle Maschinen“ als Mittel zur Aufbewahrung solcher Geheimnisse genutzt würden. Was dafür nötig ist, ist breit verfügbare Hardware-Unterstützung auf Verbraucherplattformen
Frühere CPU-Seitenkanalangriffe haben jedoch gezeigt, dass auch verschlüsselter Speicher angreifbar ist (https://www.usenix.org/conference/usenixsecurity21/presentat...). Dabei wird der Cache ausgenutzt, wenn die CPU den Speicher für den normalen Betrieb entschlüsselt
Das würde helfen, Speicher-Dumps zu vereiteln, aber verschlüsseltes RAM wird das Auslesen von Schlüsseln aus dem Speicher nicht beenden. Das gilt besonders gegenüber geduldigen oder hochqualifizierten Angreifern
https://techcommunity.microsoft.com/blog/windowsosplatform/m...
Speicherkomprimierung gibt es schon lange, mindestens seit Windows 10 RTM. Alle wichtigen Betriebssysteme haben diese Funktion implementiert, aber sie hat nichts mit Sicherheit zu tun
Verwandter Beitrag: BitLocker auf Lenovo-Laptops mit einem günstigen Logikanalysator umgehen
https://news.ycombinator.com/item?id=37249623
Bei Angriffen, die darauf beruhen, den Speicher-Dump der Zielmaschine auszulesen, frage ich mich, wie praktikabel ein Interposer-Gerät wäre, das bei physischem Zugriff die in das RAM hinein- und herausgehenden Daten kopiert oder verändert
Das erinnert mich an Geräte wie „Action Replay“ für den Gameboy, die Cheats ermöglichten, indem sie den Speicher veränderten, der von der Spielkassette ins System geladen oder dort ausgeführt wurde. Man steckte die Kassette in den Action Replay und den Action Replay in den Gameboy
Könnte man zwischen RAM und Mainboard etwas Ähnliches tun? Also das RAM in ein Gerät stecken, dieses Gerät dann ins Mainboard einsetzen und die Speicher-Lese-/Schreibvorgänge beobachten, um den Speicherzustand zu einem beliebigen Zeitpunkt festzuhalten
Damit könnte man sich das umständliche manuelle Ausschalten sparen und darauf hoffen, dass die benötigten Daten erhalten bleiben
Ich bin kein Elektrotechniker, daher ist das vielleicht ein völlig unrealistischer Vorschlag. Die Einschränkungen bei physischem Platz und Bandbreite wirken jedenfalls erheblich, aber wäre es möglich?
Es ist schwer vorstellbar, dass dafür eine Lösung von der Stange auf den Markt kommt
Nur wenige wissen, dass in den letzten Jahren erschienene Intel-/AMD-CPUs transparente Vollspeicherverschlüsselung unterstützen
Der Inhalt des RAM wird mit einem Zufallsschlüssel verschlüsselt, der im Speichercontroller der CPU gehalten und beim Reset erzeugt wird
Im BIOS ist das normalerweise deaktiviert, weil es einen kleinen Leistungsverlust beim Speicher mit sich bringt (0,1 % bis 1 %)
Dieser Angriff ließe sich damit jedoch vollständig verhindern