themalwareguardian/cve-2022-34302Demuestra CVE-2022-34302, un bypass de Secure Boot mediante el bootloader firmado de New Horizon Datasys cuyo cargador PE/COFF personalizado integrado ejecuta aplicaciones UEFI no firmadas.
New Horizon Datasys Reboot Restore Boot Loader - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Omisión de Secure Boot mediante un cargador de arranque firmado con un cargador PE/COFF personalizado integrado que carga aplicaciones UEFI sin firmar.
Este repositorio demuestra la técnica BYOVUA (Bring Your Own Vulnerable UEFI Application) explotando CVE-2022-34302, una vulnerabilidad de omisión de Secure Boot en el cargador de arranque de New Horizon Datasys.
A diferencia de las vulnerabilidades basadas en el UEFI Shell (CVE-2022-34301 y CVE-2022-34303), este cargador de arranque no expone un UEFI Shell. En su lugar, shdloader.efi implementa su propio cargador PE/COFF personalizado que carga un binario de segunda etapa (shdmgr.ef_) sin utilizar la función LoadImage() del firmware y sin realizar ninguna verificación de firma. Un atacante solo necesita reemplazar shdmgr.ef_ con cualquier aplicación UEFI compatible para lograr la ejecución de código arbitrario con Secure Boot habilitado.
Esta es la más peligrosa de las tres vulnerabilidades divulgadas en la investigación "One Bootloader to Load Them All". Como señaló Eclypsium: la omisión está integrada, es completamente silenciosa y no deja ninguna indicación visual en la pantalla, lo que la hace invisible incluso en sistemas con monitor e indetectable en sistemas sin cabeza como servidores o equipos industriales.
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 que contiene funcionalidad capaz de socavar Secure Boot.
Debido a que shdloader.efi está firmado con un certificado de confianza de Microsoft, Secure Boot lo acepta sin cuestionamientos, lo que lo 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 enviada en la última década. Una vez en ejecución, su cargador PE personalizado integrado proporciona al atacante la capacidad de cargar y ejecutar código arbitrario sin firmar 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.
shdloader.efi es un cargador de arranque UEFI distribuido como parte de los productos de restauración y recuperación del sistema de New Horizon Datasys (Reboot Restore Rx, RollBack Rx). Su función en la cadena de arranque legítima es cargar un componente de gestión pre-SO (shdmgr.ef_) que maneja operaciones de instantáneas y restauración antes de que se inicie el sistema operativo.
La vulnerabilidad es un defecto de diseño en la arquitectura del cargador de arranque. En lugar de utilizar los servicios de arranque del firmware LoadImage() y StartImage(), que aplican la verificación de firmas de Secure Boot, shdloader.efi implementa su propio cargador PE/COFF personalizado que lee, reubica y ejecuta shdmgr.ef_ directamente desde los bytes sin procesar del disco, omitiendo por completo las comprobaciones de seguridad del firmware.
El problema central: un binario firmado que es confiable para Secure Boot contiene su propio cargador de imágenes que no verifica firmas. El firmware valida shdloader.efi como firmado, pero una vez que se está ejecutando, carga shdmgr.ef_ sin ninguna verificación. Reemplazar shdmgr.ef_ con una aplicación UEFI arbitraria da como resultado que esa aplicación se ejecute con acceso completo al hardware, mientras Secure Boot se reporta como habilitado.
| Propiedad | Valor |
|---|
| Archivo | shdloader.efi = EFI/Boot/bootx64.efi |
| Fabricante | New Horizon Datasys Inc |
| Producto | Reboot Restore Rx / RollBack Rx |
| CVE | CVE-2022-34302 |
| Firma | Microsoft Windows UEFI Driver Publisher → Microsoft Corporation UEFI CA 2011 |
| 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) |
Esto es fundamentalmente diferente de CVE-2022-34301 y CVE-2022-34303, donde el atacante necesita interactuar con un UEFI Shell y corromper manualmente gSecurity2 para deshabilitar la verificación. Aquí, la omisión es automática y silenciosa: sin interacción del usuario, sin salida visible, sin prompt de shell.
El shdloader.efi firmado contiene su propia implementación de un cargador de imágenes PE/COFF. En lugar de llamar al servicio de arranque LoadImage() del firmware, que invocaría los Security Architectural Protocols y verificaría la firma de la imagen contra la base de datos de Secure Boot, el cargador de arranque:
\EFI\Boot\shdmgr.ef_ usando el EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.reloc y aplica las reubicaciones baseEn ningún momento de este proceso el cargador verifica la firma Authenticode de la imagen, comprueba la base de datos de Secure Boot (db/dbx) ni invoca el EFI_SECURITY2_ARCH_PROTOCOL. La imagen se carga únicamente en función de su validez estructural 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);
// Step 3: Parse PE/COFF headers
DosHeader = (EFI_IMAGE_DOS_HEADER *)Buffer;
PeHeader = (EFI_IMAGE_NT_HEADERS *)(Buffer + DosHeader->e_lfanew);
// Step 4: Allocate memory and copy sections
ImageBase = AllocatePages(...);
CopySections(ImageBase, Buffer, PeHeader);
// Step 5: Apply base relocations from .reloc
Delta = ImageBase - PeHeader->OptionalHeader.ImageBase;
ApplyRelocations(ImageBase, PeHeader, Delta);
// Step 6: Jump to entry point
// NO SIGNATURE VERIFICATION ANYWHERE
EntryPoint = ImageBase + PeHeader->OptionalHeader.AddressOfEntryPoint;
((EFI_IMAGE_ENTRY_POINT)EntryPoint)(ImageHandle, SystemTable);
}
---
<div id='LoadImageVsCustomLoader'/>
### ***LoadImage vs Custom Loader***
La diferencia entre `LoadImage()` del firmware y el cargador personalizado es la brecha de seguridad crítica:```
┌─────────────────────────────────────────────────────────────────────────┐
│ Firmware LoadImage() - How legitimate boot chains work │
│ │
│ bootx64.efi ──> LoadImage("shdmgr.ef_") │
│ │ │
│ ├── Parse PE/COFF headers │
│ ├── Verify Authenticode signature │
│ ├── Check signature against db (allowed) │
│ ├── Check hash against dbx (revoked) │
│ ├── Call gSecurity2->FileAuthenticationState() │
│ │ │ │
│ │ ├── Signature valid? ── YES ──> Load image │
│ │ └── Signature invalid? ── NO ──> REJECT │
│ └── StartImage() │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ Custom PE Loader - What shdloader.efi does │
│ │
│ shdloader.efi ──> OpenFile("shdmgr.ef_") │
│ │ │
│ ├── ReadFile() into buffer │
│ ├── Parse PE/COFF headers │
│ ├── Allocate memory │
│ ├── Copy sections │
│ ├── Apply .reloc relocations │
│ ├── *** NO SIGNATURE CHECK *** │
│ └── Jump to EntryPoint │
│ │
│ Result: ANY valid PE/COFF EFI application runs, signed or not │
└─────────────────────────────────────────────────────────────────────────┘
El cargador PE personalizado es una implementación simplificada y espera un diseño PE/COFF específico. Los binarios que no cumplen con esto son rechazados con errores:``` Reloc table overflows binary Relocation failed Invalid entry point
Un binario al que le falte cualquiera de estos será rechazado por el cargador personalizado.
| Campo | Valor requerido | Motivo |
|-------|---------------|--------|
| *Machine* | `0x8664` (x64) | El cargador solo admite imágenes x86-64 |
| *Subsystem* | `10` (EFI Application) | Debe ser una EFI Application |
| *sección .reloc* | `.reloc` debe existir con entradas de reubicación base válidas | El cargador realiza su propia reubicación de imagen. Sin .reloc, falla con "Reloc table overflows binary" |
| *Relocation Directory* | `VirtualAddress` != 0, Size != 0 (DATA_DIRECTORY[5]) | La entrada del directorio debe apuntar a datos de reubicación válidos |
Se proporciona un script de verificación (Scripts/VerifyPE.py) para comprobar la compatibilidad antes del despliegue.
---
<div id='BYOVD'/>
### ***Paralelismo con Kernel BYOVD***
El paralelismo estructural entre UEFI BYOVUA y kernel BYOVD es exacto, aunque CVE-2022-34302 representa la forma más directa: el componente firmado **en sí mismo** carga código no firmado, en lugar de proporcionar una primitiva para deshabilitar la verificación:```
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA - CVE-2022-34302 (Custom PE Loader) │
│ │
│ Signed Bootloader ──> Custom PE Loader ──> Load unsigned │
│ (trusted by (no sig check) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ UEFI BYOVUA - CVE-2022-34301/34303 (Shell + gSecurity2) │
│ │
│ Signed Shell ─ mm ─> gSecurity2 = NULL ─> Load unsigned │
│ (trusted by (Security2 Protocol) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ Kernel BYOVD (DSE Bypass) │
│ │
│ Signed Driver ─ IOCTL ─> g_CiOptions = 0 ─> Load unsigned │
│ (trusted by (CI.dll) kernel drivers │
│ DSE / CI) │
└──────────────────────────────────────────────────────────────┘
CVE-2022-34302 es la variante más peligrosa porque el bypass es inherente al diseño del bootloader - no hay un paso intermedio donde el atacante necesite corromper un mecanismo de seguridad. El componente firmado carga directamente código no firmado como su operación normal.
El shdloader.efi firmado se coloca en la Partición del Sistema EFI (ESP) como el bootloader predeterminado. Debido a que está firmado por el certificado UEFI Driver Publisher de Microsoft, Secure Boot lo valida y lo carga sin problemas.```
EFI System Partition (ESP)
└── EFI/
└── Boot/
└── bootx64.efi (shdloader.efi) ← Signed by Microsoft Windows UEFI Driver Publisher
└── shdmgr.ef_ (PAYLOAD) ← Unsigned, loaded by shdloader's custom PE loader
Cuando el sistema arranca, el firmware:
1. Lee `bootx64.efi` desde la ESP
2. Llama a `LoadImage()`, que verifica la firma Authenticode contra la base de datos de Secure Boot
3. La firma coincide con el certificado Microsoft UEFI CA 2011 en la `db` → la imagen es aceptada
4. Llama a `StartImage()` para transferir la ejecución a `shdloader.efi`
---
<div id='Phase2'/>
### ***Fase 2 - El cargador PE personalizado se activa***
Una vez que `shdloader.efi` tiene el control, imprime un mensaje de diagnóstico y activa inmediatamente su cargador PE/COFF personalizado:```
Booting in insecure mode
El gestor de arranque entonces:
\EFI\Boot\shdmgr.ef_ usando el protocolo del sistema de archivos.text, .data, .reloc, etc.) a la memoria asignadaLoadAddress - ImageBase) y aplica todas las reubicaciones base desde la sección .relocLoadAddress + AddressOfEntryPoint como el objetivo de ejecuciónNo se realiza ninguna verificación de firma en ningún punto de este proceso. El cargador no llama a LoadImage(), no invoca gSecurity2->FileAuthenticationState() y no comprueba las bases de datos db ni dbx. El archivo se carga únicamente en función de su validez estructural.
Si no se encuentra el archivo, el gestor de arranque informa:``` Failed to open \EFI\Boot\shdmgr.ef_ - 800000000000000E Failed to load image
---
<div id='Phase3'/>
### ***Fase 3 - Ejecución de código no firmado***
El cargador personalizado salta al punto de entrada de `shdmgr.ef_`. La aplicación UEFI no firmada ahora se ejecuta con:
- Acceso completo al hardware (memoria directa, puertos de E/S, PCI, MMIO)
- Ningún sistema operativo cargado todavía
- Sin ASLR, DEP ni protecciones del kernel
- Sin EDR ni monitoreo de seguridad de endpoint
- Secure Boot reportado como **habilitado** a cualquier consulta posterior del SO
El ataque es completamente silencioso. A diferencia de CVE-2022-34301 y CVE-2022-34303, que muestran un prompt visible del UEFI Shell, este exploit no produce ninguna salida visual más allá del mensaje "Booting in insecure mode" (que, en un sistema legítimo, aparece brevemente y es reemplazado rápidamente por la pantalla de arranque del SO). En sistemas sin cabeza (servidores, IoT, equipos industriales), no hay indicación alguna.
---
<div id='Phase4'/>
### ***Fase 4 - Persistencia***
El ataque es persistente por defecto. Mientras `shdloader.efi` permanezca en `\EFI\Boot\bootx64.efi` y el payload del atacante permanezca en `\EFI\Boot\shdmgr.ef_` en la ESP, el payload no firmado se ejecuta en cada arranque.
No se necesita ningún script `startup.nsh`. No es necesario recalcular ninguna dirección de gSecurity2 a través de actualizaciones de firmware. El cargador PE personalizado carga cualquier `shdmgr.ef_` que encuentre, incondicionalmente.
El sistema continúa reportando Secure Boot como "habilitado" - solo la cadena de confianza ha sido rota a nivel del bootloader. Esto hace que el ataque sea invisible para las consultas de estado de Secure Boot a nivel del SO y para cualquier software de seguridad que dependa de la atestación de Secure Boot.
> **Importante:** La persistencia se rompe solo si la DBX se actualiza con la entrada de revocación para `shdloader.efi` (KB5012170), lo que hace que el firmware rechace `shdloader.efi` antes de que el cargador personalizado se active.
---
---
---
<div id='Exploit'/>
## ***Exploit***
El directorio `Exploit/` contiene todo lo necesario para construir un `shdmgr.ef_` compatible:```
Exploit/
|
├── README.md ← Build guide and PE/COFF requirements
|
├── PayloadShdmgr/
| |
│ ├── ForceReloc.nasm ← Force .reloc section generation
│ ├── shdmgr.ef_.c ← UEFI application source (EDK2)
│ ├── shdmgr.ef_.inf ← EDK2 module definition
│ ├── shdmgr.ef_.dsc ← EDK2 platform build configuration
│ └── shdmgr.ef_.dec ← EDK2 package declaration
|
└── Scripts/
└── VerifyPE.py ← PE/COFF compatibility verifier
El gestor de arranque firmado se ha añadido a la lista de revocación DBX de Microsoft mediante KB5012170 (agosto de 2022). En los sistemas actualizados, el gestor de arranque será rechazado por Secure Boot antes de que el cargador PE personalizado llegue a activarse.
Para el entorno de laboratorio, se necesita un sistema en el que:
El QEMU UEFI Research Environment proporciona una configuración automatizada para esto.
CVE-2022-34302 es más sencillo de explotar que CVE-2022-34301 y CVE-2022-34303:
| Aspecto | CVE-2022-34302 (Cargador personalizado) | CVE-2022-34301/34303 (Shell) |
|---|
| Técnica | Reemplazar shdmgr.ef_ con el payload | Corromper gSecurity2 mediante el comando mm |
| Interacción | Ninguna (totalmente automática) | Comandos de shell manuales o startup.nsh |
| Visibilidad | Silenciosa ("Booting in insecure mode") | Prompt visible del UEFI Shell |
| Dependencia del firmware | Ninguna (el payload es autocontenido) | La dirección de gSecurity2 cambia según la compilación del firmware |
| Complejidad | Baja (reemplazo de archivo) | Media (escaneo y parcheo de memoria) |
| Sigilo | Alto (sin salida visual en modo headless) | Bajo (shell visible en pantalla) |