El arranque seguro (Secure Boot), normalmente una barrera impenetrable para el arranque de equipos modernos, acaba de revelar una vulnerabilidad de larga data. Once parches UEFI firmados por Microsoft, pero nunca revocados, permiten a los usuarios eludir este sistema. La amenaza se extiende más allá de Windows y Linux y afecta a casi todos los PC que confían en el certificado de 2011.
Estos gestores de arranque, heredados de versiones anteriores, aún son compatibles con el firmware UEFI. Basta con copiar uno de estos binarios a la partición EFI para eludir la verificación de arranque seguro. Analicemos qué necesitas saber para comprender y contrarrestar esta vulnerabilidad.
Este problema de seguridad genera dudas sobre la confianza depositada en el conocido certificado “Microsoft Corporation UEFI CA 2011”. La crucial monitorización del inicio del sistema se ha visto comprometida por un descuido persistente.
¿Por qué estos adaptadores UEFI representan un riesgo importante para el arranque seguro en 2026?
El arranque seguro se basa en la verificación de cada componente cargado durante el inicio mediante listas: db (autorizado) y dbx (revocado). Microsoft firma los adaptadores con su certificado, que la mayoría de los fabricantes incorpora en la base de datos. Hasta aquí, todo bien.
El truco está en que un parche se firma una sola vez y garantiza la cadena de confianza para los componentes posteriores, como GRUB2 o el kernel de Linux, evitando que Microsoft tenga que firmar cada actualización. ¡Ingenioso, pero un arma de doble filo!
El problema, revelado por el investigador Martin Smolár a través de ESET, es que 11 certificados de seguridad antiguos nunca se han revocado en dbx. Esta inacción hace que el ataque sea sencillo pero efectivo: cualquier máquina que acepte el certificado de 2011 sigue siendo vulnerable.
Shims firmó hace años y nunca se retractó.
Estos gestores de arranque son anteriores a la versión 1.0 (de la 0.7 a la 0.9) y están asociados a diversas soluciones. Entre las vulnerables se encuentran distribuciones comerciales de Linux como Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2 y ROSA Linux. Dos binarios antiguos de openSUSE también se ven afectados.
Otros programas, como PC-Doctor Service Center, baramundi Management Suite, Abitti para el sistema educativo finlandés, así como WipeDrive y Spyrus WTGCreator, también figuran en esta lista. Todos comparten esta firma obsoleta, que nunca ha sido invalidada.
Copiar un archivo shim firmado en la partición de arranque EFI es el equivalente técnico a insertar una llave maestra en la cerradura, eludiendo cualquier protección de alto rendimiento instalada posteriormente.
¿Cómo permiten estas antiguas modificaciones eludir el arranque seguro?
El principal problema es que no se necesita código malicioso nuevo. Simplemente se trata de copiar y pegar un archivo shim original previamente firmado por Microsoft. Independientemente del sistema operativo, Windows o Linux, la cadena de confianza los acepta como legítimos.
Para que un atacante explote la vulnerabilidad, se requiere acceso privilegiado a la máquina. Sin embargo, la persistencia se vuelve muy sencilla, ya que pueden desplegar el shim malicioso sin que la UEFI reaccione.
La analogía con BYOVD (Bring Your Own Vulnerable Driver, Traiga su propio controlador vulnerable) resulta pertinente en este caso. La confianza depositada en el adaptador se convierte en el eslabón débil que puede ser explotado mediante este método.
Casos específicos ilustran el impacto de las calzas obsoletas.
Por ejemplo, el parche de Oracle Linux 7.2 permite una versión de GRUB 2 de la ISO de Oracle Linux 7.1, afectada por la vulnerabilidad CVE-2015-5281. Esto posibilita la ejecución de código arbitrario sin una verificación exhaustiva. No es necesario explotar la corrupción de memoria.
Abitti 0.8 copia un parche que ignora MokListX, la lista de revocación integrada en la versión 0.9, lo que proporciona otro vector de ataque. Red Hat Enterprise Linux 7.2 utiliza un parche anterior a la versión 15.3 (la introducción de SBAT), por lo que no comprueba la política SbatLevel y carga imágenes revocadas sin dudarlo.
Todos estos son ejemplos en los que la supuesta cadena de confianza inviolable se resquebraja sin un esfuerzo heroico, simplemente debido a un componente olvidado.
¿Qué se puede hacer para protegerse contra esta vulnerabilidad de arranque seguro?
La principal recomendación es aplicar las últimas listas de revocación UEFI de Microsoft, distribuidas desde junio de 2026. Estas actualizaciones corrigen la base de datos dbx para designar estos antiguos shims firmados como no deseados.
En Windows, estas actualizaciones se distribuyen principalmente a través de Windows Update. Un pequeño script de PowerShell, proporcionado por ESET, permite verificar que las revocaciones se hayan aplicado correctamente. Una simple comprobación mediante los hashes de los shims defectuosos confirma el estado del sistema.
En Linux, las actualizaciones de la base de datos las gestiona el Servicio de Firmware del Proveedor de Linux. El script uefi-dbx-audit auditará el sistema local. Se recomienda actualizar la base de datos antes de aplicar las revocaciones de DBX para evitar inconsistencias.
Una cuestión de vigilancia y actualización
Este problema demuestra que la seguridad de las startups no solo depende de la validez del certificado, sino también de la revocación rigurosa de los componentes obsoletos. La expiración del certificado de Microsoft en junio de 2026 es irrelevante si la revocación no es efectiva.
El informe de ESET destaca que varias amenazas graves, como los bootkits BlackLotus y Bootkitty, podrían explotar este vector. La prevención no es opcional; es vital para la infraestructura crítica.
Creer que el arranque seguro es invulnerable es exponerse. En materia de seguridad, es mejor ser como un buen granjero: anticiparse a los agujeros en la cerca antes de que el lobo los atraviese.