wack0/bitlocker-attacksEine Liste öffentlicher Angriffe auf BitLocker
Eine Liste öffentlicher Angriffe auf BitLocker. Jeder öffentliche Angriff mit dem Potenzial, BitLocker anzugreifen, dessen genaue Methode aber noch nicht öffentlich ist (wie Baton Drop), wird nicht berücksichtigt.
Die meisten Angriffe betreffen den Fall, dass der VMK nur durch das TPM versiegelt ist – die Standardeinstellung – und was automatic BitLocker zusammen mit der Hinterlegung des Wiederherstellungsschlüssels bei einem Microsoft-Konto verwendet.
Standardmäßig wird ab Windows 8 die Secure-Boot-Integritätsvalidierung verwendet, wenn Secure Boot aktiviert ist.
Falls du den VMK nur durch das TPM versiegeln musst, ist die sicherste Konfiguration dafür die Verwendung der Legacy-Integritätsvalidierung mit den PCRs 0, 2, 4, 7, 11 (und außerdem solltest du dein System vollständig aktualisiert halten).
Bitte beachte, dass dies nur vor Softwareangriffen schützt.
Hardware-Angriffe sind in der Regel nur dann sinnvoll, wenn der Angreifer physischen Zugriff auf ein System hat, dessen VMK ausschließlich durch das TPM versiegelt ist.
| Zusammenfassung | Beschreibung | Behoben | Zeitraum der öffentlichen Offenlegung | Entdeckt von |
|---|---|---|---|---|
| TPM-Sniffing: bootmgr kommuniziert im Klartext mit dem TPM | Der Windows-Boot-Manager kommuniziert im Klartext mit dem TPM. Wenn also ein separater TPM-Chip auf dem LPC-Bus verwendet wird (d. h. kein fTPM oder „Pluton“/HSP), kann ein Logikanalysator an diesem Bus verwendet werden, um den VMK auszulesen. Siehe auch Blogbeitrag von Pulse Security, LPC-Sniffer-Verilog-Code. | Keine, aber Firmware-TPMs waren ohnehin nicht betroffen. | Januar 2019 | marcan |
| Hardware-Debugger: Einige Systeme nehmen keine PCR7-Messung vor, bevor ein Hardware-Debugger aktiviert wird | Die TCG-EFI-Plattformspezifikation für TPM (Abschnitt 6.4) enthält Folgendes: „Wenn die Plattform einen Firmware-Debugger-Modus bereitstellt, der vor der UEFI-Umgebung verwendet werden kann, oder wenn die Plattform einen Debugger für die UEFI-Umgebung bereitstellt, MUSS die Plattform ein EV_EFI_ACTION-Ereignis in PCR[7] extendieren, bevor die Nutzung des Debuggers erlaubt wird“ Einige Systeme führen diese Messung nicht durch, bevor sie bestimmte Hardware-Debugger (wie Intel DCI) aktivieren. Daher kann auf einem solch anfälligen System ein Secure-Boot-Bypass (bei physischem Zugriff wären mindestens zwei möglich, während Secure Boot weiterhin aktiviert ist) oder ein Hardware-Angriff (direktes Schreiben auf den SPI-Flash) verwendet werden, um den Hardware-Debugger zu aktivieren; das Setzen eines Breakpoints (beispielsweise) innerhalb von bootmgr!FvebUnsealCallback kann es dann ermöglichen, den VMK auszulesen. Siehe auch diesen Artikel der Digital Forensics Research Conference Europe 2023. | Keine für anfällige Systeme. Eine genaue Liste der anfälligen Systeme ist unbekannt. | März 2023 | Brasilianische Bundespolizei |
| fTPM-Glitching: Codeausführung per Glitching, um den fTPM-Zustand vollständig zu kompromittieren | Wenn ein auf dem SoC befindlicher Prozessor/Mikrocontroller, der ein fTPM implementiert, anfällig für Glitching ist, sodass früh im Bootvorgang Codeausführung erlangt werden kann, kann der gesamte fTPM-Zustand kompromittiert werden, was zum Auslesen des VMK führt (usw.). Siehe auch den Forschungsartikel, Payloads/usw. für AMD PSP | IntelME: November 2021 / Alder Lake AMD: unbekannt, keine? Andere (ARM64, ARMv7, usw.): unbekannt | April 2023 | Hans Niklas Jacob, Christian Werling, Robert Buhren, Jean-Pierre Seifert der Technischen Universität Berlin – SecT |
| IOMMU-Deaktivierung zur Bootzeit: Das Ändern des UEFI-Speichers für nichtflüchtige Variablen per Flash-Dump/-Rewrite kann die IOMMU beim Booten deaktivieren | Einige UEFI-Firmwares aktivieren die IOMMU beim Booten anhand von Variablendaten nicht. Durch das Dumpen des Flash, das Ändern dieser Variable(n) und das erneute Schreiben wird die IOMMU beim Booten deaktiviert, während der nichtflüchtige TPM-Zustand weiterhin gültig ist. Zu diesem Zeitpunkt kann ein Angreifer die DMAR-ACPI-Tabelle per PCI-DMA überschreiben, bevor bootmgr startet, in den abgesicherten Modus booten und dann erneut PCI-DMA verwenden, um eine SYSTEM-Shell zu erhalten. Siehe den Write-up. Es ist unbekannt, um welche Komponente es sich handelt; der Write-up verwendet ein Intel-System, der relevante Code dort wird vom Intel Firmware Support Package bereitgestellt. Es ist unbekannt, ob das AMD-Pendant (AGESA/CBS) ebenfalls betroffen ist. | Intel Firmware Support Package: unbekannt AMD AGESA/CBS: unbekannt | März 2026 | Craig S. Blackie von MDSec |
Software-Angriffe sind typischerweise Schwachstellen in bootmgr oder einer anderen Boot-Anwendung, bei denen eine Ausnutzung möglich ist, während sich abgeleitete BitLocker-Schlüssel für ein beliebiges Volume im Speicher befinden.
Wenn in einer Boot-Anwendung Codeausführung erlangt werden kann, könnte ein „Evil-Cleaner“-Angreifer ein Bootkit installieren, das selbst mit abgeleiteten Schlüsseln im Speicher läuft (oder wenn Schlüssel noch abgeleitet werden können), und so ein System kompromittieren, bei dem ein Kennwort oder ein Startschlüssel anstelle von oder zusätzlich zu einem TPM verwendet wird.
