11 antiguas cuñas UEFI de Linux firmadas por Microsoft podrían permitir a los atacantes evitar el arranque seguro – CYBERDEFENSA.MX
Los investigadores de ciberseguridad han descubierto 11 aplicaciones antiguas de Interfaz de firmware extensible unificada (UEFI) firmadas por Microsoft de las que se podría abusar para evitar el arranque seguro en la mayoría de los sistemas que utilizan el estándar de firmware moderno.
«Un atacante que explote una de estas aplicaciones vulnerables puede ejecutar código que no es de confianza durante el arranque del sistema, permitiendo la implementación de bootkits UEFI maliciosos u otro malware», dijo el investigador de ESET Martin Smolár. dicho en un informe publicado hoy.
Los cargadores de arranque UEFI exponen cualquier máquina basada en UEFI que confíe en Microsoft «Corporación Microsoft UEFI CA 2011«Certificado de autoridad certificadora (CA) UEFI de terceros, independientemente del sistema operativo instalado. El certificado se utiliza para firmar componentes de arranque de terceros destinados a ejecutarse bajo arranque seguro. Expiró el 27 de junio de 2026 y ha sido reemplazado por Microsoft UEFI CA 2023 y Microsoft Option ROM UEFI CA 2023.
El shim es un gestor de arranque UEFI liviano y de código abierto que actúa como intermediario entre el firmware de la placa base de una computadora y el sistema operativo Linux. Su objetivo principal es permitir que las distribuciones de Linux se inicien cuando el arranque seguro está habilitado. Vale la pena señalar que el shim en sí está firmado con una clave en la que confía el firmware, principalmente una firma de Microsoft, ya que sus certificados vienen preinstalados en dispositivos basados en UEFI.
La secuencia procede de la siguiente manera: el firmware UEFI carga el shim y valida su firma con la CA de Microsoft almacenada en el firmware. Luego, el shim valida el cargador de arranque de segunda etapa (en la mayoría de los casos, GRUB 2) con su propio certificado de proveedor integrado. GRUB 2 finalmente valida el kernel utilizando el mismo certificado de proveedor.
La compañía eslovaca de ciberseguridad dijo que los shims, obsoletos pero confiables, pueden explotarse para ejecutar código arbitrario cuando se inicia el sistema, lo que permite a los delincuentes implementar kits de arranque UEFI como Bootkitty, HybridPetya o BlackLotus incluso cuando las protecciones de arranque seguro están habilitadas.
Desde entonces, Microsoft ha revocado los gestores de arranque UEFI del proyecto shim de código abierto, principalmente de la versión 0.9 y anteriores, como parte de su Actualización del martes de parches de junio de 2026 tras la divulgación responsable a principios de febrero. La lista de los cargadores de arranque afectados se encuentra a continuación:
- Spyrus WTGCreator del cargador de cuñas UEFI (0.7 o inferior)
- RedHat RedHat Enterprise Linux (7.2) desde el cargador de cuñas UEFI (0.9)
- RedHat CentOS (7.2) del cargador de cuñas UEFI (0.9)
- Software Baramundi baramundi Management Suite (hasta 2024R1) desde UEFI shim loader (0.8)
- WhiteCanyon/Blancco WipeDrive (8.0.0 a 8.1.3) del cargador de cuñas UEFI (0.7)
- Junta de Examen de Matriculación de Finlandia Abitti 1 (1.0) del cargador de cuñas UEFI (0.8)
- NTC IT ROSA, LLC ROSA Linux (R10, R9) del cargador de cuñas UEFI (0.9)
- Oracle America, Inc. OracleLinux (7.2) del cargador de cuñas UEFI (0.9)
- PC-Doctor, Inc. Centro de servicio PC Doctor (15, 16) del cargador de cuñas UEFI (0.9)
- OpenSuse OpenSuse UEFI Cargador de cuñas (0.9)
- OpenSuse OpenSuse Shim (2.1) del cargador UEFI Shim (0.9)
Una consecuencia de esta laguna jurídica es que un atacante podría aprovechar estos cargadores de arranque shim susceptibles para eludir los mecanismos de seguridad más nuevos haciendo uso de la técnica de ataque «traiga su propio controlador vulnerable» (BYOVD) para ejecutar código arbitrario durante la fase de arranque inicial, incluso antes de que se inicialice el sistema operativo.
Los sistemas Linux también vienen con una característica de seguridad llamada lista de permitidos de clave de propietario de máquina (MOK) que permite a los usuarios autorizar la carga de controladores no firmados mientras UEFI Secure Boot está activo. Aunque se introdujo una lista de denegados MOK en la versión 0.9 de shim como una forma de revocar certificados de firma antiguos asociados con un binario UEFI vulnerable y volver a firmar versiones parcheadas.
En este contexto, un atacante podría reemplazar el shim actualizado de la víctima con un shim UEFI más antiguo firmado por Microsoft y evitar la aplicación de la lista de denegados MOK aprovechando el hecho de que la lista de permitidos todavía confía en el certificado antiguo. Esto, a su vez, podría permitir que el shim de un atacante cargue binarios vulnerables sin restricciones y obtenga la ejecución de código arbitrario.
Eso no es todo. El ataque también subvierte el Secure Boot Advanced Targeting (SBAT), que está diseñado para revocar componentes de arranque vulnerables en lugar de mantener una enorme lista de bloqueo de hashes criptográficos individuales correspondientes a cada archivo. Dicho de otra manera, el mecanismo se utiliza para actualizar la generación mínima aceptable cada vez que se descubre una vulnerabilidad en un componente de la cadena de arranque. Si un intento de arranque utiliza una versión anterior y vulnerable, el sistema lo bloquea y arroja un error.
El Centro de Coordinación CERT (CERT/CC), en un aviso emitido el mes pasado, dijo que los cargadores de arranque específicos del proveedor no se han actualizado para abordar las vulnerabilidades en el proyecto ascendente después de que se conocieron públicamente y se solucionaron.
«Como resultado, los cargadores de arranque vulnerables permanecieron firmados y confiables para los sistemas de arranque seguro porque no habían sido revocados a través de la lista de revocación DBX firmada por Microsoft», dijo. anotado. «Esto creó una exposición a largo plazo en la cadena de suministro en la que los componentes de arranque obsoletos y vulnerables aún podían ejecutarse en sistemas completamente parcheados».
El resultado es que un atacante con privilegios administrativos o la capacidad de modificar el proceso de arranque podría abusar de uno de los cargadores de arranque vulnerables mencionados anteriormente para eludir las protecciones de arranque seguro y ejecutar código arbitrario antes de que se cargue el sistema operativo, allanando el camino para una persistencia arraigada que puede sobrevivir a los reinicios del sistema operativo y, en algunos casos, a su reinstalación.
Debido a que todo esto ocurre antes de que se inicialicen el sistema operativo y los productos de seguridad, el código malicioso ejecutado a través de los cargadores de arranque también puede eludir la detección mediante controles de seguridad integrados y soluciones de detección y respuesta de endpoints (EDR).
Los problemas se rastrean bajo los identificadores CVE. CVE-2026-8863 y CVE-2026-10797, este último haciendo referencia a un problema de larga data en una corrección que permitía omitir el mecanismo de revocación basado en certificados modificando el encabezado de firma del gestor de arranque de la segunda etapa.
ESET ha advertido que la caducidad del certificado «Microsoft Corporation UEFI CA 2011» no influye en el proceso de verificación de Secure Boot siempre que los gestores de arranque firmados con el certificado caducado no sean revocados explícitamente mediante hash.
«Lo que hace que estas viejas correcciones sean peligrosas no es una vulnerabilidad novedosa, es que no se necesita ninguna vulnerabilidad nueva para evitar el arranque seguro UEFI», dijo ESET. «Un atacante no necesita primitivos de explotación complicados: solo una copia de un binario shim antiguo, aún confiable, pero no revocado y una comprensión básica de cómo funcionan los shims UEFI. Eso es suficiente para eludir una característica de seguridad tan esencial como UEFI Secure Boot».
