CVE-2025-4275 — Actualizado!
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.
🐞 CVE-2025-4275: Hydroph0bia SecureFlash Certificate Shadowing
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.
📑 Tabla de Contenidos
- Descubrimiento Original y Referencias Oficiales
- Descripción General de la Vulnerabilidad (Análisis, Explotación, PoC)
🧠 Descubrimiento Original y Referencias Oficiales
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:
- Blog del Investigador - Parte 1 (omisión de Secure Boot)
- Blog del Investigador - Parte 2 (toma de control del volumen DXE)
- Blog del Investigador - Parte 3 (análisis del parche)
- Aviso oficial de Insyde (10 de junio de 2025)
- Colección de referencias de la comunidad
🧪 Descripción General de la Vulnerabilidad (Análisis, Explotación, PoC)
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.
🔐 NVRAM y Secure Boot en Insyde H2O
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:
- SecureFlashSetupMode: una variable de activación leída por SecurityStubDxe para activar la verificación basada en certificados.
- SecureFlashCertData: una variable que transporta el certificado de firma en formato EFI_SIGNATURE_LIST, utilizada para autenticar la aplicación de actualización de firmware (isflash.bin).
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.
💣 Shadowing de Variables NVRAM
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:
- Crear una variable de activación SecureFlashSetupMode no volátil antes de que comience el flujo de actualización de firmware.
- Crear una variable SecureFlashCertData no volátil que contenga un certificado controlado por el atacante en formato EFI_SIGNATURE_LIST.
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.
💥 Encontrando y Explotando la Vulnerabilidad
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:
- Adquiere el privilegio SeSystemEnvironmentPrivilege necesario para llamar a SetFirmwareEnvironmentVariable.
- Crea la variable no volátil SecureFlashCertData que contiene un certificado controlado por el atacante.
- Crea la variable de activación no volátil SecureFlashSetupMode establecida en 1.
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.
🎯 Ataque (Parte 1 - Omisión de Secure Boot)
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:
- Generar un certificado personalizado: El atacante genera un par de claves y envuelve el certificado público en formato EFI_SIGNATURE_LIST.
- Establecer las variables NVRAM: Usando la herramienta SFCD desde una sesión de Administrador de Windows, el atacante crea SecureFlashCertData no volátil (que contiene el certificado personalizado) y SecureFlashSetupMode (establecida en 1).
- Firmar un payload: El atacante firma cualquier aplicación o controlador UEFI con su clave privada personalizada.
- Registrar el payload: El payload firmado se registra como un controlador UEFI mediante el mecanismo de opción de arranque DriverXXXX, o se coloca como una entrada de arranque en el Administrador de Arranque de UEFI.
- Reiniciar: En el siguiente arranque, SecurityStubDxe lee las variables NVRAM eclipsadas, confía en el certificado del atacante y permite que el payload firmado se ejecute independientemente del estado de Secure Boot.
🔺 Escalada (Parte 2 - Toma de Control del Volumen DXE)
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:
- Evitar la eliminación de SecureFlashCertData : SecureFlashDxe intenta eliminar la variable del certificado antes de llamar a LoadImage, utilizando una llamada SetVariable desnuda que no puede eliminar las variables especiales Insyde Authenticated Write (AW). El atacante vuelve a establecer el certificado como una variable especial con atributo AW para sobrevivir a este intento de eliminación.
- Desbloquear InsydeVariableLock: VariableRuntimeDxe establece un indicador global (InsydeVariableLock) que impide la creación de variables AW después de que BDS se inicia. Al registrar un controlador UEFI mediante DriverXXXX (que se ejecuta antes de que se active este bloqueo), el atacante localiza el indicador en memoria analizando la cadena de hooks BdsArchProtocol->Entry y lo cambia de 1 a 0.
- Establecer SecureFlashInfo: La variable SecureFlashInfo normalmente está protegida por VariableLockProtocol, pero este bloqueo solo se activa en ReadyToBoot. Un controlador registrado mediante DriverXXXX se ejecuta antes de este evento y puede establecer libremente SecureFlashTrigger=1 para iniciar el flujo de actualización de firmware.
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.
🩹 Corrección (Parte 3 - Análisis del Parche)
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:
- BdsDxe: Reemplazó la llamada desnuda gRT->SetVariable (que no podía eliminar variables especiales con atributo AW) con una llamada LibSetSecureVariable que utiliza comunicación SMM y puede eliminar dichas variables.
- SecureFlashDxe: Aplicó el mismo reemplazo de LibSetSecureVariable, agregó la eliminación explícita de SecureFlashSetupMode y SecureFlashCertData en el punto de entrada del controlador, y registró una VariablePolicy para ambas variables para bloquear su creación desde código a nivel de sistema operativo.
- SecurityStubDxe: Corrección menor no relacionada al manejador de eventos `ExitBootServices; la ruta central de la vulnerabilidad permanece estructuralmente sin cambios.
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.
📦 Vendedores Afectados
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 |
🤝 Investigación y Colaboración
¿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.