themalwareguardian/cve-2022-34302Dimostra CVE-2022-34302, un bypass di Secure Boot tramite il bootloader firmato New Horizon Datasys il cui loader PE/COFF personalizzato integrato esegue applicazioni UEFI non firmate.
New Horizon Datasys Reboot Restore Boot Loader - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Bypass di Secure Boot tramite bootloader firmato con loader PE/COFF personalizzato integrato che carica applicazioni UEFI non firmate.
Questo repository dimostra la tecnica BYOVUA (Bring Your Own Vulnerable UEFI Application) sfruttando CVE-2022-34302, una vulnerabilità di bypass di Secure Boot nel boot loader di New Horizon Datasys.
A differenza delle vulnerabilità basate su UEFI Shell (CVE-2022-34301 e CVE-2022-34303), questo bootloader non espone una UEFI Shell. Al contrario, shdloader.efi implementa il proprio loader PE/COFF personalizzato che carica un binario di secondo stadio (shdmgr.ef_) senza utilizzare la funzione LoadImage() del firmware e senza eseguire alcuna verifica della firma. Un attaccante deve solamente sostituire shdmgr.ef_ con qualsiasi applicazione UEFI compatibile per ottenere l'esecuzione di codice arbitrario con Secure Boot abilitato.
Questa è la più pericolosa delle tre vulnerabilità divulgate nella ricerca "One Bootloader to Load Them All". Come osservato da Eclypsium: il bypass è integrato, completamente silenzioso e non lascia alcuna indicazione visiva sullo schermo - rendendolo invisibile anche su sistemi dotati di monitor e non rilevabile su sistemi headless come server o apparecchiature industriali.
BYOVUA è l'equivalente UEFI della tecnica BYOVD (Bring Your Own Vulnerable Driver) utilizzata a livello kernel. Invece di portare un driver kernel firmato con una vulnerabilità, l'attaccante porta un'applicazione UEFI firmata che contiene funzionalità in grado di compromettere Secure Boot.
Poiché shdloader.efi è firmato con un certificato considerato attendibile da Microsoft, viene accettato da Secure Boot senza obiezioni, rendendolo attendibile su qualsiasi sistema che includa questo certificato nel proprio database Secure Boot (db) - ovvero praticamente ogni PC con supporto UEFI spedito nell'ultimo decennio. Una volta in esecuzione, il suo loader PE personalizzato integrato fornisce all'attaccante la capacità di caricare ed eseguire codice arbitrario non firmato prima del caricamento del sistema operativo, in un ambiente in cui i moderni controlli di sicurezza (ASLR, DEP, protezioni del kernel) semplicemente non esistono.
shdloader.efi è un boot loader UEFI distribuito come parte dei prodotti di ripristino e recupero del sistema di New Horizon Datasys (Reboot Restore Rx, RollBack Rx). Il suo ruolo nella catena di avvio legittima è caricare un componente di gestione pre-OS (shdmgr.ef_) che gestisce le operazioni di snapshot e ripristino prima dell'avvio del sistema operativo.
La vulnerabilità è un difetto di progettazione nell'architettura del boot loader. Anziché utilizzare i boot services del firmware LoadImage() e StartImage() - che impongono la verifica della firma Secure Boot - shdloader.efi implementa il proprio loader PE/COFF personalizzato che legge, rilocalizza ed esegue shdmgr.ef_ direttamente dai byte grezzi del disco, aggirando completamente i controlli di sicurezza del firmware.
Il problema principale: un binario firmato considerato attendibile da Secure Boot contiene il proprio image loader che non verifica le firme. Il firmware convalida shdloader.efi come firmato, ma una volta in esecuzione, carica shdmgr.ef_ senza alcuna verifica. Sostituire shdmgr.ef_ con un'applicazione UEFI arbitraria comporta che tale applicazione venga eseguita con pieno accesso all'hardware, mentre Secure Boot risulta abilitato.
Questo è fondamentalmente diverso da CVE-2022-34301 e CVE-2022-34303, dove l'attaccante deve interagire con una UEFI Shell e corrompere manualmente per disabilitare la verifica. Qui, il bypass è - nessuna interazione utente, nessun output visibile, nessun prompt della shell.
| Proprietà | Valore |
|---|
| File | shdloader.efi = EFI/Boot/bootx64.efi |
| Vendor | New Horizon Datasys Inc |
| Prodotto | Reboot Restore Rx / RollBack Rx |
| CVE | CVE-2022-34302 |
| Firma | Microsoft Windows UEFI Driver Publisher → Microsoft Corporation UEFI CA 2011 |
| Scoperta | Eclypsium (Mickey Shkatov, Jesse Michael) - Agosto 2022 |
| Presentazione | DEF CON 30 - "One Bootloader to Load Them All" |
| Revoca | Aggiunto al DBX tramite Microsoft KB5012170 (Agosto 2022) |
gSecurity2Il firmato shdloader.efi contiene la propria implementazione di un loader di immagini PE/COFF. Anziché chiamare il boot service LoadImage() del firmware, che invocherebbe i Security Architectural Protocols e verificherebbe la firma dell'immagine rispetto al database Secure Boot, il bootloader:
\EFI\Boot\shdmgr.ef_ utilizzando il protocollo EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.reloc e applica le rilocazioni di baseIn nessun momento di questo processo il loader verifica la firma Authenticode dell'immagine, controlla il database Secure Boot (db/dbx) o invoca il protocollo EFI_SECURITY2_ARCH_PROTOCOL. L'immagine viene caricata esclusivamente in base alla sua validità strutturale PE/COFF.```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 Custom Loader***
La differenza tra `LoadImage()` del firmware e il loader personalizzato è il divario di sicurezza critico:```
┌─────────────────────────────────────────────────────────────────────────┐
│ 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 │
└─────────────────────────────────────────────────────────────────────────┘
Il loader PE personalizzato è un'implementazione semplificata e si aspetta un layout PE/COFF specifico. I binari che non sono conformi vengono rifiutati con errori:``` Reloc table overflows binary Relocation failed Invalid entry point
Un binario privo di uno qualsiasi di questi elementi verrà rifiutato dal loader personalizzato.
| Campo | Valore richiesto | Motivo |
|-------|---------------|--------|
| *Machine* | `0x8664` (x64) | Il loader supporta solo immagini x86-64 |
| *Subsystem* | `10` (EFI Application) | Deve essere un'EFI Application |
| *sezione .reloc* | `.reloc` deve esistere con voci di base relocation valide | Il loader esegue la propria relocation dell'immagine. Senza .reloc, fallisce con "Reloc table overflows binary" |
| *Relocation Directory* | `VirtualAddress` != 0, Size != 0 (DATA_DIRECTORY[5]) | La voce di directory deve puntare a dati di relocation validi |
Uno script di verifica (Scripts/VerifyPE.py) è fornito per controllare la compatibilità prima del deployment.
---
<div id='BYOVD'/>
### ***Parallelismo con il Kernel BYOVD***
Il parallelismo strutturale tra UEFI BYOVUA e kernel BYOVD è esatto, sebbene CVE-2022-34302 rappresenti la forma più diretta - il componente firmato **stesso** carica codice non firmato, invece di fornire una primitiva per disabilitare la verifica:```
┌──────────────────────────────────────────────────────────────┐
│ 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 è la variante più pericolosa perché il bypass è insito nel design del bootloader - non esiste alcuno step intermedio in cui l'attaccante debba corrompere un meccanismo di sicurezza. Il componente firmato carica direttamente codice non firmato come sua normale operazione.
Il file firmato shdloader.efi viene posizionato sulla EFI System Partition (ESP) come boot loader predefinito. Poiché è firmato dal certificato Microsoft UEFI Driver Publisher, Secure Boot lo convalida e lo carica senza problemi.```
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
Quando il sistema si avvia, il firmware:
1. Legge `bootx64.efi` dall'ESP
2. Chiama `LoadImage()` che verifica la firma Authenticode rispetto al database Secure Boot
3. La firma corrisponde al certificato Microsoft UEFI CA 2011 nel `db` → l'immagine viene accettata
4. Chiama `StartImage()` per trasferire l'esecuzione a `shdloader.efi`
---
<div id='Phase2'/>
### ***Fase 2 - Attivazione del PE Loader Personalizzato***
Una volta che `shdloader.efi` ha il controllo, stampa un messaggio diagnostico e attiva immediatamente il suo PE/COFF loader personalizzato:```
Booting in insecure mode
Il bootloader quindi:
\EFI\Boot\shdmgr.ef_ utilizzando il protocollo del filesystem.text, .data, .reloc, ecc.) nella memoria allocataLoadAddress - ImageBase) e applica tutte le rilocazioni di base dalla sezione .relocLoadAddress + AddressOfEntryPoint come target di esecuzioneNessuna verifica della firma avviene in nessun punto di questo processo. Il loader non chiama LoadImage(), non invoca gSecurity2->FileAuthenticationState() e non controlla i database db o dbx. Il file viene caricato esclusivamente in base alla validità strutturale.
Se il file non viene trovato, il bootloader segnala:``` Failed to open \EFI\Boot\shdmgr.ef_ - 800000000000000E Failed to load image
---
<div id='Phase3'/>
### ***Fase 3 - Esecuzione di codice non firmato***
Il loader personalizzato salta al punto di ingresso di `shdmgr.ef_`. L'applicazione UEFI non firmata ora viene eseguita con:
- Accesso completo all'hardware (memoria diretta, porte I/O, PCI, MMIO)
- Nessun sistema operativo ancora caricato
- Nessun ASLR, DEP o protezione del kernel
- Nessun EDR o monitoraggio della sicurezza degli endpoint
- Secure Boot segnalato come **abilitato** a qualsiasi query successiva del sistema operativo
L'attacco è completamente silenzioso. A differenza di CVE-2022-34301 e CVE-2022-34303, che mostrano un prompt visibile della UEFI Shell, questo exploit non produce alcun output visivo oltre al messaggio "Booting in insecure mode" (che, su un sistema legittimo, appare brevemente e viene rapidamente sostituito dalla schermata di avvio del sistema operativo). Su sistemi headless (server, IoT, apparecchiature industriali), non c'è alcuna indicazione.
---
<div id='Phase4'/>
### ***Fase 4 - Persistenza***
L'attacco è persistente per impostazione predefinita. Finché `shdloader.efi` rimane in `\EFI\Boot\bootx64.efi` e il payload dell'attaccante rimane in `\EFI\Boot\shdmgr.ef_` sull'ESP, il payload non firmato viene eseguito a ogni avvio.
Non è necessario alcuno script `startup.nsh`. Non è necessario ricalcolare alcun indirizzo gSecurity2 tra gli aggiornamenti del firmware. Il loader PE personalizzato carica qualunque `shdmgr.ef_` trovi, incondizionatamente.
Il sistema continua a segnalare Secure Boot come "abilitato" - solo la catena di fiducia è stata infranta a livello di bootloader. Questo rende l'attacco invisibile alle query sullo stato di Secure Boot a livello di sistema operativo e a qualsiasi software di sicurezza che si basa sull'attestazione di Secure Boot.
> **Importante:** La persistenza viene interrotta solo se il DBX viene aggiornato con la voce di revoca per `shdloader.efi` (KB5012170), il che causa il rifiuto di `shdloader.efi` da parte del firmware stesso prima che il loader personalizzato si attivi.
---
---
---
<div id='Exploit'/>
## ***Exploit***
La directory `Exploit/` contiene tutto il necessario per compilare un `shdmgr.ef_` compatibile:```
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
Il bootloader firmato è stato aggiunto alla lista di revoca DBX di Microsoft tramite KB5012170 (agosto 2022). Sui sistemi aggiornati, il bootloader verrà rifiutato da Secure Boot prima che il custom PE loader possa mai attivarsi.
Per l'ambiente di laboratorio, è necessario un sistema in cui:
Il QEMU UEFI Research Environment fornisce una configurazione automatizzata per questo scopo.
CVE-2022-34302 è più semplice da sfruttare rispetto a CVE-2022-34301 e CVE-2022-34303:
| Aspetto | CVE-2022-34302 (Custom Loader) | CVE-2022-34301/34303 (Shell) |
|---|
| Tecnica | Sostituire shdmgr.ef_ con il payload | Corrompere gSecurity2 tramite il comando mm |
| Interazione | Nessuna (completamente automatica) | Comandi shell manuali o startup.nsh |
| Visibilità | Silenziosa ("Booting in insecure mode") | Prompt UEFI Shell visibile |
| Dipendenza dal firmware | Nessuna (il payload è autonomo) | L'indirizzo di gSecurity2 cambia per ogni build del firmware |
| Complessità | Bassa (sostituzione di file) | Media (scansione e patching della memoria) |
| Stealth | Alta (nessun output visivo su headless) | Bassa (shell visibile sullo schermo) |