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.

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.

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.

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.

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.

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.

Fuentes:
https://www.welivesecurity.com/es/investigaciones/uefi-secure-boot-vulnerabilidad-bootkit/