Vulnerabilidad en el sistema de arranque seguro de Microsoft permaneció sin detección por más de una década

Qué pasó

Investigadores de la firma de seguridad ESET descubrieron que el estándar Secure Boot de Microsoft, diseñado para proteger dispositivos Windows y Linux contra infecciones de firmware, permaneció vulnerable durante 13 de sus 14 años de existencia. La falla fue identificada tras detectarse once imágenes de firmware conocidas como shims, al menos una de ellas fechada en 2013, que fueron catalogadas como defectuosas pero que nunca fueron revocadas por la compañía.

Los shims son componentes desarrollados originalmente para extender la compatibilidad de Secure Boot a dispositivos Linux y software de utilidades. Microsoft, responsable de la firma y validación de estos componentes, no retiró las imágenes defectuosas una vez conocidas sus vulnerabilidades, lo que abrió una puerta de entrada a atacantes con conocimientos técnicos básicos.

De acuerdo con Martin Smolár, investigador de ESET, lo peligroso de estos shims obsoletos no reside en una vulnerabilidad nueva, sino en la ausencia de revocación. Un atacante no necesita explotar primitivas complejas, solo una copia de un shim antiguo, aún confiable y no revocado, y una comprensión básica de su funcionamiento. Eso basta para eludir una característica de seguridad esencial como UEFI Secure Boot, señaló el especialista.

Una vez instalado el shim comprometido, un atacante puede subvertir la cadena de validación digital del firmware e instalar firmware malicioso que se ejecuta en las etapas iniciales del proceso de arranque. Este código persiste incluso si el sistema operativo es reinstalado o si la unidad de disco duro es reemplazada.

La lista de los once shims identificados por CERT incluye componentes utilizados por distribuidores Linux como Red Hat, openSUSE y Oracle, además de software de terceros como el sistema de la Junta de Examen de Matriculación de Finlandia, desarrollado por PC-Doctor. Muchos de estos archivos fueron creados antes de la existencia de protecciones adicionales como SBAT y las listas de denegación MOK.

Contexto

Secure Boot fue introducido en 2012 con el objetivo específico de mitigar la amenaza de los bootkits, programas maliciosos que se instalan en el firmware del dispositivo y se activan antes que el sistema operativo. Sin este mecanismo de protección, atacantes con acceso físico breve al equipo, incluso apagado, pueden instalar códigos maliciosos de persistencia profunda.

El problema de los bootkits no es teórico. Desde 2018 se han documentado múltiples campañas activas en entornos reales, entre ellas LoJax, vinculada a actores estatales rusos; MosaicRegressor, detectada en 2020; CosmicStrand, identificada en 2022; y BlackLotus, aparecida en 2023. Otras familias de malware de este tipo incluyen ESpecter, FinSpy y MoonBounce.

El estándar Secure Boot forma parte de la especificación UEFI (Unified Extensible Firmware Interface), el firmware que reemplaza al tradicional BIOS en las placas madre modernas. Su función es verificar criptográficamente que cada componente cargado durante el arranque esté firmado digitalmente por una entidad confiable, estableciendo así una cadena de confianza desde el hardware hasta el sistema operativo.

La mayoría de estas amenazas de bootkit requiere acceso físico al dispositivo objetivo, un escenario que Secure Boot está explícitamente diseñado para mitigar. Sin embargo, la omisión de Microsoft al no revocar los shims defectuosos anuló precisamente la protección que el estándar prometía ofrecer.

Impacto para empresas chilenas

En Chile, donde la adopción de Secure Boot es generalizada en equipos corporativos, educativos y gubernamentales, la vulnerabilidad representa un riesgo relevante para la seguridad de la infraestructura tecnológica de empresas e instituciones públicas. Los shims identificados afectan tanto a equipos con Windows como a aquellos basados en distribuciones Linux ampliamente utilizadas en servidores y entornos de desarrollo.

Para las empresas chilenas, particularmente aquellas que manejan información financiera, datos de clientes o infraestructura crítica, la implicancia es directa. Un atacante con acceso físico a un computador corporativo podría instalar firmware malicioso que sobrevive a formateos y reemplazos de disco, comprometiendo la confidencialidad e integridad de la información.

El sector financiero local, los organismos públicos y las empresas de servicios que operan bajo marcos regulatorios de protección de datos deben evaluar urgentemente la exposición de sus flotas de equipos a esta vulnerabilidad. Las recomendaciones de mitigación incluyen la actualización de firmware, la verificación de listas de revocación y, en casos críticos, la auditoría física de dispositivos.

Adicionalmente, la revelación subraya la dependencia del ecosistema tecnológico chileno respecto de proveedores globales de software y firmware. La cadena de suministro de componentes de seguridad digital sigue concentrada en un número reducido de actores, lo que deja al mercado local expuesto a fallas sistémicas originadas fuera de su jurisdicción.

Qué sigue

Microsoft enfrenta el desafío técnico y logístico de revocar de manera efectiva los once shims identificados y de establecer procesos que eviten la repetición de este tipo de omisiones en el futuro. La empresa deberá coordinar con distribuidores Linux y fabricantes de hardware la implementación de las listas de denegación SBAT y MOK ya disponibles.

Para el ecosistema tecnológico global, el incidente reitera la necesidad de mecanismos automatizados de revocación de certificados y firmas digitales en la cadena de suministro de firmware. La confianza en estándares de seguridad como UEFI Secure Boot depende de procesos de mantenimiento que, según este caso, pueden presentar fallas durante periodos prolongados sin que la industria lo detecte.