1 Punkte von GN⁺ 2023-08-25 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn BitLocker ohne Passwort auf ein separates TPM (discrete TPM) angewiesen ist, lässt sich der Klartext-Schlüssel auf dem SPI-Bus in dem Moment abgreifen, in dem der VMK beim Booten vom TPM zur CPU übertragen wird
  • Das Experiment mit einem Lenovo L13 wurde mit einem DSLogic Plus für unter 100 US-Dollar durchgeführt, doch zum stabilen Lesen des 33-MHz-SPI-Busses waren die Sampling-Grenzen erheblich
  • Die erfassten Daten müssen in der Reihenfolge SPI → TIS → TPM 2.0 interpretiert werden; im Antwortpuffer von TPM2_Unseal findet sich ein 32-Byte-Schlüssel, der mit 5761 beginnt
  • Mit dem extrahierten Schlüssel lässt sich die BitLocker-Partition per dislocker-fuse einhängen, und durch das Ersetzen von sethc.exe durch cmd.exe erhält man nach fünfmaligem Drücken von Shift sogar eine SYSTEM-Shell
  • Ein separates TPM allein bietet keinen ausreichenden Schutz; wirksame Abwehr hängt praktisch von der Nutzung von fTPM oder der Konfiguration einer BitLocker-PIN bzw. Passphrase ab

Schwachstelle von BitLocker ohne Passwort und separatem TPM

  • Die BitLocker-Partition wird mit dem FVEK (Full Volume Encryption Key) verschlüsselt
  • Der FVEK wird wiederum mit dem VMK (Volume Master Key) verschlüsselt und zusammen mit den verschlüsselten Daten auf der Festplatte gespeichert
    • Diese Struktur ermöglicht eine Schlüsselrotation, ohne die gesamte Festplatte erneut verschlüsseln zu müssen
  • Der VMK wird im TPM gespeichert
    • Daher kann die Festplatte nur entschlüsselt werden, wenn sie auf diesem Computer gebootet wird
    • In Active Directory gibt es einen Wiederherstellungsmechanismus
  • Der verwundbare Punkt ist der Moment, in dem die CPU das TPM auffordert, den VMK für die Entschlüsselung der Festplatte zu übertragen
    • Der VMK passiert den SPI-Bus zwischen TPM und CPU im Klartext
    • Wird dieser Wert abgegriffen, kann er zur Entschlüsselung der BitLocker-Festplatte verwendet werden

Für das Mitschneiden der TPM-Kommunikation verwendete Hardware

  • Für das Experiment wurde der Logikanalysator DSLogic Plus verwendet
    • Er wurde 2021 für unter 100 US-Dollar inklusive Steuern und Versand gekauft
  • Um ein stabiles Signal zu erhalten, ist typischerweise eine Sampling-Frequenz von etwa dem 3- bis 4-Fachen der Busfrequenz nötig
    • Der Ziel-SPI-Bus lief mit 33 MHz, daher waren mindestens 100 MHz Sampling erforderlich
    • Die Spezifikation des DSLogic Plus nennt bis zu 400 MHz bei 16 Kanälen, in der Praxis gelten jedoch Einschränkungen
  • Je nach Capture-Methode und Kanalzahl zeigt der DSLogic Plus klare Grenzen
    • Je mehr Kanäle gleichzeitig aufgezeichnet werden, desto stärker sinkt die Sampling-Frequenz
    • Der Stream-Modus kann etwa eine Minute lang große Datenmengen aufzeichnen, ist aber auf 100 MHz bei 3 Kanälen begrenzt
    • Der Buffer-Modus erlaubt zwar 400 MHz Sampling, läuft jedoch nur wenige Millisekunden und ist für diese Aufgabe unpraktisch
  • Eine professionellere Option ist der etwa zehnmal teurere Saleae; weitere Geräte finden sich in der Liste von durch sigrok unterstützter Hardware

Anschluss an das Board und Timing der Aufzeichnung

  • SPI ist ein gemeinsam genutzter Bus, daher muss nicht direkt an die kleinen TPM-Pins angeschlossen werden
    • Wenn ein größeres Bauteil am selben SPI-Bus hängt, kann dort angesetzt werden
    • Im Experiment wurde ein nahegelegener SPI-Flash identifiziert und verwendet
    • Dank der Bauteilbeschriftung ließ sich das Datenblatt leicht finden und die Funktion verifizieren
  • Mit dem DSLogic wurden wegen der niedrigeren Sampling-Frequenz nur 3 der SPI-Leitungen erfasst
    • Die wichtigen Leitungen sind CLK, MOSI und MISO
  • Die Schwellspannung sollte ungefähr auf die Hälfte der Signalspannung gesetzt werden
    • Die gemessene Signalspannung betrug 3,3 V, ein geeigneter Schwellenwert lag bei etwa 1,6 V
  • Der gesuchte VMK wird erst spät in der POST-Phase verwendet
    • Beim Lenovo L13 war das direkt nach dem Splash-Screen, etwa bei Sekunde 14 eines insgesamt rund 25 Sekunden langen Bootvorgangs
    • Davor gab es ebenfalls SPI-Aktivität, jedoch überwiegend für Lese- und Prüfoperationen früher Boot-Phasen und nicht für TPM-Kommunikation
    • Die Aufzeichnung kann direkt nach dem Einschalten starten oder zur Reduktion unnötiger Daten erst etwa 7 Sekunden später

Interpretation von SPI, TIS und TPM 2.0

  • Die erfassten Signale müssen auf drei Ebenen interpretiert werden: SPI, TIS und TPM 2.0
  • SPI ist ein einfaches Protokoll und lässt sich auch mit gewöhnlichen Logikanalysatoren dekodieren
    • In dem Moment, in dem der Takt von 0 auf 1 wechselt, entspricht der Zustand der Datenleitung dem Bitwert
    • Im Beispiel ist MOSI über 8 Takte hinweg 0 und wird daher als 0x00 interpretiert; bei MISO ist nur das erste Bit gesetzt, also 0x80
  • Der schwierigste Teil war TIS (TPM Interface Specification)
    • Es ließ sich kein funktionierender Decoder finden, daher wurde dieser Teil manuell ausgewertet
    • Die libsigrok decoder konnten die Daten zwar nicht korrekt dekodieren, halfen aber dabei, den ungefähren Bereich mit TPM-Austausch zu finden
    • Das Scheitern kann daran gelegen haben, dass im Mitschnitt Chip Select fehlte, der Takt ungenau war, einige Bytes fehlten oder an anderen Ursachen
  • Die vom Master zum Slave gesendeten Anfragen zeigen ein wiederkehrendes Muster
    • Der Slave sendet 80, um Bereitschaft zu signalisieren
    • Der Master sendet den Header D4 00 24 und danach die TPM-Bytes
    • Der Slave bestätigt das Lesen mit 01 FF
  • Antworten vom Slave zum Master hängen von Registerkonfiguration und Lesevorgang ab
    • Das Beispiel-Frame ist das Ergebnis eines 1-Byte-Lesezugriffs an Adresse D4 00 24
    • Der Slave beginnt die Transaktion mit 80, danach erscheint der relevante Wert 0x80

Den Schlüssel in der TPM2_Unseal-Antwort finden

  • Der TPM-Befehl zum Abrufen des Schlüssels ist TPM2_Unseal
  • Zur Trennung der TPM-Transaktionen wurde stärker auf die Antworten auf der MISO-Leitung als auf die Request-Frames geachtet
    • In den rohen SPI-Daten wurde mit der Maske 80 00 00 00 01 .. gefiltert und nur das letzte Wildcard-Byte beibehalten
    • Der Beginn einer TPM-Transaktion lässt sich über die Header 80 01 oder 80 02 erkennen
    • Die Antwort mit dem Schlüssel ist die längere authentifizierte Antwort und beginnt mit 80 02
  • Zwischen dem Unseal-Befehl und der Antwort lag eine Verzögerung von etwa 10 ms
    • Der Header 80 02 kennzeichnet eine Passwort-Session und unterscheidet sich vom Klartext-Header 80 01, der in den meisten Requests verwendet wird
    • Die Verzögerung dürfte durch Request-Authentifizierung und HMAC-Verarbeitung in der Antwort verursacht worden sein
  • TPM-Befehle und Antworten wurden durch byteweises Rekonstruieren gewonnen
    • Zum Dekodieren wurde das Tool tpmstream-web verwendet
    • Der Schlüssel im Antwortpuffer beginnt mit 5761 und ist 32 Byte lang

Einhängen der Festplatte und Backdoor

  • Der extrahierte Schlüssel wurde in einer Datei gespeichert und anschließend an dislocker-fuse übergeben, um die BitLocker-Partition einzuhängen
  • Das Beispielkommando erstellt eine Schlüsseldatei, bindet /dev/sdd3 nach ./mnt/ ein und mountet danach dislocker-file erneut unter ./mnt2/
  • Die einfachste Backdoor besteht darin, das Sticky-Keys-Programm von Windows durch cmd.exe zu ersetzen
    • Windows/System32/cmd.exe wird nach Windows/System32/sethc.exe kopiert
    • Nachdem die Festplatte wieder in den Laptop eingesetzt und gebootet wurde, erhält man durch fünfmaliges Drücken der Shift-Taste eine SYSTEM-Shell

Grenzen der Hardware und Gegenmaßnahmen

  • Der DSLogic ist für diese Aufgabe schwer zu empfehlen
    • Viele Mitschnitte schlugen fehl und mussten verworfen werden
    • Sampling mit dem Dreifachen der Busgeschwindigkeit reichte gerade so für einen konsistenten Takt, einige Bytes gingen dennoch verloren
  • Wegen der Hardware-Grenzen war viel Zeit nötig, um das Protokoll tief zu verstehen und die Aufzeichnungen manuell auszuwerten
    • Wenn ein Arbeitgeber die Hardware bezahlt, ist ein professioneller Logikanalysator vermutlich die bessere Wahl
  • Der Einsatz eines separaten TPM erhöht die Systemsicherheit entgegen der Erwartung nicht und kann eine Illusion von Sicherheit erzeugen
  • Es gibt zwei Gegenmaßnahmen
    • fTPM verwenden
    • Falls ein separates TPM verwendet werden muss, für BitLocker eine PIN oder Passphrase setzen
  • Microsoft empfiehlt für Bereiche in Organisationen mit höherem Schutzbedarf ebenfalls eine BitLocker-PIN oder Passphrase

1 Kommentare

 
GN⁺ 2023-08-25
Meinungen auf Hacker News
  • Alle TPMs unterstützen verschlüsselte Sessions, um solche Man-in-the-Middle-Angriffe zu verhindern. Man muss TPM2_StartAuthSession verwenden und für jeden Session-Befehl Verschlüsselung angeben; dass BitLocker das nicht nutzt, ist ein gravierendes Versäumnis. Microsoft sollte das beheben.
    Zum Vergleich: systemd verwendet verschlüsselte Sessions, wenn LUKS-Disk-Verschlüsselung zusammen mit einem TPM genutzt wird: https://github.com/systemd/systemd/commit/acbb504eaf1be51572...

    • Das ist nicht einmal ein richtiger Man-in-the-Middle-Angriff, sondern eher passives Sniffing.
      Ich kenne mich mit TPM nicht gut aus, daher die Frage: Wie funktionieren authentifizierte Sessions? Wie weist das Betriebssystem dem TPM seine Identität auf eine Weise nach, die ein Angreifer bei einem echten Man-in-the-Middle-Angriff nicht fälschen kann? Ein auf der Betriebssystemseite gespeichertes Secret oder ein Schlüssel müsste doch im Klartext auf der Platte liegen, weil der Verschlüsselungsschlüssel noch nicht verfügbar ist.
      Selbst wenn das Betriebssystem irgendwie die Identität des TPM überprüft und verhindert, dass man das durch das Ändern einiger Dateien auf der Festplatte umgehen kann, ist mir unklar, was einen Angreifer daran hindert, dieselbe Routine in einem Emulator auszuführen. Ohne Integration mit einer sicheren Ausführungsumgebung auf CPU-Seite wie Intel ME oder SGX scheint dieser Ansatz kaum echte Sicherheit zu bringen; dann bräuchte man das TPM von vornherein wohl nicht.
    • Ich frage mich, ob diese Auslassung Absicht ist, und falls ja, warum.
    • Authentifizierte Sessions sind praktisch weitgehend nutzlos, wenn es sich nicht um ein vollständig integriertes Gerät handelt. Da es keine Möglichkeit gibt, die SRK-Identität zu garantieren, bleiben Man-in-the-Middle-Angriffe weiterhin möglich.
  • Es gibt auch einen anderen Artikel von 2021.
    https://arstechnica.com/gadgets/2021/08/how-to-go-from-stole...
    Einige Notebook-Hersteller bieten eine Einstellung an, die das TPM löscht, wenn das Notebook geöffnet wird. Wenn man das Notebook geöffnet hat, um zu sehen, ob man RAM nachrüsten kann, sollte man hoffen, Zugriff auf den BitLocker-Wiederherstellungsschlüssel zu haben oder ein Backup davon zu besitzen.

    • Es ist gute Praxis, irgendwo eine Kopie des Wiederherstellungsschlüssels aufzubewahren.
    • Vermutlich verlässt sich das einfach auf einen simplen Tamper-Switch-Taster und lässt sich leicht umgehen, indem man die Kunststoffrückseite aufschneidet. Ich glaube kaum, dass dort eine aufwendige Vorrichtung mit Leitungen im ganzen Gehäuse verbaut ist.
    • Ich habe noch nie gesehen, dass Chassis-Intrusion-Erkennung bei Consumer-Geräten standardmäßig aktiviert ist. Es könnte ein per Großauftrag beschafftes Gerät für ein Unternehmenskonto gewesen sein. Solche Geräte können mit den von der IT-Abteilung gewünschten Einstellungen ausgeliefert werden.
    • Meinst du den Fall, dass man die Schrauben des Notebooks löst und Zugriff auf das Innere bekommt?
      Ich denke, man könnte auch durch Aufschneiden des Kunststoffs herankommen. So ähnlich wie in der Parasiten-Extraktionsszene aus Matrix.
    • Es ist inzwischen ein Witz, dass man heutzutage kaum noch Notebooks mit aufrüstbarem RAM findet. Manche ThinkPad-Reihen fallen auch darunter; Gaming-Notebooks bieten es häufig noch.
  • Das ist nichts Neues. Die Standardeinstellung verlangt keine PIN, aber die Microsoft-Dokumentation beschreibt mehrere Angriffe und empfiehlt, eine BitLocker-PIN einzurichten, die diese vollständig verhindert. Weil das TPM Brute-Force-Versuche verhindert, darf die PIN sogar ziemlich schwach sein.
    Beispiel: https://learn.microsoft.com/en-us/windows/security/operating...

    • Interessanterweise blockiert Windows Defender meines Wissens inzwischen standardmäßig Rechteausweitungsangriffe über Barrierefreiheitsfunktionen. Behavior:Win32/AccessibilityEscalation
    • Ich hätte erwartet, dass das TPM nach X fehlgeschlagenen Versuchen das Schlüsselmaterial löscht. Ist das nicht so?
  • Bei BitLocker und dieser Art von Verschlüsselung habe ich nie verstanden, warum der Entschlüsselungsschlüssel automatisch vom System bereitgestellt wird. Welche Sicherheit bietet BitLocker, wenn das ganze Notebook gestohlen wird? Aus Sicht des Angreifers bootet das System einfach und verlangt nur das Passwort des Benutzerkontos.
    Nach meinem Verständnis schützt es meine Daten, wenn jemand die Festplatte aus dem Notebook ausbaut und versucht, sie in einem anderen System zu starten. Wegen dieses vielleicht dummen Missverständnisses habe ich BitLocker immer mit einem manuell einzugebenden Passwort konfiguriert, und bei LUKS habe ich es auch immer so gemacht. Liege ich damit völlig falsch?

    • Der Angreifer müsste die Anmeldung umgehen, den Schlüssel aus dem Systemspeicher extrahieren oder, wenn ein physisches TPM vorhanden ist, einen Angriff wie den in diesem Artikel durchführen. Das ist wahrscheinlich ein deutlich raffinierterer Angriff als der eines gewöhnlichen Diebs, der einen teuren Computer stiehlt, um schnell Geld zu machen.
      In der Regel wird er das Laufwerk wohl eher löschen und verkaufen wollen und nicht tatsächlich einen Cold-Boot-Angriff versuchen. Es hängt allerdings vollständig vom Bedrohungsmodell ab. Persönlich nutze ich Full-Disk-Encryption auf privaten Geräten vor allem, um beim Entsorgen von Speichermedien weniger auf physische Zerstörung angewiesen zu sein.
      Wenn eine Festplatte ausfällt, muss ich sie nicht wirklich auseinandernehmen, um sicherzugehen, dass meine Daten verschwunden sind. Meine Geräte sind unterwegs normalerweise im Standby; wenn also jemand einen Cold-Boot-Angriff durchführen will, könnte er das ohnehin tun.
    • Völlig falsch ist das nicht, aber du übersiehst möglicherweise das Risiko, dass der Schlüssel exportierbar wird.
      Wenn der Entschlüsselungsschlüssel, wie du sagst, automatisch an das System geliefert wird, liegt er im RAM und ist bereit, von einem Angreifer exportiert und anschließend für die verschlüsselte Platte wiederverwendet zu werden. Cold-Boot-Angriffe[1] sind ein Angriffsvektor, über den es sich zu lesen lohnt, um einzuschätzen, ob er in dein Bedrohungsmodell passt.
      [1] https://en.wikipedia.org/wiki/Cold_boot_attack
    • Windows sollte verhindern, dass irgendjemand auf Dateien zugreift, bevor das korrekte Kontopasswort eingegeben wurde. Auf diesem Computer wird die Festplatte also entschlüsselt, aber danach verhindert Windows den Zugriff.
    • Ich würde vermuten: Wenn man kein Passwort für die Festplattenverschlüsselung gesetzt hat, gibt es in diesem Szenario keinen Schutz.
  • Wenn der Schlüssel über einen gemeinsam genutzten Bus läuft, heißt das dann, dass jede Komponente im System den Schlüssel so einfach abfangen kann wie dieser Logic Analyzer? Klingt wie ein Albtraum für die Supply-Chain-Sicherheit

    • Der Zweck dieser Art von Verschlüsselung ist es, ausgebaute Festplatten ohne Datenrisiko verkaufen oder wiederverwenden zu können.
      Wenn jeder den Laptop booten und auf die entschlüsselte Festplatte zugreifen kann, welchen Unterschied macht es dann, vorher den Schlüssel zu sniffen? Wenn man den Laptop booten kann, hatte man ohnehin Zugriff auf das Endergebnis
    • Er wird zwar zwischen einigen Komponenten geteilt, aber längst nicht zwischen allen. Heutzutage hängen am SPI-Bus normalerweise nur der Boot-Flash, das TPM und die CPU selbst als Bus-Master
  • Wenn man möchte, dass BitLocker in einem Szenario schützt, in dem jemand den Laptop stiehlt, muss man ohnehin ein Passwort verwenden und den Energiesparmodus deaktivieren, wenn es kein Ruhezustand ist

    • Ersteres war bis zu diesem Artikel nicht völlig klar. Laptop-Diebstahl ist praktisch eine der schwächsten[1] Bedrohungen, bei denen Full-Disk-Encryption sinnvoll ist, und Windows hat stark damit geworben, außer dem normalen Kontopasswort nichts zu verlangen.
      Was macht die „vertrauenswürdige“ Hardware des TPM dann gerade eigentlich? Sind auch die Boot-Messungen fälschbar? Außerdem ist das absurd dumm. Warum läuft Schlüsselmaterial im Klartext über den Bus? Es gibt nicht einmal so etwas wie ein Key-Exchange-Protokoll.
      [1] Hier kommt auch Secure Erase zur Sprache; das ist zwar ein noch schwächeres Beispiel. Aber wenn Full-Disk-Encryption ein EEPROM hat, das man aus dem Sockel ziehen und physisch zerstören kann, löst das diesen Teil genauso effektiv
  • Ich frage mich, welche Software verwendet wurde, um das Rohsignal in Nullen und Einsen umzuwandeln. Ich habe schon länger ein ähnliches Projekt: digitale Daten von Kassetten aus den 80ern auszulesen. Die .wav-Datei des Bands habe ich ziemlich gut gesichert, aber ein passendes Tool oder eine Library, um sie in Nullen und Einsen zu verwandeln, habe ich noch nicht gefunden.
    Der eigentliche Spaß beginnt natürlich erst, nachdem man angefangen hat, die Nullen und Einsen zu dekodieren. Ich weiß, wie die Bits kodiert sind, nämlich per Frequenzumtastung[0]. Was ich nicht weiß: Womit dekodiere ich das in einen Bitstream, den ich weiterverarbeiten kann?
    [0] https://en.wikipedia.org/wiki/Frequency-shift_keying

    • Für das Dekodieren alter FSK-Bänder lohnt sich ein Blick auf einen Sliding-Goertzel-Filter. Das ist ein leicht zu implementierender Filter, der innerhalb eines Sliding Window die Amplitude eines bestimmten Frequenz-Bins extrahiert und in der Literatur zur DTMF-Dekodierung oft erwähnt wird.
      Indem man die Ausgaben eines solchen Filterpaars vergleicht, kann man eine digitale Ausgabe erzeugen. Man könnte auch eine sparse Sliding Discrete Fourier Transform verwenden, aber die Interpolation zwischen Frequenz-Bins ist dabei umständlicher, während der Goertzel-Filter das für einen übernimmt
    • Das ist das große Feld der digitalen Signalverarbeitung und im Kern das, was ein Modem oder der Analog-Digital-Wandler einer Soundkarte macht.
      Ich kenne keinen einzelnen Algorithmus und keine einzelne Software, die beliebige Rohsignale in Bytes umwandelt. Man muss herausfinden, welche Modulationsart das Signal verwendet, und dann den passenden Decoder finden oder selbst schreiben. Im Allgemeinen gehören Filterung und verschiedene mathematische Algorithmen dazu, aber Programme für grundlegendes Dekodieren sind meist recht kurz und einfach.
      Es ist eine ziemlich coole Fähigkeit, wenn man sie gelernt hat, weil dieselben Techniken überall einsetzbar sind. Nachdem ich zum Beispiel etwas DSP gelernt hatte, eröffnete sich mir vieles, was man in Funkkommunikation, Musik und Sounddesign, Bild- und Videoverarbeitung machen kann
    • Dem Artikel nach klingt es einfach. Wenn der Takt von Low nach High wechselt, ist der aktuelle Pegel der Datenleitung der Bitwert, und um den Startpunkt zu finden, sucht man nach einer Eins und sieben Nullen
    • Pulseview https://github.com/sigrokproject/pulseview und die anderen Teile des Sigrok-Projekts https://github.com/sigrokproject dürften einen Blick wert sein.
      Oder, da der Autor DSlogic erwähnt hat, könnte es auch Forks dieser Programme vom Hersteller dieses Logic Analyzers geben
    • Die Laderoutinen jener Zeit zählten nur die Anzahl der DC-Nulldurchgänge und wandelten X Durchgänge in 0 und Y Durchgänge in 1 um; Frequenz oder Amplitude waren ihnen egal.
      Das Rohsignal ging normalerweise durch einen Schmitt-Trigger, um Hysterese für stabile Flanken zu implementieren. Dadurch wurden die Polarität des Bandsignals und Motorschwankungen kompensiert
  • Der Teil, dass „die Verwendung eines separaten physischen TPM die Sicherheit tatsächlich verringert“, ist ironisch.
    Mein Laptop von 2015 hatte kein physisches TPM, und als ich es aktivieren wollte, hieß es: „BitLocker ohne kompatibles TPM zulassen (erfordert ein Kennwort oder einen Startschlüssel auf einem USB-Flashlaufwerk)“, sodass ich dachte, es sei weniger sicher. Zum Glück habe ich BitLocker ohnehin nicht genutzt

  • Es ist zu komisch, dass dieser Grundschul-Trick, den Namen der Eingabeaufforderung in einen Bedienungshilfen-Handler umzubenennen, immer noch genau so funktioniert wie zu Zeiten von Windows Vista.
    Man würde erwarten, dass Windows eine Authentifizierung vornimmt, wenn etwas ohne Login mit Administratorrechten ausgeführt wird, aber Windows wirkt zu 75 % wie Security Theater und die restlichen 25 % wie eine andere Art von Theater

  • 2021 wurde dieselbe Technik beschrieben:
    https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-in...