Los investigadores de ESET identificaron 11 shim bootloaders UEFI antiguos y olvidados, en versiones 0.9 y anteriores, que pueden utilizarse para eludir UEFI Secure Boot en cualquier equipo basado en UEFI que confíe en el certificado de autoridad certificadora (CA) de terceros Microsoft Corporation UEFI CA 2011, independientemente del sistema operativo (OS) instalado. Los shims reportados pueden explotarse para ejecutar código no confiable durante el arranque del sistema, lo que permite a los atacantes desplegar bootkits UEFI maliciosos (como Bootkitty, HybridPetya o BlackLotus) incluso en sistemas con UEFI Secure Boot habilitado. Informamos nuestros hallazgos a CERT/CC en febrero de 2026, y las aplicaciones UEFI vulnerables fueron revocadas en el Patch Tuesday de Microsoft del 9 de junio de 2026.

Aunque se asignaron dos identificadores CVE a este caso para cubrir los shims reportados, CVE-2026-8863 y CVE-2026-10797, la explotación de cada shim reportado no se limita a uno o dos errores específicos presentes directamente en estos shims antiguos. De hecho, la superficie de ataque se amplía por los bootloaders de segunda etapa en los que estos shims confían (principalmente GRUB 2), los cuales —al igual que los propios shims— pueden incluir versiones obsoletas con vulnerabilidades conocidas. Los shims descubiertos provienen de diversas herramientas y paquetes de software, incluidos programas de diagnóstico de PC, distribuciones Linux y otras utilidades basadas en UEFI. Es importante destacar que la explotación no está limitada a sistemas con el software o el OS afectados instalados, ya que los atacantes pueden llevar su propia copia de los shims vulnerables a cualquier sistema UEFI que tenga inscrito el certificado UEFI de terceros de Microsoft.

La lista completa de productos de software que dependen de los shims reportados, junto con sus versiones afectadas, está disponible en la  Vulnerability Note de CERT/CC. Como respuesta al reporte de los investigadores de ESET, los shim bootloaders UEFI con los siguientes hashes PE Authenticode fueron revocados en la actualización de dbx incluida en el Patch Tuesday del 9 de junio:

  • AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961
  • 7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10
  • EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A
  • FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5
  • A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4
  • 95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06
  • 236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B
  • 5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B
  • 8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963
  • 410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373
  • 96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629

Puntos clave de esta publicación

  • Los investigadores de ESET descubrieron 11 aplicaciones UEFI antiguas firmadas por Microsoft que permiten eludir UEFI Secure Boot en la mayoría de los sistemas basados en UEFI.
  • Un atacante que explote una de estas aplicaciones vulnerables puede ejecutar código no confiable durante el arranque del sistema, permitiendo el despliegue de bootkits UEFI maliciosos u otro malware.
  • La explotación no está limitada a sistemas con el software o el OS afectados instalados, ya que los atacantes pueden llevar su propia copia de los binarios vulnerables a cualquier sistema UEFI que tenga inscrito el certificado UEFI de terceros de Microsoft.
  • Todos los sistemas UEFI con habilitada la firma UEFI de terceros de Microsoft están afectados (las Windows 11 Secured-core PCs deberían tener esta opción deshabilitada de forma predeterminada).
  • Los binarios vulnerables fueron revocados por Microsoft en la actualización del Patch Tuesday del 9 de junio de 2026.

A continuación se presenta la cronología de divulgación coordinada. Agradecemos a CERT/CC por su ayuda en la coordinación del proceso de divulgación, y a los proveedores afectados por su comunicación transparente y cooperación durante la mitigación del problema. Para proteger sus sistemas frente a esta amenaza, instale las actualizaciones más recientes de Microsoft dbx. Las instrucciones pueden consultarse en la sección Protección y detección.

Cronología de divulgación coordinada

  • 16-02-2026 – ESET reportó los hallazgos, junto con una prueba de concepto, a CERT/CC.
  • 18-03-2026 – Se fijó el 19 de mayo de 2026 (Patch Tuesday de mayo) como fecha para la actualización de dbx y la divulgación pública.
  • 30-03-2026 – La actualización de dbx y la divulgación pública se pospusieron al 9 de junio de 2026 (Patch Tuesday de junio).
  • 09-06-2026 – Publicación de la actualización de junio de Microsoft y de la Vulnerability Note de CERT/CC.
  • 14-07-2026 – Publicación de la entrada de blog de ESET.

UEFI shim bootloader y UEFI Secure Boot

Para comprender el impacto que estos shims vulnerables pueden tener en sistemas protegidos por UEFI Secure Boot, necesitamos entender cómo funciona UEFI Secure Boot y cómo los shim bootloaders UEFI firmados amplían la cadena de confianza de Secure Boot. En esta sección veremos los conceptos básicos de UEFI Secure Boot, cómo los shims UEFI amplían la cadena de confianza de UEFI Secure Boot y dos funciones relacionadas con los shims: Machine Owner Key (MOK) y Secure Boot Advanced Targeting (SBAT). Para quienes ya estén familiarizados con la teoría, recomendamos saltar directamente a la sección «Cómo eludir el arranque seguro de UEFI utilizando shims antiguos.

UEFI Secure Boot

Como se muestra en la Figura 1, cuando el firmware UEFI carga una aplicación de arranque —como Windows Boot Manager o un shim UEFI— verifica el binario contra dos bases de datos de Secure Boot:

  • db (certificados y hash de Authenticode permitidos) y
  • dbx (certificados y hash de Authenticode prohibidos).
Figure 1. UEFI Secure Boot simplified scheme
Figura 1. Esquema simplificado del arranque seguro de UEFI (fuente: «UEFI Bootkits and Where UEFI Security Fails», p. 48)

La imagen debe ser confiable según db y no estar listada en dbx; de lo contrario, el gestor de arranque activa una violación de seguridad en lugar de ejecutarla.Para que esto funcione de forma predeterminada en dispositivos recién adquiridos con UEFI Secure Boot habilitado, la mayoría de los OEM inscriben un conjunto de certificados UEFI de Microsoft en la base de datos db, concretamente:

  • Microsoft Windows Production PCA 2011 y Windows UEFI CA 2023 (utilizados para firmar las propias aplicaciones de arranque UEFI de Microsoft; el certificado de 2011 se añadirá pronto a dbx como consecuencia de las vulnerabilidades relacionadas con BlackLotus).
  • Microsoft Corporation UEFI CA 2011 y Microsoft UEFI CA 2023 (utilizados para firmar software de arranque UEFI de terceros, como shims de Linux, herramientas de recuperación y utilidades de cifrado de disco).

Esto significa que cualquiera que desee que su software de arranque sea compatible con UEFI Secure Boot de forma predeterminada puede enviar sus binarios a Microsoft para que sean firmados a través del Windows Hardware Dev Center, y una vez aprobados, los archivos firmados pasan a ser confiables en la gran mayoría de los sistemas UEFI. Como resultado, Microsoft desempeña un papel central en la protección de la mayoría de los dispositivos basados en UEFI, decidiendo efectivamente qué está permitido y qué no está permitido ejecutar durante el arranque.

Revocación de UEFI (dbx)

El diseño de revocación de UEFI Secure Boot es sencillo: cuando una aplicación de arranque previamente confiable —aquella cuyo hash PE Authenticode, o el certificado que la firmó, está presente en db— resulta ser vulnerable, su hash PE Authenticode se agrega a dbx, la base de datos de firmas prohibidas administrada por Microsoft (cuyo contenido más reciente suele publicarse en el repositorio de GitHub de Microsoft). Los propios certificados solo se revocan ocasionalmente.Si bien la idea original de revocar binarios vulnerables individuales mediante hash podía ser razonable cuando se introdujo Secure Boot, casos como BootHole y BlackLotus demuestran que este enfoque dista mucho de ser ideal. El problema fundamental es la escala, y queda bien reflejado en la propuesta/especificación SBATdel Red Hat Bootloader Team:

Como parte del reciente incidente de seguridad "BootHole" CVE-2020-10713, se agregaron 3 certificados y 150 hashes de imágenes a la base de datos de revocación dbx de UEFI Secure Boot en la popular arquitectura x64. Este único evento de revocación consume 10 kB de los 32 kB, o aproximadamente un tercio, del almacenamiento de revocaciones normalmente disponible en las plataformas UEFI. Debido a la forma en que UEFI fusiona las listas de revocación, esto, sumado a eventos de revocación anteriores, puede dar lugar a una dbx de casi 15 kB de tamaño, acercándose al 50 % de su capacidad.

La misma presión sobre la capacidad de dbx volvió a manifestarse con las revocaciones relacionadas con BlackLotus de binarios vulnerables de Windows Boot Manager. Ambos casos impulsaron a Microsoft, junto con sus socios, a introducir mecanismos de revocación adicionales basados en versiones, cada uno asociado a uno de los dos bootloaders compatibles con Secure Boot más ampliamente desplegados:

En pocas palabras, mientras que dbxrevoca binarios, SBAT y Secure Boot SVN de Microsoft revocan versiones. Cuando se encuentra una vulnerabilidad en una aplicación UEFI que admite uno de estos mecanismos de revocación basados en versiones, lo que realmente debe bloquearse son todas las builds hasta e incluyendo la vulnerable; y eso puede representarse mediante un número de versión mucho más fácilmente que mediante una larga lista de hashes. Explicamos más sobre SBAT en la sección Secure Boot Advanced Targeting (SBAT).

UEFI shim bootloader y Secure Boot

Con las distribuciones Linux compatibles con UEFI Secure Boot, el mecanismo de Secure Boot descrito anteriormente, construido en torno a las claves de Microsoft, introduce algunos desafíos. Cada distribución Linux genera sus propios binarios de bootloader, y cada uno tiene un hash diferente. Conseguir que Microsoft firme directamente cada bootloader de Linux sería lento, burocrático e impráctico (si no imposible) de mantener para todas las distribuciones Linux.

La solución a este problema es un shim: un bootloader pequeño y minimalista de primera etapa que Microsoft puede revisar y firmar una sola vez, y que luego crea un ancla de confianza secundaria para el resto de la cadena de arranque específica de la distribución Linux, normalmente GRUB 2 y el kernel de Linux. Esta ancla de confianza es otro certificado, denominado vendor certificate (administrado por el proveedor de la distribución), que se agrega al binario del shim antes de que Microsoft lo firme.

En la figura 2 se muestra una secuencia de arranque simplificada en un sistema Linux con Secure Boot habilitado que utiliza un shim.

Figure 2. Simplified UEFI boot flow on Linux systems
Figura 2. Flujo de arranque UEFI simplificado en sistemas Linux

El firmware UEFI carga el shim y valida su firma contra la CA de Microsoft almacenada en el firmware (la variable db). Luego, el shim toma el control y valida el bootloader de segunda etapa (a menudo GRUB 2) contra su propio vendor certificate embebido; por ejemplo, la clave UEFI de Debian para Debian, la clave UEFI de Canonical para Ubuntu o la clave de Red Hat para RHEL y Fedora. A su vez, GRUB 2 valida el kernel utilizando el mismo vendor certificate antes de ceder el control. Cada paso está respaldado criptográficamente por el paso anterior.

Esta indirecta permite que una distribución Linux publique rápidamente actualizaciones del bootloader y del kernel, firmándolas con su propia clave de proveedor, sin necesidad de recurrir a Microsoft para cada actualización. Solo el propio shim requiere una firma de Microsoft, y cambia con poca frecuencia.

Además del vendor certificate, el shim suele contener otro certificado integrado asociado únicamente con la build o binario específico del shim. Este certificado suele denominarse shim certificate y se utiliza para firmar y verificar la integridad de las utilidades del shim que pueden generarse durante el proceso de compilación del shim, como MokManager (utilizado para gestionar MOK y explicado con más detalle más adelante) o el fallback del shim.

Machine Owner Key (MOK)

Al hablar de shims, no podemos pasar por alto otro mecanismo importante que permite que un shim utilice claves externas administradas por el usuario, conocidas como Machine Owner Keys (MOKs). Una allowlist de MOK (puede considerarse una «extensión» específica del shim de la base de datos UEFI db) se almacena en una variable NVRAM de solo arranque llamadaMokList, y una lista de denegación (la «extensión» específica del shim de la base de datos UEFI dbx) se almacena en una variable NVRAM de solo arranque llamada MokListX; se requiere acceso físico para modificar ambas variables en un sistema con UEFI Secure Boot habilitado (las variables de solo arranque solo pueden modificarse durante el arranque, antes de que el cargador del OS invoque la función de servicios de arranque UEFI ExitBootServices). Para gestionar estas listas, el shim utiliza la aplicación UEFI MokManager. Puede encontrarse una guía sobre cómo gestionar MOK aquí. La Figura 3 ilustra cómo un MOK amplía la cadena de confianza de UEFI Secure Boot del shim.

Figure 3. Simplified UEFI boot flow on Linux systems (with Machine Owner Key)
Figura 3. Flujo de arranque UEFI simplificado en sistemas Linux (con Machine Owner Key)

Como describimos en nuestros descubrimientos de BlackLotus y Bootkitty, , debido a la naturaleza no autenticada de las variables NVRAM de solo arranque utilizadas por el mecanismo MOK, los bootkits tienden a abusar de los MOK para lograr persistencia una vez que consiguen eludir UEFI Secure Boot.

Secure Boot Advanced Targeting (SBAT)

Cada aplicación UEFI (componente) que admite SBAT contiene un pequeño conjunto de metadatos en una sección dedicada .sbat de su archivo PE, protegida por la misma firma que el propio binario. Los metadatos identifican el componente (por ejemplo, shim o grub) y le asignan un número de generación que se incrementa cada vez que se publica una corrección de seguridad.

Lo que convierte estos números en un mecanismo de revocación es una política correspondiente en el propio sistema UEFI: una variable UEFI de solo arranque denominada SbatLevel que registra el número mínimo de generación aceptable para cada componente conocido. Fundamentalmente, esta variable es administrada y aplicada por el shim, no por el firmware, lo que permite actualizaciones de revocación más rápidas en comparación con una actualización de dbx. El shim incorpora la política, por lo que su aplicación no depende únicamente de la variable externa e incorpora cualquier política más reciente proporcionada mediante SbatLevel. En cada arranque, el shim primero verifica sus propios metadatos SBAT frente a la política —por lo que puede hacerse que un shim obsoleto se rechace a sí mismo— y luego aplica la misma comprobación a cada binario que carga, rechazando cualquier elemento cuyo número de generación sea inferior al mínimo exigido por la política.

Ejemplos de revocaciones SBAT se muestran en la Figura 4. Estos se tomaron del archivo SbatLevel_Variable.txt ubicado en el repositorio de shim, que sirve como fuente única para las revocaciones SBAT.

Figure 4. Latest SBAT revocations in the shim repository
Figura 4. Revocaciones de SBAT más recientes en el repositorio del shim

El nivel aplicado no está oculto para el OS: el shim publica una copia de solo lectura de SbatLevel en una variable de ejecución denominada SbatLevelRT. El OS puede inspeccionar qué política de revocación está actualmente en vigor, pero no puede modificarla. En Windows, la misma información también está disponible mediante el valor del registro: HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT\SbatLevel.

Eludir UEFI Secure Boot utilizando shims antiguos

Con la teoría sobre la cadena de confianza de Secure Boot de un shim explicada en la sección anterior, ahora podemos centrarnos en el impacto práctico que binarios UEFI olvidados y antiguos, aunque confiables, pueden tener sobre la seguridad de los sistemas UEFI.

Lo ilustramos examinando algunos problemas específicos de los shims reportados: problemas que son fáciles de explotar y que ponen de relieve la amplitud de la superficie de ataque que exponen.

Bootloaders de segunda etapa vulnerables

Cada uno de los shims reportados incorpora tanto un certificado administrado por el proveedor (vendor-managed) como un shim certificate integrado que sirven como ancla de confianza para los bootloaders de segunda etapa o las utilidades del shim: binarios de GRUB 2, MokManager, fallback loaders y, ocasionalmente, otros shims firmados por proveedores que amplían aún más la cadena de confianza. La cantidad de binarios en los que confía un shim determinado varía: desde menos de diez en el caso de software especializado y dedicado hasta cerca de un centenar en el caso de distribuciones Linux ampliamente conocidas.

Las marcas de tiempo de firma y compilación de las aplicaciones en las que confían los shims que reportamos abarcan desde 2013 hasta 2025, suficiente para confirmar que una parte significativa de estos binarios era antigua y probablemente estaba afectada por numerosas vulnerabilidades conocidas públicamente, incluida la ya mencionada BootHole en el caso de GRUB 2. Aunque la mayoría de estos componentes confiables son suficientemente antiguos como para implicar cierto riesgo de seguridad, GRUB 2 parece ser el eslabón más débil. Es una pieza de software compleja y, en consecuencia, las versiones más antiguas acumulan vulnerabilidades.

Consideremos el shim de Oracle Linux, que se encuentra entre los que reportamos. Este confía en binarios firmados mediante un certificado emitido para Oracle Corporation (huella digital SHA‑1: 2E434A724B4759C981E4189AA5AD3D635096DD2F). Uno de los binarios firmados con ese certificado es un binario de GRUB 2 presente en la ISO de instalación de Oracle Linux 7.1 (V74844-01.iso). Este binario está afectado por  CVE-2015-5281, que —citando la nota de vulnerabilidad—: «cuando se utiliza en sistemas UEFI, permite a los usuarios locales eludir las restricciones previstas del arranque seguro (Secure Boot) y ejecutar código no verificado a través de un módulo (1) multiboot o (2) multiboot2 manipulado». Ambos módulos mencionados,  multiboot y multiboot2, permiten cargar código sin firma durante el arranque del sistema mediante los comandos homónimos, y deberían estar prohibidos en binarios de GRUB 2 firmados y compatibles con UEFI Secure Boot, ya que eluden UEFI Secure Boot por diseño.

La explotación es sencilla: no hay errores de corrupción de memoria que desencadenar, ni cadenas ROP que construir, ni ingeniería inversa compleja requerida. El único requisito previo es construir una imagen de kernel personalizada compatible con multiboot2 y sin firma; en la práctica, poco más que un binario ELF que contiene los encabezados requeridos y algunos otros elementos específicos. Una vez que un atacante construye este binario y lo copia a la EFI System Partition (ESP) junto con el shim vulnerable y GRUB 2, un único comando GRUB 2 multiboot2 puede utilizarse para cargarlo y ejecutarlo durante el arranque, con Secure Boot habilitado o no. Una prueba de concepto que demuestra la explotación de CVE-2015-5281 mediante el antiguo shim de Oracle Linux reportado en un sistema con UEFI Secure Boot habilitado (sin los últimos parches de Microsoft aplicados) se muestra en el video a continuación:

Ausencia de funcionalidades más recientes

Con el paso de los años, el shim bootloader UEFI ha evolucionado de forma natural, con nuevas mejoras y funcionalidades de seguridad introducidas en sucesivas versiones del repositorio upstream de «shim» de UEFI. Al mismo tiempo, muchos proveedores externos han tomado versiones disponibles del código fuente de shim para crear sus propios binarios, que posteriormente enviaron a Microsoft para su firma. Este comportamiento es esperado y está alineado con el diseño original de los shims. Sin embargo, no se ha prestado suficiente atención a la revocación de shims obsoletos firmados por Microsoft, muchos de los cuales pueden utilizarse, por diseño, para eludir mecanismos de seguridad más recientes. Ilustramos esta brecha con algunos ejemplos concretos.

Aplicación de la lista de exclusión de MOK

MokList(allowlisting basado en MOK) ha sido compatible con el shim UEFI upstream casi desde el principio (versión 0.3). Sin embargo, las revocaciones MOK (MokListX) comenzaron a aplicarse recién en la versión 0.9. ¿Por qué esto representa un problema? Consideremos el siguiente escenario...

Una organización ha inscrito su propio MOK para firmar herramientas UEFI y bootloaders personalizados que despliega en toda su red. Se descubre una vulnerabilidad en varios de esos binarios y, como respuesta, los administradores revocan el antiguo certificado de firma agregándolo a la denylist de MOK (MokListX). Luego inscriben un nuevo MOK y vuelven a firmar las versiones corregidas de los binarios afectados utilizando la nueva clave. Los binarios antiguos y vulnerables ahora son rechazados por el shim, mientras que los recién firmados se cargan correctamente, por lo que los dispositivos de la organización parecen seguros. El certificado antiguo sigue presente y siendo confiable en MokList, pero está revocado en MokListX, donde se aplica como una regla de mayor prioridad.

En este escenario, un atacante podría reemplazar el shim actualizado de la víctima por un shim UEFI más antiguo firmado por Microsoft de nuestro reporte; por ejemplo, la versión 0.8 incluida en el software Abitti 1, firmada por Microsoft para el Finland's Matriculation Examination Board. Este shim sigue confiando en los certificados almacenados en la variable MokList de la víctima, donde el certificado MOK obsoleto sigue siendo válido, pero ignora MokListX, ya que fue compilado antes de la introducción de la aplicación de la denylist de MOK. Como resultado, el shim del atacante podría utilizarse para cargar binarios vulnerables sin restricciones, permitiendo la ejecución arbitraria de código o la instalación de un bootkit UEFI malicioso.

Aplicación de SBAT

El mismo problema se aplica a SBAT. El soporte para este mecanismo se introdujo upstream en la versión 15.3 de shim, por lo que cualquier shim anterior desconoce su existencia: no lee la política de revocación SbatLevel ni inspecciona la sección .sbat del bootloader de segunda etapa que carga. Como resultado, ignora cualquier revocación SBAT posterior destinada a bloquear componentes vulnerables.

En este caso, el escenario de ataque sería el siguiente: un atacante toma un shim firmado por Microsoft anterior a la versión 15.3 —como el shim versión 0.9  de Red Hat Enterprise Linux 7.2 incluido en nuestro reporte—, lo combina con uno de los varios binarios GRUB 2 en los que el shim todavía confía pero que SBAT ya revocó, y luego copia ambos a la ESP. Durante el arranque del sistema, el shim valida el binario GRUB 2 utilizando su certificado integrado, nunca consulta SBAT y carga el binario vulnerable sin objeciones, dejando al atacante libre para explotar cualquier vulnerabilidad presente en ese binario GRUB 2.

Vulnerabilidades conocidas en shim

Por último, los shims antiguos son simplemente código antiguo, y gran parte del código antiguo contiene vulnerabilidades conocidas. Para ilustrarlo, utilizamos como ejemplo un problema antiguo que afecta a los shims en versión 0.9 e inferiores. Esta vulnerabilidad no tuvo un identificador CVE asignado hasta nuestro reporte, aunque fue corregida y descrita en detalle hace casi exactamente una década en el mensaje de uno de los commits upstream del repositorio de shim, d241bbb. Actualmente se rastrea como CVE-2026-10797.

El problema es que un binario PE firmado con Authenticode registra la longitud de su firma en dos ubicaciones independientes:

  • el directorio de datos de su encabezado PE (IMAGE_DIRECTORY_ENTRY_SECURITY), y
  • su estructura WIN_CERTIFICATE, que encapsula la propia firma.

En los shims afectados, la comprobación de revocación y las funciones de verificación de firma diferían en cuanto a cuál de los valores de tamaño debían considerar confiable. La comprobación de revocación utilizaba el valor del encabezado de la firma, mientras que la función de verificación de firma utilizaba el valor del encabezado PE.

Por lo tanto, es posible eludir el mecanismo de revocación manipulando la estructura WIN_CERTIFICATE del bootloader de segunda etapa para que la función de revocación compare dbx y MokListX contra datos falsos en lugar de contra la firma real del bootloader.

En pocas palabras, aunque el certificado del bootloader de segunda etapa estuviera revocado en dbx o MokListX, el shim no se daría cuenta. Dos comentarios importantes al respecto:

  • este bypass funciona únicamente con revocaciones basadas en certificados (no con las basadas en hash), y
  • el bootloader de segunda etapa debe estar firmado por un certificado integrado en el shim (ya sea el certificado incorporado del propio shim, generado durante su proceso de compilación, o el certificado del proveedor).

Estas limitaciones se deben a que las revocaciones basadas en hash y los certificados no integrados (procedentes de  MokList y db) se verifican en otras partes del código y no se ven afectados por este problema.

¿No se resolvería esto el vencimiento de los certificados UEFI de Microsoft?

Teniendo en cuenta los vencimientos actuales de los certificados UEFI de Microsoft (como se muestra en la Figura 5, Microsoft Corporation UEFI CA 2011 venció el 27 de junio de 2026), podría pensarse que reportar aplicaciones UEFI vulnerables firmadas con este certificado vencido solo genera ruido innecesario.

La realidad es que la fecha de vencimiento de un certificado UEFI no tiene ningún efecto sobre el proceso de verificación de Secure Boot. Si el certificado Microsoft Corporation UEFI CA 2011 permanece en db y no está revocado en dbx, todos los bootloaders válidamente firmados con este certificado vencido seguirán siendo confiables, siempre que no hayan sido revocados explícitamente mediante hash. Esta es la razón por la que Microsoft continuó firmando nuevos envíos con el certificado antiguo hasta su fecha de vencimiento.

Figure 5. Microsoft Corporation UEFI CA 2011 certificate
Figura 5. Certificado «Microsoft Corporation UEFI CA 2011»

Protección y detección

Estos shims vulnerables pueden bloquearse aplicando las revocaciones UEFI más recientes de Microsoft. Los sistemas Windows deberían actualizarse automáticamente. La Figura 6 muestra comandos de PowerShell (que deben ejecutarse con privilegios elevados) para comprobar si las revocaciones necesarias están instaladas en su sistema Windows.

 

$hashes = 
'AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961',
'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',
'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',
'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',
'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',
'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',
'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',
'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',
'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',
'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',
'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629' 
$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'
$notRevoked = $hashes | Where-Object { $dbx -notmatch $_ }
if ($notRevoked) {
    $notRevoked | ForEach-Object { "Hash not revoked: $_" }
} else {
    "All hashes revoked in dbx!"
}

Figura 6. Comandos de PowerShell para comprobar las revocaciones de UEFI

En sistemas Linux, las actualizaciones deberían estar disponibles a través de Linux Vendor Firmware Service, y el estado de las revocaciones puede comprobarse utilizando el script uefi-dbx-audit.

Para recomendaciones más generales sobre cómo protegerse frente a la explotación (o al menos detectar la explotación) de bootloaders UEFI vulnerables firmados y desconocidos y el despliegue de bootkits UEFI, consulte nuestra publicación Under the cloak of UEFI Secure Boot: Introducing CVE-2024-7344.

Conclusión

Lo que hace peligrosos a estos shims antiguos no es una vulnerabilidad novedosa, sino que no se necesita ninguna vulnerabilidad nueva para eludir UEFI Secure Boot. Un atacante no necesita primitivas de explotación complejas; solo una copia de un binario shim antiguo, todavía confiable pero no revocado, y un conocimiento básico de cómo funcionan los shims UEFI. Eso basta para eludir una funcionalidad de seguridad tan esencial como UEFI Secure Boot.

Si bien la revocación de estos 11 shims resolvió el problema inmediato, sigue existiendo un problema más profundo: la visibilidad. El proceso de firma de shims se volvió significativamente más transparente en 2017 con la introducción del repositorio https://github.com/rhboot/shim-review, donde los envíos de los proveedores son revisados por los mantenedores antes de que Microsoft los firme. Todos los shims aprobados desde entonces están documentados, pero los firmados antes de esa fecha no lo están, y nadie puede afirmar con certeza cuántos de esos shims antiguos, todavía confiables, siguen existiendo. Lo que no ha sido catalogado de forma completa y transparente no puede retirarse de forma efectiva.

Como nota positiva, creemos que la tendencia avanza en la dirección correcta. Cada divulgación como esta reduce el conjunto de shims olvidados y, gracias a una mayor transparencia en la firma de shims y a mecanismos como SBAT, el seguimiento de lo que debe revocarse y su revocación efectiva pueden gestionarse de manera mucho más eficiente que en el pasado. El siguiente paso es extender este nivel de transparencia en el ecosistema de firma UEFI de terceros de Microsoft a las aplicaciones UEFI de terceros que no son shims, las cuales, como se ha demostrado repetidamente (por ejemplo,  CVE-2022-34302, CVE-2023-28005, CVE-2024-7344, CVE-2026-25250, ...), también pueden servir como una fuente directa para eludir UEFI Secure Boot.

IoC

Dado que los shims vulnerables forman parte de paquetes de software legítimos que potencialmente están presentes en miles de sistemas que nunca han sido comprometidos mediante estos loaders, no proporcionamos indicadores de compromiso para evitar una identificación errónea masiva. En su lugar, los defensores deberían seguir las recomendaciones incluidas en la sección Protección y detección.

Para cualquier consulta sobre nuestra investigación publicada en WeLiveSecurity, ponte en contacto con nosotros en threatintel@eset.com.
ESET Research ofrece informes privados de inteligencia sobre APT y fuentes de datos. Para cualquier consulta sobre este servicio, visite la página de ESET Threat Intelligence.