Investigadores de ESET han descubierto una vulnerabilidad que permite eludir el UEFI Secure Boot y que afecta a la mayoría de los sistemas basados en UEFI. Esta vulnerabilidad, asignada CVE-2024-7344, se encontró en una aplicación UEFI firmada por el certificado UEFI de terceros de Microsoft Microsoft Corporation UEFI CA 2011. La explotación de esta vulnerabilidad conduce a la ejecución de código no fiable durante el arranque del sistema, lo que permite a los atacantes potenciales desplegar fácilmente bootkits UEFI maliciosos (como Bootkitty o BlackLotus) incluso en sistemas con UEFI Secure Boot habilitado, independientemente del sistema operativo instalado.
La aplicación UEFI afectada forma parte de varias suites de software de recuperación de sistemas en tiempo real desarrolladas por Howyar Technologies Inc., Greenware Technologies, Radix Technologies Ltd., SANFONG Inc., Wasay Software Technology Inc., Computer Education System Inc. y Signal Computer GmbH. A continuación figura la lista de productos de software vulnerables:
- Howyar SysReturn antes de la versión 10.2.023_20240919
- Greenware GreenGuard antes de la versión 10.2.023-20240927
- Radix SmartRecovery antes de la versión 11.2.023-20240927
- Sanfong EZ-back System antes de la versión 10.3.024-20241127
- WASAY eRecoveryRX antes de la versión 8.4.022-20241127
- CES NeoImpact antes de la versión 10.1.024-20241127
- SignalComputer HDD King antes de la versión 10.3.021-20241127
La vulnerabilidad está causada por el uso de un PE loader personalizado en lugar de utilizar las funciones estándar y seguras de UEFI LoadImage y StartImage. Como resultado, la aplicación permite la carga de cualquier binario UEFI - incluso uno sin firmar - desde un archivo especialmente diseñado llamado cloak.dat, durante el arranque del sistema, independientemente del estado de arranque seguro UEFI.
Informamos de nuestros hallazgos al Centro de Coordinación CERT (CERT/CC) en junio de 2024, que se puso en contacto con los proveedores afectados. El problema ya ha sido corregido en sus productos y los antiguos binarios vulnerables fueron revocados por Microsoft en la actualización del martes de parches del 14 de enero de 2025.
Puntos clave de este blogpost:
- Los investigadores de ESET descubrieron una nueva vulnerabilidad, CVE-2024-7344, que permite eludir el arranque seguro UEFI en la mayoría de los sistemas basados en UEFI.
- La explotación de esta vulnerabilidad permite la ejecución de código no fiable durante el arranque del sistema, permitiendo el despliegue de bootkits UEFI maliciosos.
- Están afectados todos los sistemas UEFI con la firma UEFI de terceros de Microsoft activada (los PC con Windows 11 Secured-core deberían tener esta opción desactivada por defecto).
- El problema fue solucionado por los proveedores afectados y los antiguos binarios vulnerables fueron revocados por Microsoft en la actualización del martes de parches del 14 de enero de 2025.
A continuación, figura la cronología coordinada de la divulgación. Nos gustaría dar las gracias al CERT/CC por su ayuda en la coordinación del proceso de divulgación de la vulnerabilidad, y a los proveedores afectados por su comunicación y cooperación fluidas y transparentes durante el proceso de divulgación y corrección de la vulnerabilidad.
Calendario de divulgación coordinada:
- 2024-07-08: ESET encuentra la vulnerabilidad.
- 2024-07-09: ESET informa de la vulnerabilidad al CERT/CC.
- 2024-07-23: CERT/CC aceptó ayudarnos a coordinar el proceso de divulgación de la vulnerabilidad - la fecha de divulgación pública se fijó para el 2024-10-21.
- 2024-08-05: CERT/CC se pone en contacto con los proveedores afectados.
- 2024-08-20: Los proveedores proporcionan el parche inicial para su revisión.
- 2024-08-20: ESET confirmó que el problema reportado se solucionó correctamente, pero descubrió otro problema recientemente introducido con la misma causa raíz.
- 2024-08-28: Los proveedores proporcionaron un segundo parche para su revisión.
- 2024-09-23: Acordamos con Microsoft la nueva fecha de divulgación pública del 14 de enero 2025.
- 2025-01-14: Revocación de las aplicaciones UEFI vulnerables afectadas por parte de Microsoft.
- 2025-01-16: Publicación del blog de ESET.
UEFI Secure Boot en el mundo real
Antes de pasar a describir la vulnerabilidad, echemos un vistazo a cómo funciona la verificación de UEFI Secure Boot en dispositivos reales, y quién es responsable de gestionar las bases de datos de UEFI Secure Boot en ellos.
La lógica básica es bastante simple y se representa en la Figura 1. Cuando el Gestor de Arranque UEFI procede a cargar una aplicación de arranque, como el Gestor de Arranque de Windows, shim, GRUB2, o similar, entre otras comprobaciones, verifica el binario de la aplicación de arranque contra dos bases de datos de Arranque Seguro:
- db - lista de certificados permitidos o hashes PE Authenticode, en los que confía el firmware de la plataforma.
- dbx - lista de certificados prohibidos o hash PE Authenticode.
Las condiciones son que la imagen verificada debe ser de confianza para la db y, al mismo tiempo, el hash del archivo o su certificado no deben figurar en la base de datos dbx. En función de los resultados de la verificación, el gestor de arranque UEFI provoca una violación de la seguridad o ejecuta la imagen verificada.
Para garantizar que el Arranque Seguro UEFI pueda asegurar el proceso de arranque de los principales sistemas operativos en dispositivos UEFI recién adquiridos (por defecto y sin interacción del usuario), la mayoría de los dispositivos vienen con un conjunto de certificados UEFI específicos inscritos en su base de datos db. Aunque estos certificados pueden variar en función del OEM y de los requisitos y la finalidad específicos del dispositivo, en la mayoría de los dispositivos habituales (como portátiles, ordenadores de sobremesa, servidores...), Microsoft pide a los OEM que incluyan los certificados propios de Microsoft. Por eso Microsoft juega un papel importante en la seguridad de la mayoría de estos dispositivos basados en UEFI, ya que con las claves de Microsoft inscritas en db, Microsoft puede gestionar lo que se permite, y lo que no, ejecutar durante el arranque.
Certificados UEFI de Microsoft
Como se explicó anteriormente, muchos dispositivos UEFI vienen con certificados UEFI de Microsoft inscritos. Los siguientes son dos certificados específicos que suelen estar presentes entre los de confianza en dichos dispositivos:
- Microsoft Windows Production CA 2011
- CA UEFI de Microsoft Corporation 2011
Tenga en cuenta que Microsoft debería revocar pronto el certificado Microsoft Windows Production PCA 2011 y sustituirlo por el certificado Windows UEFI CA 2023 (más información), como respuesta a los vulnerables bootloaders de Windows relacionados con el infame bootkit BlackLotus. Los dispositivos Windows nuevos o actualizados ya confiarán en este nuevo certificado. En el caso del certificado UEFI CA 2011 de Microsoft Corporation, parece que sigue utilizándose para firmar nuevas aplicaciones UEFI; sin embargo, también debería sustituirse en el futuro por un nuevo certificado denominado Microsoft UEFI CA 2023. Para cualquier persona interesada en el plan de renovación de certificados UEFI de Microsoft, eche un vistazo a las diapositivas Evolving the Secure Boot Ecosystem presentadas en la UEFI Fall 2023 Developers Conference & Plugfest.
Mientras que el primer certificado (el PCA) es utilizado por Microsoft para firmar sus propias aplicaciones de arranque UEFI, el segundo es utilizado por Microsoft para firmar el software de arranque UEFI desarrollado por terceros, que incluye shims Linux, diversos software especializados de recuperación, copia de seguridad, cifrado de disco o mantenimiento, etc....
Esto significa que cualquiera que esté interesado en que su software de arranque sea compatible por defecto con UEFI Secure Boot puede pedir a Microsoft que firme sus binarios (a través del panel del Centro de desarrollo de hardware de Windows), y si los binarios superan la revisión interna de Microsoft, Microsoft los firma con su certificado UEFI de terceros y, de este modo, los archivos pasan a ser compatibles con la mayoría de los sistemas UEFI, que confían en el certificado de terceros de Microsoft (en los PC con Windows 11 Secured-core, el certificado UEFI de terceros de Microsoft no debe considerarse de confianza por defecto).
A partir de los requisitos de firma de UEFI de Microsoft disponibles en línea, no está claro qué incluye el proceso de revisión interna, aunque sin duda evoca un análisis más profundo en lugar de limitarse a repasar los requisitos enumerados. Aunque creemos que el proceso de revisión manual se está mejorando con el tiempo con cada nueva vulnerabilidad descubierta, una mayor transparencia en lo que realmente se está firmando y en qué comprobaciones incluye este proceso de revisión manual podría aumentar las posibilidades de que binarios tan obviamente vulnerables como el descrito en este informe se descubran y reparen antes.
CVE-2024-7344
Cuando nos encontramos con el paquete de software SysReturn de Howyar el año pasado, lo primero que llamó inmediatamente nuestra atención fue la presencia de un archivo llamado cloak.dat desplegado junto con una aplicación UEFI firmada por Microsoft llamada reloader.efi. A continuación se muestran los hash PE Authenticode de la aplicación vulnerable reloader.efi:
- cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48 (64-bit version)
- e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9 (32-bit version)
En este análisis, utilizamos la versión de 64 bits de reloader.efi. Como se muestra en la Figura 2, el archivo cloak.dat contiene una estructura de datos similar a una cabecera que comienza con la cadena mágica ALRM. A esta cabecera le siguen datos desconocidos que se asemejan visualmente a la estructura de una cabecera de archivo PE/COFF, cifrados mediante un simple cifrado XOR. Es fácil adivinar la clave basándose en la frecuencia de bytes 0xB3, correspondientes a la plétora de bytes 0x00 presentes en las cabeceras PE/COFF normales. Descifrar cloak.dat mediante una operación XOR con la clave 0xB3 revela que, efectivamente, contiene una aplicación UEFI, y además sin firmar.
Rápidamente descubrimos que el binario extraído no es malicioso, pero nos preguntamos: ¿es este binario utilizado de alguna manera por el gestor de arranque de SysReturn durante el arranque del sistema? Si es así, ¿tiene en cuenta el arranque seguro UEFI y se niega a cargar este binario sin firmar si está activado? Después de mirar más profundamente en reloader.efi, encontramos código responsable de cargar el archivo cloak.dat en la memoria y descifrar la imagen incrustada. Como se muestra en la Figura 3, la función intenta cargar el archivo desde una de las siguientes ubicaciones en la partición del sistema EFI:
- \EFI\Microsoft\boot\cloak64.dat
- \EFI\boot\cloak64.dat
- \EFI\Microsoft\boot\cloak.dat
- \Bootbootcloak.dat
Hasta aquí, no habría nada malo en ello. El gestor de arranque podría pasar el buffer que contiene la imagen PE descifrada a la función LoadImage de la UEFI como argumento, lo que aseguraría que la imagen cumple con la política de Arranque Seguro UEFI de la máquina mediante el proceso de verificación descrito en la Figura 1. Desafortunadamente, este no es el caso. Después de descifrar una imagen PE del archivo cloak.dat, el gestor de arranque vulnerable llama a su propia función representada en la Figura 4, responsable de cargar y ejecutar manualmente la imagen sin ninguna comprobación de integridad relacionada con el Arranque Seguro.
En el siguiente vídeo se muestra una prueba de concepto que demuestra la explotación de la vulnerabilidad en un sistema con UEFI Secure Boot activado.
La explotación de esta vulnerabilidad no se limita a los sistemas con el software de recuperación afectado instalado, ya que los atacantes pueden llevar su propia copia del binario vulnerable reloader.efi a cualquier sistema UEFI con el certificado UEFI de terceros de Microsoft inscrito. Además, se requieren privilegios elevados para desplegar los archivos vulnerables y maliciosos en la partición del sistema EFI (administrador local en Windows; root en Linux). Para explotar la vulnerabilidad, un atacante necesitaría:
- Sustituir un binario del bootloader del sistema operativo predeterminado en la partición del sistema EFI (ESP) por el archivo vulnerable reloader.efi.
- Copiar un archivo cloak.dat especialmente diseñado, que contenga una aplicación UEFI maliciosa, en una de las rutas de la ESP soportada por el gestor de arranque vulnerable.
- Reinicia el sistema.
Después de confirmar la vulnerabilidad mediante la creación de una prueba de concepto de trabajo, nos dimos cuenta de que la aplicación vulnerable reloader.efi fue utilizado no sólo por el software de Howyar SysReturn, sino también por varios productos de software de recuperación adicionales. Una lista exhaustiva de los paquetes de software afectados se puede encontrar al principio de este blogpost. Como parecía estar afectado más de un producto desarrollado por distintos proveedores, nos pusimos en contacto con CERT/CC, que nos ayudó a ponernos en contacto con las partes afectadas y a coordinar el proceso de divulgación de vulnerabilidades.
Hasta ahora, no hemos detectado ningún intento de explotación en el mundo real en nuestros datos telemétricos.
Protección y detección
La vulnerabilidad puede mitigarse aplicando las últimas revocaciones UEFI de Microsoft. Los sistemas Windows deben actualizarse automáticamente. El aviso de Microsoft sobre la vulnerabilidad CVE-2024-7344 puede encontrarse aquí. Utilice los siguientes comandos de PowerShell (ejecutados con permisos elevados) para comprobar si está afectado por la vulnerabilidad y si se han instalado las revocaciones necesarias en su sistema:
# Sistemas UEFI; devuelve True si su sistema está afectado por la CVE-2024-7344
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'
# Sistemas UEFI de 64 bits; devuelve True si está protegido (el controlador vulnerable está revocado en su sistema)
[BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
# Sistemas UEFI de 32 bits; devuelve True si está protegido (el controlador vulnerable está revocado en su sistema)
[BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'
En los sistemas Linux, las actualizaciones deberían estar disponibles a través del servicio Linux Vendor Firmware Service. Utilice los siguientes comandos para comprobar si las revocaciones necesarias están instaladas en su sistema:
dbxtool --list | grep 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
dbxtool --list | grep 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'
Mientras que las revocaciones de UEFI protegen eficazmente su sistema contra CVE-2024-7344, existen otras formas más o menos eficaces de protegerse contra (o al menos detectar) la explotación de bootloaders UEFI firmados vulnerables desconocidos y el despliegue de kits de arranque UEFI, incluyendo:
- Acceso gestionado a los archivos ubicados en la partición del sistema EFI. En la mayoría de los escenarios de instalación de kits de arranque UEFI, un atacante necesita modificar el contenido de la partición del sistema EFI para instalar un kit de arranque UEFI o explotar una vulnerabilidad en un loader de arranque UEFI firmado en el sistema objetivo. La mayoría de los productos de seguridad permiten crear reglas de acceso a archivos personalizadas definidas por el usuario que permiten bloquear el acceso a archivos o directorios específicos del sistema (por ejemplo, aquí y aquí).
- Personalización del arranque seguro UEFI. Como se detalla en el informe UEFI Secure Boot Customization de la NSA, la personalización de Secure Boot puede utilizarse para proteger eficazmente contra los kits de arranque UEFI o, al menos, para reducir la superficie de ataque o permitir revocaciones más rápidas de aplicaciones UEFI vulnerables a los propietarios de sistemas si las actualizaciones de revocación oficiales tardan más tiempo. Aunque eficaz, a menudo requiere administradores experimentados (las configuraciones incorrectas de Secure Boot pueden hacer que los sistemas no arranquen temporalmente) y puede ser difícil de gestionar a escala.
- Atestación remota con TPM, donde las mediciones de los componentes de arranque UEFI y la configuración pueden ser validadas contra sus valores buenos conocidos por un servidor remoto de confianza, y por lo tanto utilizadas para detectar modificaciones de arranque no autorizadas.
Conclusión
El número de vulnerabilidades UEFI descubiertas en los últimos años y los fallos a la hora de parchearlas o revocar los binarios vulnerables dentro de un plazo razonable demuestran que ni siquiera una característica tan esencial como el arranque seguro UEFI debe considerarse una barrera impenetrable.
Sin embargo, lo que más nos preocupa en el caso de la vulnerabilidad de la que se informa en este blogpost no es el tiempo que se tardó en arreglar y revocar el binario, que fue bastante bueno en comparación con casos similares, sino el hecho de que no es la primera vez que se descubre un binario UEFI firmado tan obviamente inseguro. En realidad, una aplicación UEFI vulnerable firmada por Microsoft muy similar (CVE-2022-34302), que implementaba su propio PE loader inseguro, fue descubierta hace unos dos años por Eclypsium en One Bootloader to Load Them All.
Esto nos lleva a preguntarnos cómo de común es el uso de estas técnicas inseguras entre los vendedores de software UEFI de terceros, y cuántos otros bootloaders oscuros, pero firmados, puede haber por ahí. Nos pusimos en contacto con Microsoft para informarle de la situación, con la esperanza de que pudiera aportar más transparencia a las aplicaciones UEFI de terceros que firman, para que cualquiera pueda descubrir y denunciar rápidamente estas aplicaciones UEFI obviamente inseguras si pasan por error (o pasaron hace mucho tiempo) la revisión de firma de código UEFI de terceros de Microsoft. Creemos que el despliegue previsto por Microsoft de nuevos certificados UEFI ofrece una gran oportunidad para que esto suceda, impulsando la transparencia de la firma de terceros UEFI y la seguridad UEFI un paso adelante.
Para cualquier consulta sobre nuestra investigación publicada en WeLiveSecurity, por favor contáctenos en threatintel@eset.com.ESET Research ofrece informes privados de inteligencia APT y fuentes de datos. Para cualquier consulta sobre este servicio, visite la página de ESET Threat Intelligence.
IoCs
Como los loaderes vulnerables son parte de paquetes de software legítimos que están potencialmente presentes en miles de sistemas que nunca han sido comprometidos a través de estos loaders, no estamos proporcionando indicadores de compromiso para evitar errores masivos de identificación. En su lugar, los defensores deben seguir los consejos de la sección Protección y detección.
