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.
| 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) |
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 gSecurity2 per disabilitare la verifica. Qui, il bypass è automatico e silenzioso - nessuna interazione utente, nessun output visibile, nessun prompt della shell.
Il 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);