themalwareguardian/cve-2022-34303Demuestra el bypass de Secure Boot de CVE-2022-34303 mediante el UEFI Shell firmado por CryptoPro, utilizando el comando mm para anular gSecurity2 y cargar aplicaciones UEFI sin firmar.
CryptoPro Secure Disk UEFI Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Omisión de Secure Boot mediante un UEFI Shell firmado y corrupción de gSecurity2.
Este repositorio demuestra la técnica BYOVUA (Bring Your Own Vulnerable UEFI Application) explotando CVE-2022-34303, una vulnerabilidad de omisión de Secure Boot en el entorno de arranque UEFI de CryptoPro Secure Disk.
En este caso, el componente en el que confía Secure Boot es un shim personalizado firmado por la UEFI Third Party Certificate Authority de Microsoft. Una vez ejecutado, este shim carga un UEFI Shell como segunda etapa, lo que expone el comando mm (memory modify) y, por lo tanto, proporciona capacidades de lectura y escritura arbitraria de memoria durante la fase de arranque previa al sistema operativo.
Esta primitiva puede entonces utilizarse para localizar y anular el puntero global gSecurity2 en el núcleo DXE. Como resultado, la verificación posterior de imágenes UEFI queda deshabilitada, permitiendo que se carguen aplicaciones UEFI no firmadas, bootkits, a pesar de que Secure Boot esté habilitado.
BYOVUA es el equivalente UEFI de la técnica BYOVD (Bring Your Own Vulnerable Driver) utilizada a nivel de kernel. En lugar de traer un controlador de kernel firmado con una vulnerabilidad, el atacante trae una aplicación UEFI firmada - en este caso, un UEFI Shell completo - que contiene funcionalidad capaz de socavar Secure Boot.
Debido a que la aplicación - en este caso, el shim personalizado que carga el UEFI Shell como segunda etapa - está firmada con un certificado de confianza de Microsoft, es aceptada por Secure Boot sin cuestionamientos, lo que la hace confiable en cualquier sistema que incluya este certificado en su base de datos de Secure Boot (db) - que es prácticamente cualquier PC con capacidad UEFI comercializada en la última década. Una vez en ejecución, sus comandos integrados proporcionan al atacante acceso directo al hardware y a la memoria que opera antes de que se cargue el sistema operativo, en un entorno donde los controles de seguridad modernos (ASLR, DEP, protecciones del kernel) simplemente no existen.
Shell_Full.efi es un UEFI Shell distribuido como parte de CryptoPro Secure Disk, un producto de autenticación previa al arranque y cifrado de disco.
| Propiedad | Valor |
|---|---|
| Archivo | Shell_Full.efi = EFI/Boot/BootX64.efi (SHIM) -> EFI/CPSD/Bootxsa.efi (Shell) |
| Fabricante | CryptoPro Secure Disk |
| CVE | CVE-2022-34303 |
| Firma | Microsoft Corporation UEFI CA 2011 (Third Party) |
| Descubrimiento | Eclypsium (Mickey Shkatov, Jesse Michael) - Agosto 2022 |
| Presentación | DEF CON 30 - "One Bootloader to Load Them All" |
| Revocación | Añadido a DBX mediante Microsoft KB5012170 (Agosto 2022) |
La vulnerabilidad no es un bug - es un fallo de diseño. Los UEFI Shells son herramientas de diagnóstico legítimas que nunca fueron concebidas para ejecutarse en entornos con Secure Boot. Sin embargo, al firmarlos con un certificado de confianza de Microsoft y distribuirlos como parte de productos comerciales, los fabricantes crearon inadvertidamente una omisión firmada para Secure Boot.
El problema central: un binario firmado en el que confía Secure Boot proporciona capacidades de lectura/escritura de memoria sin restricciones a través de sus comandos integrados. Esta combinación rompe todo el modelo de confianza de Secure Boot.
El comando mm (memory modify) es un comando integrado estándar del UEFI Shell que proporciona acceso directo de lectura y escritura a la memoria del sistema. Está documentado en la UEFI Shell Specification (Sección 5.3).```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| Parámetro | Descripción |
|-----------|-------------|
| `Address` | Dirección de memoria objetivo |
| `Value` | Valor a escribir (omitir para solo lectura) |
| `-w` | Ancho: 1, 2, 4 u 8 bytes |
| `-MEM` | Acceso a memoria del sistema |
| `-MMIO` | E/S mapeada en memoria |
| `-IO` | Acceso a puerto de E/S |
| `-n` | No interactivo (sin solicitud de siguiente dirección) |
---
<div id='gsecurity2'/>
### ***gSecurity2 y el Protocolo de Arquitectura de Seguridad***
La verificación de imágenes de arranque seguro en UEFI se aplica a través de los [Protocolos de Arquitectura de Seguridad](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols), definidos en la Especificación de Inicialización de Plataforma (PI) de UEFI.
El núcleo DXE (DxeMain) mantiene un puntero global llamado [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252), que apunta a la estructura `EFI_SECURITY2_ARCH_PROTOCOL`. Este protocolo contiene un único puntero a función - `FileAuthenticationState` - que es llamado por `LoadImage()` cada vez que se carga una imagen 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
Cuando se llama a LoadImage(), el núcleo DXE verifica:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
Al establecer `gSecurity2 = NULL`, la comprobación `if` falla y `FileAuthenticationState` nunca se llama. La verificación de imagen se omite por completo - **Secure Boot permanece "habilitado" pero ya no se aplica**. Las aplicaciones UEFI sin firmar pueden cargarse libremente.
Para una comprensión técnica profunda de esta técnica, incluida una aplicación UEFI creada específicamente que localiza y parchea automáticamente gSecurity2, consulte el proyecto complementario: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption).
---