themalwareguardian/cve-2022-34303Demonstriert die Umgehung von Secure Boot über CVE-2022-34303 mittels einer von CryptoPro signierten UEFI-Shell, wobei der Befehl mm verwendet wird, um gSecurity2 zu nullifizieren und unsignierte UEFI-Anwendungen zu laden.
CryptoPro Secure Disk UEFI Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Secure Boot bypass via signierter UEFI Shell und gSecurity2-Korruption.
Dieses Repository demonstriert die BYOVUA (Bring Your Own Vulnerable UEFI Application)-Technik durch die Ausnutzung von CVE-2022-34303, einer Secure-Boot-Bypass-Schwachstelle in der CryptoPro Secure Disk UEFI-Boot-Umgebung.
In diesem Fall ist die von Secure Boot vertraute Komponente ein benutzerdefinierter Shim, der von der Microsoft UEFI Third Party Certificate Authority signiert wurde. Nach der Ausführung lädt dieser Shim eine UEFI Shell als zweite Stufe, die den Befehl mm (memory modify) bereitstellt und somit beliebige Speicher-Lese- und Schreibfähigkeiten während der Pre-OS-Boot-Phase ermöglicht.
Dieses Primitiv kann dann genutzt werden, um den globalen Zeiger gSecurity2 im DXE-Kern zu lokalisieren und zu nullifizieren. Infolgedessen wird die nachfolgende UEFI-Image-Verifizierung deaktiviert, wodurch unsignierte UEFI-Anwendungen, Bootkits, trotz aktiviertem Secure Boot geladen werden können.
BYOVUA ist das UEFI-Äquivalent zur BYOVD-Technik (Bring Your Own Vulnerable Driver), die auf Kernel-Ebene verwendet wird. Anstatt einen signierten Kernel-Treiber mit einer Schwachstelle mitzubringen, bringt der Angreifer eine signierte UEFI-Anwendung mit - in diesem Fall eine vollständige UEFI Shell -, die Funktionalität enthält, die Secure Boot untergraben kann.
Da die Anwendung - in diesem Fall der benutzerdefinierte Shim, der die UEFI Shell als zweite Stufe lädt - mit einem von Microsoft vertrauenswürdigen Zertifikat signiert ist, wird sie von Secure Boot ohne Weiteres akzeptiert, wodurch sie auf jedem System vertrauenswürdig ist, das dieses Zertifikat in seiner Secure-Boot-Datenbank (db) enthält - was praktisch auf jedem in den letzten zehn Jahren ausgelieferten UEFI-fähigen PC der Fall ist. Einmal ausgeführt, bieten ihre integrierten Befehle dem Angreifer direkten Hardware- und Speicherzugriff, der vor dem Laden des Betriebssystems arbeitet, in einer Umgebung, in der moderne Sicherheitskontrollen (ASLR, DEP, Kernel-Schutzmechanismen) schlicht nicht existieren.
Shell_Full.efi ist eine UEFI Shell, die als Teil von CryptoPro Secure Disk, einem Produkt für Pre-Boot-Authentifizierung und Festplattenverschlüsselung, vertrieben wird.
| Eigenschaft | Wert |
|---|---|
| Datei | Shell_Full.efi = EFI/Boot/BootX64.efi (SHIM) -> EFI/CPSD/Bootxsa.efi (Shell) |
| Hersteller | CryptoPro Secure Disk |
| CVE | CVE-2022-34303 |
| Signierung | Microsoft Corporation UEFI CA 2011 (Third Party) |
| Entdeckung | Eclypsium (Mickey Shkatov, Jesse Michael) - August 2022 |
| Präsentation | DEF CON 30 - "One Bootloader to Load Them All" |
| Widerruf | Zur DBX hinzugefügt via Microsoft KB5012170 (August 2022) |
Die Schwachstelle ist kein Bug - sie ist ein Designfehler. UEFI Shells sind legitime Diagnosewerkzeuge, die niemals dafür gedacht waren, in Secure-Boot-Umgebungen ausgeführt zu werden. Indem die Hersteller sie jedoch mit einem von Microsoft vertrauenswürdigen Zertifikat signierten und als Teil kommerzieller Produkte vertrieben, schufen sie unbeabsichtigt einen signierten Bypass für Secure Boot.
Das Kernproblem: Eine signierte Binärdatei, der Secure Boot vertraut, bietet uneingeschränkte Speicher-Lese-/Schreibfähigkeiten durch ihre integrierten Befehle. Diese Kombination bricht das gesamte Secure-Boot-Vertrauensmodell.
Der Befehl mm (memory modify) ist ein standardmäßiger integrierter Befehl der UEFI Shell, der direkten Lese- und Schreibzugriff auf den Systemspeicher bietet. Er ist in der UEFI Shell Specification (Abschnitt 5.3) dokumentiert.```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| Parameter | Beschreibung |
|-----------|-------------|
| `Address` | Ziel-Speicheradresse |
| `Value` | Zu schreibender Wert (weglassen für Nur-Lesen) |
| `-w` | Breite: 1, 2, 4 oder 8 Bytes |
| `-MEM` | Systemspeicherzugriff |
| `-MMIO` | Speicherzugeordnete E/A |
| `-IO` | E/A-Port-Zugriff |
| `-n` | Nicht-interaktiv (keine Aufforderung für nächste Adresse) |
---
<div id='gsecurity2'/>
### ***gSecurity2 und das Security Architectural Protocol***
Die Secure-Boot-Image-Verifikation in UEFI wird durch die [Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) erzwungen, die in der UEFI Platform Initialization (PI) Specification definiert sind.
Der DXE-Kern (DxeMain) verwaltet einen globalen Zeiger namens [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252), der auf die Struktur `EFI_SECURITY2_ARCH_PROTOCOL` zeigt. Dieses Protokoll enthält einen einzigen Funktionszeiger - `FileAuthenticationState` - der von `LoadImage()` jedes Mal aufgerufen wird, wenn ein UEFI-Image geladen wird:```c
// EFI_SECURITY2_ARCH_PROTOCOL structure (PI Specification)
typedef struct _EFI_SECURITY2_ARCH_PROTOCOL {
EFI_SECURITY_FILE_AUTHENTICATION_STATE FileAuthenticationState;
} EFI_SECURITY2_ARCH_PROTOCOL;
// GUID: 94AB2F58-1438-4EF1-9152-18941A3A0E68
Wenn LoadImage() aufgerufen wird, prüft der DXE-Core:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
Durch das Setzen von `gSecurity2 = NULL` schlägt die `if`-Prüfung fehl und `FileAuthenticationState` wird nie aufgerufen. Die Image-Verifizierung wird vollständig übersprungen – **Secure Boot bleibt „aktiviert“, wird aber nicht mehr durchgesetzt**. Unsignierte UEFI-Anwendungen können dann frei geladen werden.
Für ein tiefes technisches Verständnis dieser Technik, einschließlich einer eigens entwickelten UEFI-Anwendung, die gSecurity2 automatisch lokalisiert und patcht, siehe das begleitende Projekt: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption).
---