themalwareguardian/cve-2022-34302Demonstriert CVE-2022-34302, eine Secure-Boot-Umgehung über den von New Horizon Datasys signierten Bootloader, dessen integrierter benutzerdefinierter PE/COFF-Loader unsignierte UEFI-Anwendungen ausführt.
New Horizon Datasys Reboot Restore Boot Loader - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Secure Boot bypass via signiertem Bootloader mit integriertem benutzerdefiniertem PE/COFF-Loader, der unsignierte UEFI-Anwendungen lädt.
Dieses Repository demonstriert die BYOVUA (Bring Your Own Vulnerable UEFI Application)-Technik durch die Ausnutzung von CVE-2022-34302, einer Secure-Boot-Umgehungsschwachstelle im New Horizon Datasys Bootloader.
Im Gegensatz zu den UEFI-Shell-basierten Schwachstellen (CVE-2022-34301 und CVE-2022-34303) stellt dieser Bootloader keine UEFI-Shell bereit. Stattdessen implementiert shdloader.efi einen eigenen benutzerdefinierten PE/COFF-Loader, der ein Second-Stage-Binary (shdmgr.ef_) lädt, ohne die LoadImage()-Funktion der Firmware zu verwenden und ohne jegliche Signaturüberprüfung durchzuführen. Ein Angreifer muss lediglich shdmgr.ef_ durch eine beliebige kompatible UEFI-Anwendung ersetzen, um beliebige Codeausführung bei aktiviertem Secure Boot zu erreichen.
Dies ist die gefährlichste der drei Schwachstellen, die in der Forschung "One Bootloader to Load Them All" offengelegt wurden. Wie Eclypsium anmerkte: Die Umgehung ist eingebaut, vollständig lautlos und hinterlässt keinen sichtbaren Hinweis auf dem Bildschirm - was sie selbst auf Systemen mit Monitor unsichtbar und auf Headless-Systemen wie Servern oder Industrieanlagen unentdeckbar macht.
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, die Funktionalität enthält, die Secure Boot untergraben kann.
Da shdloader.efi mit einem von Microsoft als vertrauenswürdig eingestuften Zertifikat signiert ist, wird es von Secure Boot ohne Weiteres akzeptiert, was es auf jedem System vertrauenswürdig macht, 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, bietet sein integrierter benutzerdefinierter PE-Loader dem Angreifer die Möglichkeit, beliebigen unsignierten Code vor dem Laden des Betriebssystems zu laden und auszuführen, in einer Umgebung, in der moderne Sicherheitskontrollen (ASLR, DEP, Kernel-Schutzmechanismen) schlicht nicht existieren.
shdloader.efi ist ein UEFI-Bootloader, der als Teil der Systemwiederherstellungs- und Recovery-Produkte von New Horizon Datasys (Reboot Restore Rx, RollBack Rx) vertrieben wird. Seine Rolle in der legitimen Boot-Kette besteht darin, eine Pre-OS-Management-Komponente (shdmgr.ef_) zu laden, die Snapshot- und Wiederherstellungsvorgänge vor dem Start des Betriebssystems abwickelt.
Die Schwachstelle ist ein Designfehler in der Architektur des Bootloaders. Anstatt die LoadImage()- und StartImage()-Boot-Services der Firmware zu verwenden - die die Secure-Boot-Signaturüberprüfung erzwingen - implementiert shdloader.efi einen eigenen benutzerdefinierten PE/COFF-Loader, der shdmgr.ef_ direkt aus rohen Disk-Bytes liest, reloziert und ausführt, wodurch die Sicherheitsprüfungen der Firmware vollständig umgangen werden.
Das Kernproblem: Ein signiertes Binary, das von Secure Boot als vertrauenswürdig eingestuft wird, enthält einen eigenen Image-Loader, der keine Signaturen überprüft. Die Firmware validiert shdloader.efi als signiert, aber sobald es ausgeführt wird, lädt es shdmgr.ef_ ohne jegliche Überprüfung. Das Ersetzen von shdmgr.ef_ durch eine beliebige UEFI-Anwendung führt dazu, dass diese Anwendung mit vollem Hardwarezugriff ausgeführt wird, während Secure Boot als aktiviert gemeldet wird.
| Eigenschaft | Wert |
|---|
| Datei | shdloader.efi = EFI/Boot/bootx64.efi |
| Hersteller | New Horizon Datasys Inc |
| Produkt | Reboot Restore Rx / RollBack Rx |
| CVE | CVE-2022-34302 |
| Signierung | Microsoft Windows UEFI Driver Publisher → Microsoft Corporation UEFI CA 2011 |
| Entdeckung | Eclypsium (Mickey Shkatov, Jesse Michael) - August 2022 |
| Präsentation | DEF CON 30 - "One Bootloader to Load Them All" |
| Widerruf | Hinzugefügt zur DBX über Microsoft KB5012170 (August 2022) |
Dies unterscheidet sich grundlegend von CVE-2022-34301 und CVE-2022-34303, bei denen der Angreifer mit einer UEFI-Shell interagieren und gSecurity2 manuell korrumpieren muss, um die Überprüfung zu deaktivieren. Hier erfolgt die Umgehung automatisch und lautlos - keine Benutzerinteraktion, keine sichtbare Ausgabe, keine Shell-Eingabeaufforderung.
Das signierte shdloader.efi enthält eine eigene Implementierung eines PE/COFF-Image-Loaders. Anstatt den LoadImage()-Boot-Service der Firmware aufzurufen, der die Security Architectural Protocols aufrufen und die Signatur des Images gegen die Secure-Boot-Datenbank überprüfen würde, führt der Bootloader Folgendes aus:
\EFI\Boot\shdmgr.ef_ unter Verwendung des EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.reloc-Sektion und wendet Basisrelokationen anZu keinem Zeitpunkt dieses Prozesses überprüft der Loader die Authenticode-Signatur des Images, prüft die Secure-Boot-Datenbank (db/dbx) oder ruft das EFI_SECURITY2_ARCH_PROTOCOL auf. Das Image wird ausschließlich auf Basis seiner strukturellen PE/COFF-Gültigkeit geladen.```c
// Pseudocode of what shdloader.efi does internally
//
// NOTE: This is a simplified representation. The actual
// implementation was derived from reverse engineering.
EFI_STATUS LoadShdmgr(VOID) { // Step 1: Open the file File = OpenFile(L"\EFI\Boot\shdmgr.ef_");
// Step 2: Read raw bytes (no signature check)
ReadFile(File, &Buffer, &Size);
// Step 3: Parse PE/COFF headers
DosHeader = (EFI_IMAGE_DOS_HEADER *)Buffer;
PeHeader = (EFI_IMAGE_NT_HEADERS *)(Buffer + DosHeader->e_lfanew);
// Step 4: Allocate memory and copy sections
ImageBase = AllocatePages(...);
CopySections(ImageBase, Buffer, PeHeader);
// Step 5: Apply base relocations from .reloc
Delta = ImageBase - PeHeader->OptionalHeader.ImageBase;
ApplyRelocations(ImageBase, PeHeader, Delta);
// Step 6: Jump to entry point
// NO SIGNATURE VERIFICATION ANYWHERE
EntryPoint = ImageBase + PeHeader->OptionalHeader.AddressOfEntryPoint;
((EFI_IMAGE_ENTRY_POINT)EntryPoint)(ImageHandle, SystemTable);
}
---
<div id='LoadImageVsCustomLoader'/>
### ***LoadImage vs. benutzerdefinierter Loader***
Der Unterschied zwischen der `LoadImage()`-Funktion der Firmware und dem benutzerdefinierten Loader ist die entscheidende Sicherheitslücke:```
┌─────────────────────────────────────────────────────────────────────────┐
│ Firmware LoadImage() - How legitimate boot chains work │
│ │
│ bootx64.efi ──> LoadImage("shdmgr.ef_") │
│ │ │
│ ├── Parse PE/COFF headers │
│ ├── Verify Authenticode signature │
│ ├── Check signature against db (allowed) │
│ ├── Check hash against dbx (revoked) │
│ ├── Call gSecurity2->FileAuthenticationState() │
│ │ │ │
│ │ ├── Signature valid? ── YES ──> Load image │
│ │ └── Signature invalid? ── NO ──> REJECT │
│ └── StartImage() │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ Custom PE Loader - What shdloader.efi does │
│ │
│ shdloader.efi ──> OpenFile("shdmgr.ef_") │
│ │ │
│ ├── ReadFile() into buffer │
│ ├── Parse PE/COFF headers │
│ ├── Allocate memory │
│ ├── Copy sections │
│ ├── Apply .reloc relocations │
│ ├── *** NO SIGNATURE CHECK *** │
│ └── Jump to EntryPoint │
│ │
│ Result: ANY valid PE/COFF EFI application runs, signed or not │
└─────────────────────────────────────────────────────────────────────────┘
Der benutzerdefinierte PE-Loader ist eine vereinfachte Implementierung und erwartet ein bestimmtes PE/COFF-Layout. Binärdateien, die nicht konform sind, werden mit Fehlern abgelehnt:``` Reloc table overflows binary Relocation failed Invalid entry point
Ein Binary, dem eines dieser Felder fehlt, wird vom benutzerdefinierten Loader abgelehnt.
| Feld | Erforderlicher Wert | Grund |
|-------|---------------|--------|
| *Machine* | `0x8664` (x64) | Der Loader unterstützt nur x86-64-Images |
| *Subsystem* | `10` (EFI Application) | Muss eine EFI Application sein |
| *.reloc-Abschnitt* | `.reloc` muss mit gültigen Basis-Relaokationseinträgen existieren | Der Loader führt seine eigene Image-Relaokation durch. Ohne .reloc schlägt er mit "Reloc table overflows binary" fehl |
| *Relocation Directory* | `VirtualAddress` != 0, Size != 0 (DATA_DIRECTORY[5]) | Der Verzeichniseintrag muss auf gültige Relaokationsdaten verweisen |
Ein Verifikationsskript (Scripts/VerifyPE.py) wird bereitgestellt, um die Kompatibilität vor der Bereitstellung zu überprüfen.
---
<div id='BYOVD'/>
### ***Parallele zu Kernel BYOVD***
Die strukturelle Parallele zwischen UEFI BYOVUA und Kernel BYOVD ist exakt, obwohl CVE-2022-34302 die direkteste Form darstellt – die signierte Komponente **selbst** lädt unsignierten Code, anstatt ein Primitiv zum Deaktivieren der Verifikation bereitzustellen:```
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA - CVE-2022-34302 (Custom PE Loader) │
│ │
│ Signed Bootloader ──> Custom PE Loader ──> Load unsigned │
│ (trusted by (no sig check) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ UEFI BYOVUA - CVE-2022-34301/34303 (Shell + gSecurity2) │
│ │
│ Signed Shell ─ mm ─> gSecurity2 = NULL ─> Load unsigned │
│ (trusted by (Security2 Protocol) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ Kernel BYOVD (DSE Bypass) │
│ │
│ Signed Driver ─ IOCTL ─> g_CiOptions = 0 ─> Load unsigned │
│ (trusted by (CI.dll) kernel drivers │
│ DSE / CI) │
└──────────────────────────────────────────────────────────────┘
CVE-2022-34302 ist die gefährlichste Variante, da die Umgehung inhärent im Design des Bootloaders liegt – es gibt keinen Zwischenschritt, bei dem der Angreifer einen Sicherheitsmechanismus korrumpieren müsste. Die signierte Komponente lädt unsignierten Code direkt als ihre normale Operation.
Der signierte shdloader.efi wird auf der EFI-Systempartition (ESP) als Standard-Bootloader platziert. Da er von Microsofts UEFI Driver Publisher-Zertifikat signiert ist, validiert und lädt Secure Boot ihn ohne Probleme.```
EFI System Partition (ESP)
└── EFI/
└── Boot/
└── bootx64.efi (shdloader.efi) ← Signed by Microsoft Windows UEFI Driver Publisher
└── shdmgr.ef_ (PAYLOAD) ← Unsigned, loaded by shdloader's custom PE loader
Wenn das System startet, führt die Firmware folgende Schritte aus:
1. Liest `bootx64.efi` aus der ESP
2. Ruft `LoadImage()` auf, wodurch die Authenticode-Signatur gegen die Secure-Boot-Datenbank verifiziert wird
3. Die Signatur stimmt mit dem Microsoft UEFI CA 2011-Zertifikat in der `db` überein → das Image wird akzeptiert
4. Ruft `StartImage()` auf, um die Ausführung an `shdloader.efi` zu übergeben
---
<div id='Phase2'/>
### ***Phase 2 - Benutzerdefinierter PE-Loader wird aktiviert***
Sobald `shdloader.efi` die Kontrolle übernommen hat, gibt es eine Diagnosemeldung aus und aktiviert sofort seinen benutzerdefinierten PE/COFF-Loader:```
Booting in insecure mode
Der Bootloader führt dann Folgendes aus:
\EFI\Boot\shdmgr.ef_ unter Verwendung des Dateisystemprotokolls.text, .data, .reloc usw.) in den reservierten SpeicherLoadAddress - ImageBase) und wendet alle Basisrelokationen aus der .reloc-Section anLoadAddress + AddressOfEntryPoint als Ausführungsziel aufZu keinem Zeitpunkt dieses Prozesses findet eine Signaturprüfung statt. Der Loader ruft weder LoadImage() auf, noch ruft er gSecurity2->FileAuthenticationState() auf, noch prüft er die Datenbanken db oder dbx. Die Datei wird ausschließlich auf der Grundlage struktureller Gültigkeit geladen.
Wenn die Datei nicht gefunden wird, meldet der Bootloader:``` Failed to open \EFI\Boot\shdmgr.ef_ - 800000000000000E Failed to load image
---
<div id='Phase3'/>
### ***Phase 3 - Ausführung nicht signierten Codes***
Der benutzerdefinierte Loader springt zum Einstiegspunkt von `shdmgr.ef_`. Die nicht signierte UEFI-Anwendung läuft nun mit:
- Vollständigem Hardwarezugriff (direkter Speicher, I/O-Ports, PCI, MMIO)
- Noch kein Betriebssystem geladen
- Kein ASLR, DEP oder Kernel-Schutzmechanismen
- Keine EDR- oder Endpoint-Security-Überwachung
- Secure Boot wird gegenüber jeder nachfolgenden OS-Abfrage als **aktiviert** gemeldet
Der Angriff ist vollständig still. Anders als CVE-2022-34301 und CVE-2022-34303, die eine sichtbare UEFI-Shell-Eingabeaufforderung anzeigen, erzeugt dieser Exploit keine sichtbare Ausgabe außer der Meldung „Booting in insecure mode" (die auf einem legitimen System kurz erscheint und schnell durch den OS-Boot-Bildschirm ersetzt wird). Auf Headless-Systemen (Server, IoT, Industrieausrüstung) gibt es überhaupt keinen Hinweis.
---
<div id='Phase4'/>
### ***Phase 4 - Persistenz***
Der Angriff ist standardmäßig persistent. Solange `shdloader.efi` unter `\EFI\Boot\bootx64.efi` verbleibt und die Payload des Angreifers unter `\EFI\Boot\shdmgr.ef_` auf der ESP verbleibt, wird die nicht signierte Payload bei jedem Boot ausgeführt.
Es wird kein `startup.nsh`-Skript benötigt. Es muss keine gSecurity2-Adresse über Firmware-Updates hinweg neu berechnet werden. Der benutzerdefinierte PE-Loader lädt bedingungslos jede `shdmgr.ef_`, die er findet.
Das System meldet weiterhin Secure Boot als „aktiviert" – nur die Vertrauenskette wurde auf der Bootloader-Ebene durchbrochen. Dies macht den Angriff unsichtbar für Secure-Boot-Statusabfragen auf OS-Ebene und für jede Sicherheitssoftware, die auf Secure-Boot-Attestierung angewiesen ist.
> **Wichtig:** Die Persistenz wird nur durchbrochen, wenn die DBX mit dem Widerrufseintrag für `shdloader.efi` (KB5012170) aktualisiert wird, wodurch die Firmware `shdloader.efi` selbst ablehnt, bevor der benutzerdefinierte Loader überhaupt aktiviert wird.
---
---
---
<div id='Exploit'/>
## ***Exploit***
Das Verzeichnis `Exploit/` enthält alles, was zum Erstellen einer kompatiblen `shdmgr.ef_` benötigt wird:```
Exploit/
|
├── README.md ← Build guide and PE/COFF requirements
|
├── PayloadShdmgr/
| |
│ ├── ForceReloc.nasm ← Force .reloc section generation
│ ├── shdmgr.ef_.c ← UEFI application source (EDK2)
│ ├── shdmgr.ef_.inf ← EDK2 module definition
│ ├── shdmgr.ef_.dsc ← EDK2 platform build configuration
│ └── shdmgr.ef_.dec ← EDK2 package declaration
|
└── Scripts/
└── VerifyPE.py ← PE/COFF compatibility verifier
Der signierte Bootloader wurde über KB5012170 (August 2022) zur DBX-Sperrliste von Microsoft hinzugefügt. Auf aktualisierten Systemen wird der Bootloader von Secure Boot abgelehnt, bevor der benutzerdefinierte PE-Loader überhaupt aktiviert wird.
Für die Laborumgebung benötigen Sie ein System, bei dem:
Die QEMU UEFI Research Environment bietet eine automatisierte Einrichtung hierfür.
CVE-2022-34302 ist einfacher auszunutzen als CVE-2022-34301 und CVE-2022-34303:
| Aspekt | CVE-2022-34302 (Benutzerdefinierter Loader) | CVE-2022-34301/34303 (Shell) |
|---|
| Technik | shdmgr.ef_ durch Payload ersetzen | gSecurity2 über mm-Befehl korrumpieren |
| Interaktion | Keine (vollautomatisch) | Manuelle Shell-Befehle oder startup.nsh |
| Sichtbarkeit | Unauffällig ("Booting in insecure mode") | Sichtbare UEFI-Shell-Eingabeaufforderung |
| Firmware-Abhängigkeit | Keine (Payload ist eigenständig) | gSecurity2-Adresse ändert sich je nach Firmware-Build |
| Komplexität | Gering (Dateiersetzung) | Mittel (Speicher-Scanning und -Patching) |
| Stealth | Hoch (keine visuelle Ausgabe bei Headless) | Gering (Shell auf dem Bildschirm sichtbar) |