themalwareguardian/cve-2022-34303Dimostra il bypass di Secure Boot CVE-2022-34303 tramite UEFI Shell firmata CryptoPro, utilizzando il comando mm per annullare gSecurity2 e caricare applicazioni UEFI non firmate.
CryptoPro Secure Disk UEFI 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-34303, una vulnerabilità di bypass di Secure Boot nell'ambiente di boot UEFI di CryptoPro Secure Disk.
In questo caso, il componente fidato per Secure Boot è uno shim personalizzato firmato dalla UEFI Third Party Certificate Authority di Microsoft. Una volta eseguito, questo shim carica una UEFI Shell come secondo stadio, che espone il comando mm (memory modify) e fornisce quindi capacità di lettura e scrittura arbitraria della memoria durante la fase di boot pre-OS.
Questa primitiva può quindi essere utilizzata per individuare e azzerare 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 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 - in questo caso, lo shim personalizzato che carica la UEFI Shell come secondo stadio - è firmata con un certificato fidato di Microsoft, viene accettata da Secure Boot senza obiezioni, rendendola fidata 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, 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.
Shell_Full.efi è una UEFI Shell distribuita come parte di CryptoPro Secure Disk, un prodotto di autenticazione pre-boot e cifratura del disco.
| Proprietà | Valore |
|---|---|
| File | Shell_Full.efi = EFI/Boot/BootX64.efi (SHIM) -> EFI/CPSD/Bootxsa.efi (Shell) |
| Vendor | CryptoPro Secure Disk |
| CVE | CVE-2022-34303 |
| 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 fidato di 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 e fidato per 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.
Per una comprensione tecnica approfondita di questa tecnica, incluso un'applicazione UEFI appositamente creata che individua e corregge automaticamente gSecurity2, consulta il progetto companion: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption).
---
<div id='BYOVD'/>
### ***Parallelismo con il Kernel BYOVD***