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:
