Secure Boot, una de las principales defensas de Windows y Linux, estuvo comprometido durante diez años y solo ahora se descubrió.

El mecanismo de arranque seguro debe bloquear el código malicioso antes del inicio de Windows o Linux. Sin embargo, los investigadores de ESET descubrieron que la protección pudo eludirse durante casi toda su existencia mediante antiguos archivos de arranque que Microsoft seguía considerando de confianza. Algunos de ellos permanecieron válidos más de diez años después de que se conocieran las vulnerabilidades.

El problema afectaba a componentes especiales llamados shim. Fueron creados para extender el arranque seguro a Linux y a utilidades que se ejecutan antes del sistema operativo. Microsoft firmaba dichos archivos con su firma digital, tras lo cual el firmware del equipo les permitía ejecutarse durante el arranque.

Los investigadores encontraron 11 imágenes vulnerables. El archivo más antiguo conocido apareció en 2013, un año después del lanzamiento del arranque seguro. Las vulnerabilidades en estos componentes eran conocidas desde hace tiempo; sin embargo, Microsoft no las incluyó en las listas de revocación. Como resultado, el equipo seguía confiando en versiones antiguas, aunque los atacantes podían usarlas para ejecutar código no firmado o malicioso.

Para realizar el ataque no se necesitaba una vulnerabilidad nueva ni una técnica compleja. Bastaba con obtener una copia de uno de los archivos shim obsoletos pero aún activos y comprender el esquema general de arranque UEFI. Tras ejecutar dicho componente, el atacante podía romper la cadena de comprobación de firmas e instalar un programa malicioso en una etapa temprana del encendido del equipo.

El peligro afectaba tanto a Linux como a Windows. El shim se destinó originalmente sobre todo a Linux; sin embargo, el firmware UEFI no vincula un archivo de arranque de confianza a un sistema operativo concreto. Si el componente tiene una firma válida de Microsoft, puede ejecutarse también en un equipo con Windows.

Tras eludir el arranque seguro, el atacante obtiene la posibilidad de instalar un bootkit. Así se denomina un programa malicioso que se ejecuta antes del sistema operativo e interfiere en el arranque del equipo. Ese tipo de software es difícil de detectar por un antivirus habitual, ya que comienza a funcionar antes que la mayoría de las medidas de protección.

Un bootkit puede persistir después de reinstalar Windows o Linux e incluso tras sustituir el dispositivo de almacenamiento principal, si el código malicioso se graba en el firmware o en una partición del sistema separada. El atacante obtiene acceso persistente al dispositivo y puede sustituir componentes del sistema, desactivar medios de protección o cargar software adicional malicioso.

Arranque seguro apareció en 2012 precisamente para proteger contra ese tipo de ataques. El mecanismo verifica la firma digital de cada componente que se ejecuta al encender el equipo. Si el archivo no está firmado por un certificado de confianza o ha sido revocado anteriormente, el firmware debe detener el arranque.

A lo largo de los años los expertos han encontrado varios bootkits reales, incluidos LoJax, MosaicRegressor, CosmicStrand y BlackLotus. Algunos se han relacionado con grupos estatales, otros se vendieron en foros clandestinos. La mayoría de estos ataques requieren acceso físico al dispositivo, aunque ciertas cadenas de infección permiten instalar un bootkit de forma remota tras obtener privilegios elevados en el sistema.

Proteger contra el acceso físico de corta duración es una de las funciones del arranque seguro. Por ejemplo, un atacante puede obtener temporalmente un portátil apagado, cargar un componente vulnerable desde un medio externo e instalar código malicioso antes de que el dispositivo vuelva al propietario.

La lista elaborada por CERT incluye archivos shim asociados a Red Hat, openSUSE, Oracle y programas de terceros. Entre ellos había un componente de la empresa finlandesa PC-Doctor, que se utilizó en el sistema de realización de exámenes estatales. Parte de los archivos se publicaron antes de la aparición de los mecanismos modernos de revocación; otros contenían errores en su propio código o permitían la ejecución de componentes de segunda etapa con vulnerabilidades conocidas desde hace tiempo.

En Windows la principal fuente de confianza es el cargador de arranque de Microsoft, firmado con el certificado principal de la compañía. Cada componente siguiente debe pasar la verificación antes de ejecutarse. Linux usa otro esquema, ya que Microsoft no puede firmar por separado todos los cargadores, núcleos y utilidades de cada distribución.

Shim resuelve el problema mediante una capa adicional de confianza. Microsoft firma un pequeño cargador universal, y en su interior el desarrollador de Linux o el proveedor de la utilidad coloca su propio certificado. Tras ejecutarse el shim, este verifica el resto de los componentes del sistema por sí mismo.

Dicha construcción permite a los desarrolladores actualizar Linux sin tener que recurrir constantemente a Microsoft para firmar cada archivo. Al mismo tiempo crea un punto adicional de riesgo. Si un shim vulnerable permanece confiable, su certificado incorporado puede permitir la ejecución de otros componentes inseguros.

Microsoft es responsable de revocar los archivos shim comprometidos. Tras el descubrimiento de una vulnerabilidad, la compañía debe añadir la huella digital del componente o su certificado en una lista especial de prohibiciones. En el caso de las 11 imágenes encontradas no se hizo, y algunas versiones permanecieron válidas más de diez años.

La empresa los revocó solo en el paquete de actualizaciones de junio después de que ESET transmitiera la información a Microsoft y a los especialistas de CERT. Las razones de semejante demora aún no se han revelado.

La gestión de componentes de confianza de arranque seguro es compleja. El firmware utiliza dos bases de datos principales. En db se almacenan los certificados permitidos y las huellas digitales de archivos, mientras que dbx contiene información sobre componentes en los que ya no se debe confiar.

Antes del arranque el sistema verifica ambas listas. El archivo debe tener una firma de la base permitida y al mismo tiempo no figurar entre los componentes revocados. Si un cargador vulnerable permanece en db y no aparece en dbx, el equipo sigue considerándolo seguro.

Agregar directamente cada componente de Linux inseguro a db resultó poco práctico. La base tiene solo 32 KB, y la cantidad de cargadores, núcleos y archivos de utilidad crece constantemente. Por eso los desarrolladores crearon mecanismos de revocación adicionales por versiones.

Uno de ellos se llama Secure Boot Advanced Targeting, o SBAT. En lugar de la huella digital de un archivo individual, el sistema almacena el nombre del componente y el número de su generación. Tras corregir la vulnerabilidad, el desarrollador incrementa el número de versión, y la política de arranque seguro prohíbe la ejecución de todas las generaciones anteriores.

Un principio similar utiliza el indicador Security Version Number, abreviado SVN. Ambos mecanismos permiten revocar de inmediato todo un grupo de compilaciones vulnerables sin llenar la base limitada con un largo listado de hashes.

Cada componente compatible contiene metadatos firmados con nombre y número de generación. Durante el arranque shim compara la información con la versión mínima aceptable. Si el número es inferior al umbral establecido, el archivo no se ejecuta.

La comprobación también se aplica al propio shim. Teóricamente, una política actualizada puede obligar a un cargador obsoleto a rechazar su propia ejecución. Luego el mismo procedimiento se aplica a cada archivo siguiente en la cadena.

El problema consistía en que parte de los componentes hallados aparecieron antes de SBAT y de otros mecanismos modernos de protección. Algunos archivos shim no consultaban las listas de denegación Machine Owner Key, conocidas como la lista MOK de denegación. Otros permitían la ejecución de programas con vulnerabilidades conocidas desde hace tiempo.

Por ejemplo, el shim de Oracle confiaba en un componente secundario vulnerable al ataque CVE-2015-5381. Según ESET, incluso un especialista sin gran experiencia podría aprovechar el error. Algunos archivos contenían defectos propios que permitían eludir la comprobación de la cadena de arranque.

La expiración del certificado de Microsoft tampoco resolvía el problema de forma automática. UEFI sigue confiando en archivos firmados anteriormente hasta que se incluyan en la lista de revocación. Por tanto, la caducidad del certificado con que se firmaron los antiguos componentes shim no bloqueaba por sí sola su ejecución.

Tras instalar las actualizaciones de junio, los archivos vulnerables deberían dejar de funcionar en los dispositivos con Windows afectados. Los equipos Windows 11 de la categoría Secured-core probablemente no estuvieron expuestos al ataque con la configuración por defecto gracias a medidas de protección adicionales.

Los usuarios de Linux deben comprobar las recomendaciones de su distribución y la información en Linux Vendor Firmware Service. También se puede verificar el estado de la base de revocación con el script uefi-dbx-audit. Una sola actualización del sistema operativo puede no ser suficiente si el fabricante aún no ha distribuido la nueva política de arranque seguro para un dispositivo concreto.

La historia de los archivos shim vulnerables muestra el punto débil de todo el modelo. La fiabilidad del arranque seguro depende no solo de la criptografía, sino también del seguimiento constante de miles de componentes firmados. Un cargador olvidado puede conservar la confianza durante años y abrir el camino a código que la protección debía detener.