Demuestra el bypass de Secure Boot de CVE-2022-34301 mediante el UEFI Shell firmado por Eurosoft (esdiags.efi), utilizando el comando mm para anular gSecurity2 y cargar aplicaciones UEFI no firmadas.
Eurosoft Pc-Check UEFI Diagnostics 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-34301, una vulnerabilidad de omisión de Secure Boot en el entorno de diagnóstico UEFI Eurosoft Pc-Check.
En este caso, el componente en el que confía Secure Boot es esdiags.efi, un UEFI Shell distribuido como parte del producto de diagnóstico de hardware UEFI Pc-Check de Eurosoft, firmado por una cadena de certificados en la que confía la Autoridad de Certificación de Terceros UEFI de Microsoft. Una vez ejecutado, este shell 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 se deshabilita, 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 está firmada con una cadena de certificados en la que confía Secure Boot, se acepta sin cuestionamientos, lo que la hace confiable en cualquier sistema que incluya la Autoridad de Certificación de Terceros UEFI de Microsoft en su base de datos de Secure Boot (db) - que es prácticamente todos los PC con capacidad UEFI enviados 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.
esdiags.efi es un UEFI Shell distribuido como parte de Eurosoft's Pc-Check UEFI, un producto de diagnóstico de hardware de prearranque utilizado por fabricantes de PC, organizaciones de servicio y equipos de TI para pruebas de sistemas bare-metal.
| Propiedad | Valor |
|---|---|
| Archivo | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| Fabricante | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| 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 diseñadas para ejecutarse en entornos 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.