Análisis y explotación de CVE-2025-4275 (Hydr0ph0bia), una debilidad en la cadena de confianza de Secure Boot donde se utilizan variables de firmware para introducir certificados controlados por el atacante que son confiados por componentes de arranque posteriores.
Este repositorio contiene material de investigación relacionado con CVE-2025-4275, una vulnerabilidad de omisión de Secure Boot que afecta al firmware compatible con UEFI basado en Insyde H2O. Centraliza el análisis técnico de la vulnerabilidad, los binarios implicados en el problema, así como documentación y herramientas destinadas a ayudar a los investigadores a comprender mejor, estudiar y experimentar con esta vulnerabilidad tanto en contextos reales como educativos.
CVE-2025-4275 fue descubierta originalmente y divulgada de forma responsable por Nikolaj Schlej, con la coordinación gestionada a través de CERT/CC. Referencias oficiales y de la comunidad:
CVE-2025-4275, apodada Hydroph0bia (un juego de palabras con Insyde H2O), es una vulnerabilidad de omisión de Secure Boot que afecta al firmware compatible con UEFI construido sobre la plataforma Insyde H2O. La vulnerabilidad proviene de un fallo de diseño en el subsistema de actualización de firmware: un certificado de firma destinado a ser cargado en una variable NVRAM volátil por un controlador de confianza puede, en su lugar, ser pre-poblado como una variable no volátil por un atacante, provocando que el firmware confíe en código externo arbitrario como si hubiera sido firmado por la propia Insyde.
Lo que hace que esta vulnerabilidad sea particularmente impactante es la combinación de su simplicidad y su alcance. La explotación solo requiere privilegios de administrador local, suficientes para escribir archivos en la Partición del Sistema EFI y crear variables NVRAM, y afecta a cualquier sistema que ejecute firmware Insyde H2O construido antes del 10 de junio de 2025. El ataque es agnóstico al OEM, lo que significa que se aplica ampliamente a Acer, Dell, Framework, Fujitsu, HP, Huawei, Lenovo y cualquier otro vendedor que distribuya firmware basado en Insyde.
UEFI proporciona una interfaz abstracta para el almacenamiento de variables no volátiles conocido como NVRAM. Una peculiaridad de larga data de esta interfaz es que una variable no volátil con un nombre y GUID determinados puede coexistir con, y eclipsar (shadow), a una variable volátil con la misma identidad. Si el código espera una variable volátil (creada en tiempo de ejecución por un controlador de confianza) pero ya existe una no volátil con el mismo nombre, la versión no volátil puede ser consumida en su lugar. Este comportamiento, a veces llamado shadowing de variables NVRAM, es la base de esta vulnerabilidad.
El subsistema de actualización de firmware de Insyde H2O se basa en dos variables NVRAM para comunicar un certificado de firma entre controladores:
En el flujo esperado, ambas variables son creadas como volátiles por BdsDxe durante el proceso de actualización de firmware. SecurityStubDxe luego las consume para verificar que isflash.bin esté firmado por el certificado de Insyde antes de permitir su ejecución. El fallo crítico es que SecurityStubDxe no valida si estas variables son volátiles o no volátiles antes de confiar en su contenido.
La causa raíz de CVE-2025-4275 es que SecurityStubDxe utiliza una función de biblioteca genérica para leer SecureFlashSetupMode y SecureFlashCertData en lugar de llamar directamente al servicio de tiempo de ejecución GetVariable. Esto significa que no puede distinguir entre una variable volátil establecida por un BdsDxe de confianza y una no volátil pre-poblada por un atacante (para una explicación detallada de esta técnica específica, consulte el siguiente repositorio "TheMalwareGuardian: Exploitation Technique NVRAM Variable Shadowing").
Como resultado, un atacante con privilegios de administrador local puede:
En el siguiente arranque, SecurityStubDxe encontrará ambas variables, las tratará como legítimas y confiará en cualquier ejecutable UEFI firmado con el certificado del atacante, omitiendo efectivamente Secure Boot por completo. No se requiere interacción a nivel de firmware, acceso al hardware ni explotación de una primitiva de corrupción de memoria. La superficie de ataque es simplemente la interfaz de escritura de NVRAM de UEFI, accesible desde una sesión privilegiada del sistema operativo.
La vulnerabilidad fue descubierta durante una revisión de seguridad de un HUAWEI MateBook 14 2023, ejecutando un firmware basado en Insyde H2O con Secure Boot, contraseña de firmware y otras características de seguridad modernas habilitadas. A pesar de estas protecciones, se logró la explotación completa utilizando únicamente privilegios de administrador a nivel de sistema operativo.
La etapa de explotación inicial requiere una pequeña herramienta de Windows (SFCD) que:
Después de reiniciar, SecurityStubDxe lee ambas variables y comienza a confiar en cualquier cosa firmada por el certificado del atacante. Una demostración práctica de esta primera etapa es la carga de un controlador UEFI CrScreenshotDxe firmado con un certificado personalizado, que captura con éxito una captura de pantalla de la pantalla de Configuración del BIOS, con Secure Boot habilitado, como prueba de ejecución de código arbitrario en el entorno del firmware.
Un matiz importante: la variable IhisiParamBuffer presente en CVE-2025-3052 a menudo está bloqueada en plataformas basadas en Insyde, lo que dificulta la explotación directa allí. CVE-2025-4275 no requiere que dicha variable sea escribible y no depende de ninguna primitiva de corrupción de memoria. El ataque funciona en cualquier sistema Insyde H2O donde el atacante pueda escribir en NVRAM, que es el comportamiento predeterminado en firmware sin parchear.
Lo siguiente describe el ataque de extremo a extremo para la etapa inicial de omisión de Secure Boot, asumiendo un atacante privilegiado con acceso a nivel de sistema operativo:
La omisión de Secure Boot lograda en la Parte 1 abre la puerta a una segunda etapa significativamente más impactante: la toma de control total del volumen DXE, lograda secuestrando el propio proceso de actualización de firmware de Insyde.
El subsistema de actualización de firmware en Insyde H2O funciona de la siguiente manera: el actualizador del sistema operativo coloca una cápsula de firmware y la aplicación de actualización firmada (isflash.bin) en la Partición del Sistema EFI, luego establece un indicador SecureFlashTrigger=1 dentro de la variable NVRAM SecureFlashInfo. En el siguiente arranque, el firmware detecta el activador, deshabilita las protecciones de escritura de flash durante PEI y finalmente llama a LoadImage sobre isflash.bin después de verificarlo contra el certificado de Insyde, el mismo mecanismo de certificado que CVE-2025-4275 permite a un atacante reemplazar.
Se requieren tres pasos técnicos adicionales para escalar desde la omisión de Secure Boot hasta la toma de control de DXE:
Una vez que se cumplen las tres condiciones, el firmware se reinicia en modo de actualización, carga el isflash.bin personalizado del atacante (firmado con el certificado del atacante, ahora de confianza debido al SecureFlashCertData eclipsado) y lo ejecuta con el flash SPI desprotegido. Desde esta posición, el atacante puede escribir contenido arbitrario en el volumen DXE, instalando controladores persistentes o modificando componentes del firmware de maneras que sobreviven a la reinstalación del sistema operativo y a la mayoría de los controles de seguridad.
Insyde publicó una corrección como parte del ciclo de parches del 10 de junio de 2025. La corrección fue analizada comparando dos actualizaciones consecutivas del BIOS de Dell (una pre-parche, una post-parche) utilizando informes generados por UEFITool y comparación binaria mediante Diaphora.
Los cambios se concentraron en tres controladores:
La corrección es efectiva bajo la suposición de que un atacante no puede eludir VariablePolicy o LibSetSecureVariable. Sin embargo, la implementación predeterminada de VariablePolicy de EDK2 utiliza un indicador global internamente, que es estructuralmente similar a InsydeVariableLock derrotado en la Parte 2. La edición física de NVRAM mediante hardware de programación SPI también eludiría la corrección por completo, aunque los ataques físicos están convencionalmente fuera del alcance de los modelos de amenaza de Secure Boot.
La remediación recomendada por el investigador, eliminar NVRAM por completo del mecanismo de retransmisión de certificados entre BdsDxe y SecurityStubDxe, fue intentada por Insyde pero causó regresiones y fue diferida a un futuro ciclo de ingeniería.
Cualquier vendedor que distribuya firmware basado en Insyde H2O construido antes del 10 de junio de 2025 está potencialmente afectado. Estado confirmado en el momento de la divulgación:
| Vendedor | Estado |
|---|---|
| Dell | Corregido - Actualizaciones de BIOS publicadas poco después del fin del embargo |
| Lenovo | Vulnerable - correcciones anunciadas, entrega a partir del 2025-07-30 en adelante |
| Framework | Vulnerable - sin estimación de entrega proporcionada en el momento de la divulgación |
| Acer | Sin aviso ni corrección publicados en el momento de la divulgación |
| Fujitsu | Sin aviso ni corrección publicados en el momento de la divulgación |
| HP | Sin aviso ni corrección publicados en el momento de la divulgación |
| Huawei | Vendedor del dispositivo de prueba original - estado de corrección desconocido |
¿Trabajando en algo similar? ¿Investigando UEFI, seguridad del Kernel, explotación u otro tema de seguridad interesante? Si necesitas ayuda para desarrollar un exploit, explorar una técnica, o simplemente quieres intercambiar ideas, no dudes en contactarme. Siempre estoy abierto a discutir investigaciones, ayudar donde pueda y colaborar en proyectos interesantes. No dudes en contactarme en LinkedIn.
