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.
| 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) |
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.
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.