Investigación sobre CVE-2025-3052, una vulnerabilidad del firmware de Insyde que expone una primitiva de escritura arbitraria capaz de modificar punteros críticos para la seguridad.
Este repositorio centraliza material de investigación relacionado con CVE-2025-3052, una vulnerabilidad de corrupción de memoria en un módulo UEFI firmado con el certificado de terceros de Microsoft que permite a un atacante corromper estructuras de firmware críticas para la seguridad, neutralizar la aplicación de Secure Boot y ejecutar código arbitrario no firmado antes de que se cargue el sistema operativo. Incluye análisis técnico de la causa raíz y la técnica de explotación, binarios vulnerables reales y educativos, y documentación de apoyo destinada a ayudar a los investigadores a comprender, reproducir y experimentar con esta clase de vulnerabilidad.
CVE-2025-3052 fue descubierto originalmente y divulgado de forma responsable por el equipo de investigación de Binarly. Referencias oficiales y de la comunidad:
Este repositorio incluye dos binarios vulnerables, proporcionados con diferentes objetivos de investigación y aprendizaje.
Este binario representa la vulnerabilidad tal como existía en el mundo real.
CVE-2025-3052 es una vulnerabilidad de omisión de Secure Boot que afecta a sistemas UEFI, causada por el manejo inseguro de datos obtenidos de una variable NVRAM dentro de una aplicación UEFI firmada. La vulnerabilidad permite a un atacante corromper estructuras de firmware críticas para la seguridad durante el proceso de arranque, rompiendo efectivamente la cadena de confianza de UEFI y permitiendo la ejecución de código no firmado antes de que se cargue el sistema operativo.
Lo que hace que esta vulnerabilidad sea particularmente impactante no es solo la naturaleza del error en sí, una primitiva de corrupción de memoria, sino el contexto en el que existe: un módulo UEFI firmado con el certificado UEFI de terceros de Microsoft, en el que se confía por defecto en la gran mayoría de los sistemas modernos. Como resultado, la explotación ocurre en una de las etapas de ejecución más tempranas y privilegiadas de la plataforma, antes de los controles de seguridad a nivel del sistema operativo.
Secure Boot es una característica de seguridad fundamental de UEFI diseñada para hacer cumplir la cadena de confianza de la plataforma desde el firmware hasta el sistema operativo. Su propósito principal es evitar que componentes de arranque no autorizados o maliciosos, como los bootkits, se ejecuten durante el proceso de arranque.
A alto nivel, Secure Boot funciona validando criptográficamente los ejecutables UEFI antes de permitir que se ejecuten. Esta validación se realiza utilizando dos bases de datos mantenidas por el firmware:
Se permite la ejecución de una aplicación UEFI si se cumple alguna de las siguientes condiciones:
Por defecto, la mayoría de los sistemas se distribuyen con los siguientes certificados de confianza en db:
Los módulos vulnerables asociados con CVE-2025-3052 fueron firmados utilizando el certificado Microsoft Corporation UEFI CA 2011. Debido a que este certificado es ampliamente confiable en todos los proveedores y plataformas, cualquier aplicación firmada que lo utilice puede ejecutarse en la mayoría de los sistemas UEFI sin interacción del usuario. Esta amplia confianza amplifica significativamente el impacto de una vulnerabilidad dentro de dicho módulo, ya que efectivamente omite las garantías de protección previstas por Secure Boot.
El módulo UEFI vulnerable fue descubierto inicialmente durante el análisis a gran escala de binarios UEFI subidos a repositorios públicos de malware, en particular VirusTotal. Aunque el primer envío público del módulo ocurrió en noviembre de 2024, la inspección de su firma Authenticode reveló que había sido firmado ya en octubre de 2022, lo que indica que el binario podría haber estado circulando durante un período considerable de tiempo antes de su detección.
El nombre de archivo original observado durante el análisis fue Dtbios-efi64-71.22.efi. El examen de las cadenas incrustadas, los metadatos del certificado y el comportamiento del archivo sugirieron fuertemente que el módulo fue desarrollado por DT Research, Inc, un proveedor especializado en dispositivos móviles de computación robustecidos.
La ingeniería inversa adicional reveló que el módulo es una utilidad de flasheo de BIOS, diseñada para leer una imagen de firmware desde el disco y escribirla en la ROM del sistema. Aunque originalmente estaba destinado al hardware de DT Research, el módulo no está restringido a una plataforma específica y puede ejecutarse en cualquier sistema que confíe en el certificado UEFI de terceros de Microsoft.
Una pista crítica durante el reconocimiento fue la presencia de la variable NVRAM IhisiParamBuffer. Esta variable está estrechamente asociada con implementaciones de firmware basadas en Insyde y había estado previamente involucrada en otras vulnerabilidades divulgadas por Binarly (por ejemplo, BRLY-2022-023 y BRLY-2023-005). Su presencia sugirió inmediatamente una clase potencial de problemas relacionados con NVRAM.
La causa raíz de CVE-2025-3052 radica en el uso inseguro de datos leídos de una variable NVRAM sin validación. Específicamente:
Como resultado, un atacante que pueda controlar la variable IhisiParamBuffer obtiene la capacidad de influir en dónde ocurren estas escrituras en memoria. Aunque la primitiva de escritura es algo limitada, normalmente permitiendo escrituras de cero o constantes pequeñas en una dirección arbitraria, sigue siendo lo suficientemente potente como para corromper el estado crítico del firmware.
En la prueba de concepto de Binarly, el ataque apunta a la variable global gSecurity2, que contiene un puntero al Protocolo Arquitectónico Security2 (para una explicación detallada de esta técnica de explotación específica, consulte el siguiente repositorio "TheMalwareGuardian: Exploitation Technique SecureBoot Bypass gSecurity2 Corruption"). Este protocolo es consultado por el servicio LoadImage para hacer cumplir la política de Secure Boot, lo que significa que sobrescribir gSecurity2 con un puntero nulo desactiva efectivamente las comprobaciones de Secure Boot en tiempo de ejecución. De manera crucial, esta omisión es transparente para el sistema operativo: una vez arrancado, Secure Boot todavía parece estar habilitado a nivel del sistema operativo aunque haya sido completamente neutralizado a nivel del firmware.
Un matiz importante es que en plataformas basadas en Insyde, la variable IhisiParamBuffer normalmente está bloqueada como de solo lectura, lo que efectivamente impide la explotación en esos sistemas sin una vulnerabilidad adicional. Irónicamente, esto significa que el proveedor cuyo IBV introdujo el patrón de variable vulnerable en primer lugar es uno de los menos expuestos, mientras que todas las demás plataformas permanecen en riesgo. En los casos en que la variable está bloqueada, se puede encadenar una omisión como BRLY-2023-005 para obtener acceso de escritura a la variable antes de proceder con la explotación. En sistemas donde la variable es directamente escribible, el ataque es sencillo y altamente fiable.
A continuación se describe el ataque de extremo a extremo aprovechando CVE-2025-3052, asumiendo un atacante privilegiado con acceso a nivel del sistema operativo:
Microsoft determinó que 14 módulos UEFI diferentes estaban afectados y mitigó el problema añadiendo sus hashes a la dbx de Secure Boot.
| Nombre del Módulo | Hash SHA-256 Authenticode |
|---|---|
| BiosFlashShell-efi64-80.02.efi | C54A4060B3A76FA045B7B60EEAEBC8389780376BA3EF1F63D417BA1B5528E95 |
| BiosFlashShell-efi64-81.02.efi | CBFAA286144EB2D165A6B17245BAD4F73058436C7292BE56DC6EBA29A369ADDF |
| Dtbios-efi64-70.17.efi | 9D7E7174C281C6526B44C632BAA8C3320ADDD0C77DC90778CC14893882D74618 |
| Dtbios-efi64-70.18.efi | 9B1F35052CFC5FB06DABE5E8F7B747F081DA28D722DB59ADE253B9E38A7A3C76 |
| Dtbios-efi64-70.19.efi | E3CE55E584371D3F2FBCA2241EF0711FF80876EBF71BAB07D8ECEE645A40DCFC |
| Dtbios-efi64-70.20.efi | EE093913ABBD34CB8B5EA31375179A8B55A298353C03AFE5055AA4E8E3F705EF |
| Dtbios-efi64-70.21.efi | B4E1880425F7857B741B921D04FD9276130927CF90A427C454B970E7A2F442F9 |
| Dtbios-efi64-70.22.efi | CDA0B4A59390B36E1B654850428CBB5B4C7B5E4349E87ACDE97FB543736FF1D4 |
| Dtbios-efi64-71.17.efi | C87EFD057497F90321D62A69B311912B8EF8A045FE9C5E6BD5C8C1A4E6F39629 |
| Dtbios-efi64-71.18.efi | 9E19DD645235341A555D6AC0665591453AE13918ECD37DF22DFBEE91EAA9A2DA |
| Dtbios-efi64-71.19.efi | 63F67824FDA998798964FF33B87441857DA92F3A8EE3E04166EEC3156E4E6B82 |
| Dtbios-efi64-71.20.efi | 0BC4F078388D41AB039F87AE84CF8D39302CCBDD70C4ADEE02263EBF6A2DD328 |
| Dtbios-efi64-71.21.efi | E2AEC271B9596A461EB6D54DB81785E4E4C615CFDA5F4504BCC0A329248A4D36 |
| Dtbios-efi64-71.22.efi | 6B4328EBCBE46ED9118FF2D4472DE329D70BA83016DF7A6F50F8AF92342160A1 |
¿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 en lo que pueda y colaborar en proyectos interesantes. No dudes en contactarme en LinkedIn.
