baton drop (CVE-2022-21894): Sicherheitsfunktions-Bypass-Schwachstelle von Secure Boot

Windows-Startanwendungen erlauben es, mit der Einstellung truncatememory Speicherblöcke zu entfernen, die „persistente“ Bereiche serialisierter Daten aus der Speicherkarte enthalten, was zu einem Secure-Boot-Bypass führt.

• Das BCD-Element truncatememory entfernt den gesamten Speicher oberhalb einer angegebenen physischen Adresse aus der Speicherkarte.
• Dies wird für jede Startanwendung während der Initialisierung durchgeführt, bevor die serialisierte Secure-Boot-Richtlinie aus dem Speicher gelesen wird.
• Daher kann ein solches Element verwendet werden, um die serialisierte Secure-Boot-Richtlinie aus der Speicherkarte zu entfernen.
• Dadurch können gefährliche Einstellungen in einer Startanwendung verwendet werden (bootdebug, testsigning, nointegritychecks), wodurch Secure Boot gebrochen wird.

Dieses Problem wurde durch zwei verschiedene Änderungen behoben:

• Nach dem Versuch, eine serialisierte Secure-Boot-Richtlinie zu laden, schlägt die Initialisierung der Startanwendung fehl, wenn keine Richtlinie geladen wurde, Secure Boot aktiviert ist, die Startanwendung nicht direkt von der UEFI-Firmware geladen wurde und die Startanwendung nicht bootmgr ist.
• Beim Laden einer Startanwendung schlägt das Laden fehl, wenn sie eine VERSIONINFO-Ressource mit einem OriginalFilename enthält und dieser Dateiname in einer Blockliste enthalten ist (die bootmgr.exe und hvloader.exe enthält; in Nickel wurde hvloader.efi hinzugefügt, aber dies wurde nicht zurückportiert).
  • In Windows 8 und Windows 8.1 ist hvloader.exe nicht in der Blockliste von winload enthalten – ursprünglich war es enthalten, was das Hyper-V-Laden brach!
  • Seit Windows 10 Version 1809 muss der OriginalFilename zwingend bootmgr.exe sein, wenn ein bestimmtes Flags-Bit gesetzt ist (das mit dem Element flightedbootmgr verwendet wird, um bootmgr von der Festplatte zu laden).

Ausnutzung

Der Angreifer muss sicherstellen, dass die serialisierte Secure-Boot-Richtlinie oberhalb einer bekannten physischen Adresse zugewiesen wird.

• Standardmäßig wird sie an der niedrigstmöglichen Adresse zugewiesen.
• Ursprünglich wird die serialisierte Secure-Boot-Richtlinie nach dem Laden zugewiesen, bevor eine aus der BCD geladene Konfiguration verwendet wird.
  • Seit RS1 wird die serialisierte Secure-Boot-Richtlinie beim Laden einer Startanwendung zugewiesen.
  • Seit RS2 wird eine vorhandene serialisierte Secure-Boot-Richtlinie freigegeben, wenn eine Secure-Boot-Richtlinie serialisiert wird.
• Die serialisierte Secure-Boot-Richtlinie wird neu zugewiesen, wenn beim Laden einer Startanwendung das osdevice des BCD-Eintrags eine BitLocker-verschlüsselte Partition ist, bei der der VMK mithilfe des TPM abgeleitet wurde.
  • Dies kann vorgetäuscht werden, indem Bit 0 der Schlüsselflags nach erfolgreicher TPM-Entsiegelung gesetzt wird; dieses Bit kann manuell in den BitLocker-Metadaten gesetzt werden, wobei zusätzliche Metadaten hinzugefügt werden, um anzugeben, dass Secure Boot für die Integritätsvalidierung verwendet wird.

Das Element avoidlowmemory kann verwendet werden, um sicherzustellen, dass alle Zuweisungen von physischem Speicher oberhalb einer angegebenen physischen Adresse erfolgen:

• Seit Windows 10 ist dieses Element nicht zulässig, wenn VBS aktiviert ist. Da es jedoch während der Initialisierung der Startanwendung verwendet wird, bevor die serialisierte Secure-Boot-Richtlinie aus dem Speicher gelesen wird, kann das Laden von bootmgr und das Angeben eines benutzerdefinierten BCD-Pfads (mithilfe des Elements bcdfilepath, auch bekannt als custom:22000023) verwendet werden, um dies zu umgehen.
• Wenn BitLocker auf dem Betriebssystemvolume vorhanden ist oder das Zielsystem TH1 oder TH2 ausführt, schlägt diese Methode fehl; es ist daher auch möglich, den Angriff einmal mit einem Windows-8.x-bootmgr auszuführen, um VBS zu deaktivieren, und dann wieder zum ursprünglichen Bootloader zu wechseln.
  • Windows 10 änderte die Initialisierung von Startanwendungen so, dass alle TPM-PCRs einmal begrenzt werden, sodass ein Windows-8.x-bootmgr den VMK auf einem Windows-10+-System nicht entsiegeln kann.

hvloader.efi kann mit dem Element nointegritychecks geladen werden, um eine selbstsignierte mcupdate.dll zu laden, deren Einstiegspunkt vor ExitBootServices aufgerufen wird.

Alternativ kann auf Nicht-AMD64-Systemen winload.efi vor TH2 mit dem Element testsigning verwendet werden; dies erlaubt selbstsignierte Binärdateien mit der EKU szOID_NT5_CRYPTO im Zertifikat.

Auf ARMv7-Systemen ist das Laden einer gepatchten, selbstsignierten hal.dll mit einem Import zu mcupdate.dll erforderlich, um Codeausführung zu erlangen.

Auf x86- und AMD64-Systemen muss die als mcupdate.dll geladene Datei mcupdate_*.dll heißen, wobei * die CPUID-Herstellerzeichenfolge ist (GenuineIntel, AuthenticAMD usw.).

Auf ARM64-Systemen kann diese Technik nicht verwendet werden, da der früheste verfügbare produktionssignierte Build ein WinPE von RS2 ist; daher kann derzeit nur tethered Codeausführung durchgeführt werden (mithilfe von bootdebug).

Enthaltene Dateien

Dieses Repository enthält die folgenden Dateien:

• Quellcode für eine einfache Payload ist enthalten. Diese Payload wartet nur unendlich auf einen Interrupt, da es ohne das Finden interessanter Funktionen und Variablen in der aufrufenden Startanwendung unmöglich ist, etwas anderes zu tun.
  • Da mcupdate.dll an einer virtuellen Adresse mit aktiviertem Paging ausgeführt wird, ist es unmöglich, EFI-Funktionen direkt aufzurufen (Paging muss deaktiviert werden, um EFI-Funktionen aufzurufen; die Rückkehr zu einer virtuellen Adresse mit deaktiviertem Paging führt zu nichts Gutem).
  • Um EFI-Funktionen aufzurufen, müsste eine Payload BlImgLoadPEImageEx oder BlImgLoadPEImageFromSourceBuffer mit Bit 0 in den Flags aufrufen, um eine zusätzliche Payload bei einer 1:1-Zuordnung von physischer Adresse zu virtueller Adresse zu laden.
    • Alternativ kann sie BlImgAllocateImageBuffer mit demselben gesetzten Bit aufrufen, um Speicher bei einer 1:1-Zuordnung von physischer Adresse zu virtueller Adresse zuzuweisen; dann eine Payload selbst laden (oder sich selbst dorthin umabbilden).
• Eine ISO, die dieses Problem auf AMD64 mithilfe von bootmgfw aus Windows 8 RTM und hvloader aus TH1 RTM ausnutzt.
  • Die hier verwendete Payload gibt mithilfe einer durch Offset erhaltenen Funktion aus hvloader eine Nachricht auf dem Bildschirm aus und läuft dann in einer Endlosschleife.
• Eine ISO, die dieses Problem auf AMD64 mithilfe von bootmgr aus RS1 und aus TH1 RTM ausnutzt.

Postskriptum

Dieses Problem kann verwendet werden, um BitLocker-Schlüssel auszulesen (wenn Secure Boot für die Integritätsvalidierung verwendet wird).

• Obwohl es möglich ist, wird die genaue Methode zur Erlangung von Codeausführung mit abgeleiteten BitLocker-Schlüsseln für ein beliebiges Volume im Speicher nicht offengelegt.

Die Korrektur für dieses Problem behob auch ein weiteres Problem ohne CVE.

• bootmgr ignoriert eine bereits im Speicher befindliche BitLocker-Schlüsseltabelle und weist eine neue zu, ohne die alte zu löschen.
  • Daher könnte ein Angreifer RS2+ bootmgr aus bootmgr laden (mit einem beliebigen osdevice, bei dem Secure Boot für die Integritätsvalidierung verwendet wird), zu WinPE booten, einen bekannten verwundbaren Treiber laden und damit die vorhandene BitLocker-Schlüsseltabelle im physischen Speicher suchen und auslesen.

Es wurde noch keine bekannte verwundbare Startanwendung widerrufen.

• Bis ein Widerruf erfolgt, kann ein Angreifer einfach eigene verwundbare Bootloader mitbringen.
• Ein Widerruf würde dazu führen, dass alle vorhandenen Windows-Installations-/Wiederherstellungsmedien und alte Backups nicht mehr booten können.
  • Der Bootfehler würde sogar bei deaktiviertem Secure Boot auftreten, da bootmgr seine eigene Signatur prüft.

Update (2023-05-10)

Ein unvollständiger Widerruf erfolgte, und eine weitere CVE (CVE-2023-24932). Es gibt immer noch verwundbare bootmgfws, die nicht widerrufen wurden, sowie zusätzliche Patches, die nur den Fall beheben, in dem bootmgr bootmgr lädt. Es brauchte nur einen eingefügten Bootkit, um MS zum Handeln zu bewegen ;)
Wenn du kreativ genug bist, findest du einen Weg, den Widerruf von über 2000 bootmgfw-Dateien zu umgehen ;)