Dimostra il bypass di Secure Boot CVE-2022-34301 tramite la UEFI Shell firmata Eurosoft (esdiags.efi), utilizzando il comando mm per annullare gSecurity2 e caricare applicazioni UEFI non firmate.
Eurosoft Pc-Check UEFI Diagnostics Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Bypass di Secure Boot tramite UEFI Shell firmata e corruzione di gSecurity2.
Questo repository dimostra la tecnica BYOVUA (Bring Your Own Vulnerable UEFI Application) sfruttando CVE-2022-34301, una vulnerabilità di bypass di Secure Boot nell'ambiente diagnostico UEFI Eurosoft Pc-Check.
In questo caso, il componente considerato attendibile da Secure Boot è esdiags.efi, una UEFI Shell distribuita come parte del prodotto di diagnostica hardware UEFI Pc-Check di Eurosoft, firmata da una catena di certificati considerata attendibile dalla Microsoft UEFI Third Party Certificate Authority. Una volta eseguita, questa shell espone il comando mm (memory modify) e fornisce quindi capacità di lettura e scrittura arbitraria della memoria durante la fase di avvio pre-OS.
Questa primitiva può quindi essere utilizzata per individuare e annullare il puntatore globale gSecurity2 nel core DXE. Di conseguenza, la successiva verifica delle immagini UEFI viene disabilitata, consentendo il caricamento di applicazioni UEFI non firmate, bootkit, nonostante Secure Boot sia abilitato.
BYOVUA è l'equivalente UEFI della tecnica BYOVD (Bring Your Own Vulnerable Driver) utilizzata a livello di kernel. Invece di portare un driver kernel firmato con una vulnerabilità, l'attaccante porta un'applicazione UEFI firmata - in questo caso, una UEFI Shell completa - che contiene funzionalità in grado di compromettere Secure Boot.
Poiché l'applicazione è firmata con una catena di certificati considerata attendibile da Secure Boot, viene accettata senza riserve, rendendola attendibile su qualsiasi sistema che includa la Microsoft UEFI Third Party Certificate Authority nel proprio database Secure Boot (db) - ovvero praticamente ogni PC con capacità UEFI spedito nell'ultimo decennio. Una volta in esecuzione, i suoi comandi integrati forniscono all'attaccante accesso diretto all'hardware e alla memoria che opera prima del caricamento del sistema operativo, in un ambiente in cui i moderni controlli di sicurezza (ASLR, DEP, protezioni del kernel) semplicemente non esistono.
esdiags.efi è una UEFI Shell distribuita come parte di Eurosoft Pc-Check UEFI, un prodotto di diagnostica hardware pre-boot utilizzato da produttori di PC, organizzazioni di assistenza e team IT per il test di sistemi bare-metal.
| Proprietà | Valore |
|---|---|
| File | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| Vendor | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| Firma | Microsoft Corporation UEFI CA 2011 (Third Party) |
| Scoperta | Eclypsium (Mickey Shkatov, Jesse Michael) - Agosto 2022 |
| Presentazione | DEF CON 30 - "One Bootloader to Load Them All" |
| Revoca | Aggiunta al DBX tramite Microsoft KB5012170 (Agosto 2022) |
La vulnerabilità non è un bug - è un difetto di progettazione. Le UEFI Shell sono strumenti diagnostici legittimi che non erano mai stati pensati per essere eseguiti in ambienti Secure Boot. Tuttavia, firmandole con un certificato considerato attendibile da Microsoft e distribuendole come parte di prodotti commerciali, i vendor hanno inavvertitamente creato un bypass firmato per Secure Boot.
Il problema principale: un binario firmato considerato attendibile da Secure Boot fornisce capacità illimitate di lettura/scrittura della memoria attraverso i suoi comandi integrati. Questa combinazione infrange l'intero modello di fiducia di Secure Boot.
Il comando mm (memory modify) è un comando integrato standard della UEFI Shell che fornisce accesso diretto in lettura e scrittura alla memoria di sistema. È documentato nella UEFI Shell Specification (Sezione 5.3).```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| Parametro | Descrizione |
|-----------|-------------|
| `Address` | Indirizzo di memoria di destinazione |
| `Value` | Valore da scrivere (omettere per sola lettura) |
| `-w` | Larghezza: 1, 2, 4 o 8 byte |
| `-MEM` | Accesso alla memoria di sistema |
| `-MMIO` | I/O mappato in memoria |
| `-IO` | Accesso alla porta I/O |
| `-n` | Non interattivo (nessun prompt per l'indirizzo successivo) |
---
<div id='gsecurity2'/>
### ***gSecurity2 e il Security Architectural Protocol***
La verifica delle immagini Secure Boot in UEFI è imposta tramite i [Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols), definiti nella specifica UEFI Platform Initialization (PI).
Il core DXE (DxeMain) mantiene un puntatore globale chiamato [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252), che punta alla struttura `EFI_SECURITY2_ARCH_PROTOCOL`. Questo protocollo contiene un singolo puntatore a funzione - `FileAuthenticationState` - che viene chiamato da `LoadImage()` ogni volta che viene caricata un'immagine UEFI:```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
Quando viene chiamato LoadImage(), il core DXE verifica:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
Impostando `gSecurity2 = NULL`, il controllo `if` fallisce e `FileAuthenticationState` non viene mai chiamato. La verifica dell'immagine viene completamente saltata - **Secure Boot rimane "abilitato" ma non è più applicato**. Le applicazioni UEFI non firmate possono quindi essere caricate liberamente.