Los investigadores de ciberseguridad han descubierto 11 aplicaciones obsoletas de Interfaz de firmware extensible unificada (UEFI) firmadas por Microsoft que pueden explotarse para evitar el arranque seguro en la mayoría de los sistemas que utilizan estándares de firmware modernos.
«Un atacante que explote cualquiera de estas aplicaciones vulnerables podría ejecutar código que no sea de confianza durante el arranque del sistema, lo que podría permitir la implementación de bootkits UEFI maliciosos u otro malware», afirmó el investigador de ESET, Martin Smolár, en un informe publicado hoy.
El cargador de arranque UEFI shim expone las máquinas basadas en UEFI para que confíen en el certificado de autoridad de certificación (CA) UEFI de terceros «Microsoft Corporation UEFI CA 2011» de Microsoft, independientemente del sistema operativo instalado. Este certificado se utiliza para firmar componentes de arranque de terceros que se ejecutan con arranque seguro. Expiró el 27 de junio de 2026 y fue reemplazado por Microsoft UEFI CA 2023 y Microsoft Option ROM UEFI CA 2023.
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 su 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 (principalmente una firma de Microsoft) en la que confía el firmware, ya que el certificado está preinstalado en los dispositivos basados en UEFI.
La secuencia procede de la siguiente manera. El firmware UEFI carga la corrección y verifica su firma con la CA de Microsoft almacenada en el firmware. Luego, la corrección valida el cargador de arranque de segunda etapa (GRUB 2 en la mayoría de los casos) con su propio certificado de proveedor integrado. En última instancia, GRUB 2 verifica el kernel utilizando el mismo certificado de proveedor.
La firma eslovaca de ciberseguridad dijo que el sim obsoleto pero confiable podría explotarse para ejecutar código arbitrario al iniciar el sistema, permitiendo a actores maliciosos implementar kits de arranque UEFI como Bootkitty, HybridPetya y BlackLotus incluso cuando la protección de arranque seguro está habilitada.
Microsoft deshabilitó los cargadores de arranque UEFI del proyecto shim de código abierto (principalmente versiones inferiores a 0.9) como parte de la actualización del martes de parches de junio de 2026 luego de una divulgación responsable a principios de febrero de este año. La lista de cargadores de arranque de SIM afectados se encuentra a continuación.
Spyrus WTGCreator del cargador de cuñas UEFI (0.7 y anteriores) RedHat RedHat Enterprise Linux (7.2) del cargador de cuñas UEFI (0.9) RedHat CentOS (7.2 del cargador de cuñas UEFI (0.9)) Software Baramundi del cargador de cuñas UEFI (0.8) baramundi Management Suite (hasta 2024R1) Cargador de cuñas UEFI (0.7) WhiteCanyon/Blancco WipeDrive (8.0.0 a 8.1.3) UEFI Shimloader (0.7) Junta de Investigación de Matriculación de Finlandia Abitti 1 (1.0) UEFI Shimloader (0.8) NTC IT ROSA, LLC ROSA Linux (R10, R9) UEFI Shimloader (0.9) Oracle America, Inc. OracleLinux (7.2) UEFI Shim Loader (0.9) PC-Doctor, Inc. PC Doctor Service Center (15, 16) (de UEFI Shim Loader (0.9)) OpenSuse OpenSuse UEFI Shim Loader (0.9) OpenSuse de UEFI Shim Loader (0.9) OpenSuse Shim (2.1)
Como resultado de esta laguna jurídica, los atacantes podrían aprovechar estos cargadores de arranque sim susceptibles para eludir nuevos mecanismos de seguridad aprovechando técnicas de ataque «traiga su propio controlador vulnerable» (BYOVD) para ejecutar código arbitrario durante las primeras etapas de arranque, incluso antes de que se inicialice el sistema operativo.
Los sistemas Linux también vienen con una característica de seguridad llamada lista blanca de claves de propietario de máquina (MOK), que permite a los usuarios autorizar la carga de controladores no firmados cuando UEFI Secure Boot está activo. La lista de denegación de MOK se introdujo en la versión 0.9 de shim como una forma de revocar certificados de firma antiguos asociados con archivos binarios UEFI vulnerables y volver a firmar versiones parcheadas.
En esta situación, un atacante podría aprovechar el hecho de que la lista blanca todavía confía en el certificado antiguo y reemplazar la corrección más reciente de la víctima con una corrección UEFI más antigua firmada por Microsoft, evitando la aplicación de la lista de denegación de MOK. Esto podría permitir que el shim de un atacante cargue archivos binarios vulnerables y ejecute código arbitrario.
Eso no es todo. Este ataque también subvierte el Secure Boot Advanced Targeting (SBAT), que está diseñado para desactivar los componentes de arranque vulnerables en lugar de mantener una enorme lista de bloqueo de hashes criptográficos individuales correspondientes a cada archivo. En otras palabras, este 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 se utiliza una versión antigua vulnerable cuando intenta iniciar, el sistema la bloqueará y arrojará un error.
El Centro de Coordinación CERT (CERT/CC) dijo en un aviso emitido el mes pasado que los cargadores de arranque de proveedores específicos no se actualizaron para abordar las vulnerabilidades en los proyectos ascendentes después de que se conocieron y solucionaron públicamente.
«Como resultado, el gestor de arranque vulnerable permaneció firmado y confiado en el sistema Secure Boot porque no había sido revocado a través de la lista de revocación DBX firmada por Microsoft», dice el informe. «Esto podría permitir que componentes de arranque obsoletos y vulnerables se ejecuten en sistemas completamente parcheados, exponiendo la cadena de suministro a riesgos a largo plazo».
Como resultado, un atacante con privilegios administrativos o la capacidad de modificar el proceso de arranque podría aprovechar uno de los cargadores de arranque shim vulnerables enumerados anteriormente para evitar la protección de arranque seguro y ejecutar código arbitrario antes de que se cargue el sistema operativo. Esto podría allanar el camino para una persistencia profundamente arraigada que pueda sobrevivir a reinicios e incluso reinstalaciones del sistema operativo.
Debido a que todo esto sucede antes de que se inicialicen el sistema operativo y los productos de seguridad, el código malicioso que se ejecuta a través del gestor de arranque también puede evadir la detección mediante controles de seguridad integrados y soluciones de detección y respuesta de endpoints (EDR).
El problema se rastrea con los identificadores CVE CVE-2026-8863 y CVE-2026-10797, el último de los cuales se refiere a un problema de corrección de larga duración que permite eludir los mecanismos de revocación basados en certificados modificando el encabezado de firma del cargador de arranque de la segunda etapa.
ESET advierte que la fecha de vencimiento del certificado «Microsoft Corporation UEFI CA 2011» es irrelevante para el proceso de validación de arranque seguro a menos que un gestor de arranque firmado con un certificado vencido sea revocado explícitamente mediante hash.
«Lo que hace que estos viejos simuladores sean peligrosos no son las nuevas vulnerabilidades, sino el hecho de que no requieren nuevas vulnerabilidades para evitar el arranque seguro UEFI», dijo ESET. «Un atacante no necesita primitivas de explotación complejas; todo lo que necesita es 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. Esto es suficiente para evitar características de seguridad críticas como UEFI Secure Boot».
Source link
