La grieta en el templo de UEFI: Cómo 11 'shims' olvidados desarman la seguridad antes de que arranque tu sistema

Imaginemos un búnker diseñado para resistir un ataque nuclear. Sus paredes tienen metros de hormigón armado, las puertas son de acero macizo y los sistemas de autenticación biométrica custodian cada acceso. Sin embargo, el sargento de guardia decide dejar una llave maestra antigua, de un modelo descatalogado pero que todavía encaja en la cerradura trasera, guardada en una caja de herramientas sin cerrar junto a la entrada. No hace falta dinamitar el búnker; solo hay que encontrar esa llave vieja y legítima para entrar sin hacer ruido.

Esta analogía ilustra con precisión el hallazgo de la firma de seguridad ESET. Sus investigadores han identificado 11 cargadores de arranque (conocidos en la jerga técnica como shims) antiguos, legítimos y firmados digitalmente por Microsoft, que contienen vulnerabilidades críticas. Al ser software firmado oficialmente, el firmware de cualquier placa base moderna los acepta como válidos. El problema es que, una vez cargados, un atacante puede explotar sus fallos internos para saltarse por completo la protección de UEFI Secure Boot, tomando el control del sistema antes de que el propio sistema operativo comience a cargarse.

El peso de la herencia: de la BIOS clásica al ecosistema UEFI

Para comprender la gravedad de esta situación, es necesario retroceder en el tiempo. Durante décadas, el proceso de arranque de las computadoras dependía de la BIOS (Basic Input/Output System), un sistema heredado de los años 80 que carecía de cualquier noción de seguridad moderna. Cualquier código ubicado en el Master Boot Record (MBR) del disco duro se ejecutaba con privilegios absolutos. Esto dio origen a la era dorada de los virus de sector de arranque.

La llegada de UEFI (Unified Extensible Firmware Interface) a finales de la década de 2000 y, específicamente, la introducción de Secure Boot en 2012 con el lanzamiento de Windows 8, prometía erradicar esta amenaza. Secure Boot establece una cadena de confianza criptográfica: el firmware de la placa base solo ejecuta código que esté firmado por una entidad de certificación de confianza. Por defecto, prácticamente todas las placas base del mercado de consumo confían en la clave de Microsoft (Microsoft Production CA).

Sin embargo, esta centralización creó un cuello de botella para el ecosistema de código abierto. ¿Cómo podía arrancar una distribución de Linux como Ubuntu, Fedora o Debian en una máquina con Secure Boot activado sin obligar al usuario a desactivar esta protección o a instalar claves personalizadas? La respuesta fue el nacimiento del shim.

El 'Shim' como puente de confianza y su talón de Aquiles

Un shim es un cargador de arranque de tamaño muy reducido, diseñado específicamente para servir de puente. Está firmado por la entidad de certificación de terceros de Microsoft (Microsoft Third-Party UEFI CA). Cuando el firmware de la máquina arranca, verifica la firma del shim, la acepta y le cede el control. Una vez en ejecución, el shim utiliza sus propias claves internas para verificar y cargar el cargador de arranque real de Linux (habitualmente GRUB) y, posteriormente, el kernel del sistema operativo.

Este diseño, aunque ingenioso, traslada la responsabilidad de la seguridad de la firma global de Microsoft a la solidez del código del propio shim. Si un shim firmado oficialmente contiene una vulnerabilidad de desbordamiento de búfer o de ejecución de código anómala, toda la cadena de confianza de Secure Boot se desmorona.

El problema fundamental de la criptografía de clave pública en el firmware no es la solidez de los algoritmos, sino la gestión del ciclo de vida del software firmado. Una firma digital no caduca cuando el código se vuelve obsoleto o vulnerable; permanece válida para siempre a menos que se revoque explícitamente a nivel de hardware.

— Carlos Mendoza, Director de Arquitectura de Seguridad en Iberia CyberSec

El descubrimiento de ESET no se basa en un fallo de día cero (0-day) extremadamente sofisticado. Se trata de la constatación de que existen 11 de estos archivos shim, distribuidos en su día por diferentes vendedores y distribuciones de Linux, que siguen siendo considerados totalmente válidos por las placas de millones de servidores y ordenadores en todo el mundo, a pesar de albergar fallos de seguridad conocidos.

BYOVD en fase de pre-arranque: la importación de código vulnerable

En el ámbito de la ciberseguridad corporativa, el ataque conocido como BYOVD (Bring Your Own Vulnerable Driver o 'Trae tu propio controlador vulnerable') se ha convertido en una técnica habitual para evadir las soluciones EDR (Endpoint Detection and Response). Consiste en que un atacante con privilegios de administrador instala un controlador legítimo pero antiguo (por ejemplo, de una tarjeta gráfica o una herramienta de diagnóstico) que tiene una vulnerabilidad conocida. Al estar firmado por un fabricante legítimo, Windows permite su instalación. Luego, el atacante explota ese controlador para acceder al kernel del sistema operativo y desactivar las defensas.

El hallazgo de ESET traslada este concepto al escenario previo a la carga del sistema operativo: el BYOVD en fase de pre-arranque (que podríamos denominar Bring Your Own Vulnerable Bootloader).

Un atacante no necesita manipular el firmware de la placa base ni romper el cifrado de Secure Boot. Solo necesita colocar uno de estos 11 shims vulnerables en la partición de sistema EFI (ESP) y configurar el sistema para que arranque desde él. Dado que el shim cuenta con una firma válida de Microsoft, el firmware lo ejecutará sin rechistar. A partir de ahí, el atacante explota la vulnerabilidad intrínseca de ese shim para ejecutar código arbitrario no firmado, saltándose las restricciones de Secure Boot y cargando un bootkit UEFI (malware de firmware).

La caída de las fronteras entre Windows y Linux

Es común pensar que las vulnerabilidades asociadas a componentes de Linux solo afectan a dicho sistema operativo. En este caso, la realidad es radicalmente distinta. Dado que el mecanismo de verificación de Secure Boot reside en el firmware de la placa base (independientemente del sistema operativo que se vaya a ejecutar después), un atacante puede utilizar estos shims de Linux vulnerables para comprometer una máquina que ejecuta exclusivamente Windows.

El proceso es directo: el atacante monta la partición EFI en Windows, escribe el shim vulnerable y modifica las variables de arranque de la NVRAM para priorizarlo. En el siguiente reinicio, la máquina ejecutará el shim de Linux, se explotará la vulnerabilidad antes de que se inicie el cargador de Windows (Bootmgr.efi), y el atacante podrá parchear el kernel de Windows en memoria antes de que se activen las medidas de seguridad del sistema operativo, como el aislamiento de núcleo (HVCI) o Microsoft Defender.

Este ataque no requiere exploits complejos adaptados a la última versión del sistema operativo. Se apoya en fallos lógicos y de desbordamiento de memoria documentados hace años en la gestión de protocolos de red (como IPv6 o HTTP) dentro del propio entorno de pre-arranque de los shims.

El debate del riesgo real: ¿es tan fácil de explotar?

Existe una corriente de opinión entre ciertos administradores de sistemas que tiende a restar importancia a este tipo de amenazas de firmware, argumentando que requieren acceso físico a la máquina o privilegios de administrador local previos para poder modificar la partición EFI y las variables de la NVRAM. La premisa es simple: si un atacante ya es administrador de tu sistema, ya ha ganado; no necesita un bootkit UEFI.

Sin embargo, este argumento pasa por alto la importancia estratégica de la persistencia y la evasión en el espionaje de alto nivel y el ransomware avanzado. Un atacante que logra privilegios de administrador mediante un exploit local o un robo de credenciales sabe que su presencia en el sistema operativo tiene fecha de caducidad. Los analistas de seguridad acabarán detectando sus procesos, o el sistema será formateado y reinstalado durante las labores de limpieza.

Un bootkit UEFI instalado mediante la técnica de shim vulnerable proporciona una persistencia casi indestructible. Sobrevive al formateo completo del disco duro, al cambio del sistema operativo e incluso a la sustitución física de la unidad de almacenamiento, ya que el código malicioso se ejecuta antes de que se lea el disco principal. Además, al ejecutarse antes que cualquier agente de seguridad, puede ocultar su presencia modificando el propio kernel del sistema operativo sobre la marcha, volviéndose invisible para los antivirus.

La pesadilla logística de la revocación por DBX

La solución teórica a este problema parece sencilla: revocar las firmas de los 11 shims vulnerables. Para ello, UEFI utiliza la base de datos de firmas prohibidas, conocida como DBX. Cuando el firmware encuentra un archivo cuya firma coincide con un hash de la DBX, bloquea su ejecución.

En la práctica, la actualización de la DBX es un terreno minado para los administradores de TI y los fabricantes de hardware. La memoria NVRAM donde se almacenan estas firmas en las placas base es extremadamente limitada, a menudo restringida a unos pocos kilobytes (típicamente entre 32KB y 64KB). Si la lista de revocación crece demasiado, simplemente no cabe en el chip físico.

La gestión de la DBX de UEFI es uno de los mayores dolores de cabeza de la seguridad de hardware moderna. Forzar una actualización masiva de revocación de firmas puede provocar que sistemas antiguos queden inoperativos o sufran un bucle de reinicios infinito debido a fallos en la implementación del firmware de los OEM.

— Dr. Aris Thorne, Investigador Principal de Firmware en el Instituto de Seguridad de Sistemas de Múnich

Además, existe el riesgo real de 'bricking' (dejar el equipo inservible). Si un administrador aplica una actualización de la DBX que revoca un cargador de arranque que el sistema todavía necesita para iniciar (por ejemplo, porque el sistema operativo utiliza una versión antigua de GRUB no actualizada), la máquina dejará de arrancar por completo, requiriendo una intervención física compleja para restablecer la BIOS.

Guía de acción para administradores de sistemas

Ante este panorama, la inacción no es una opción viable para las organizaciones que gestionan infraestructura crítica o datos sensibles. La mitigación de esta vulnerabilidad requiere un enfoque estructurado y preventivo

• Auditoría de la partición EFI: Es fundamental monitorizar la presencia de archivos `.efi` no reconocidos en la partición de sistema EFI de los servidores y estaciones de trabajo. Herramientas de monitorización de integridad de archivos (FIM) pueden alertar sobre cualquier modificación en este directorio crítico.
• Actualización controlada de la DBX: Los administradores deben planificar la aplicación de las actualizaciones de revocación de Secure Boot proporcionadas por Microsoft (a través de Windows Update) o por las distribuciones de Linux. Es vital realizar pruebas previas en entornos de laboratorio con hardware idéntico para descartar problemas de compatibilidad del firmware.
• Implementación de Measured Boot y TPM: Configurar el Arranque Medido utilizando el chip TPM 2.0 (Trusted Platform Module). Esto no impide la ejecución del shim vulnerable, pero registra métricas (PCR) del proceso de arranque. Si la cadena de arranque se altera para introducir un cargador vulnerable, las claves de cifrado del disco (como BitLocker) no se liberarán automáticamente, bloqueando el acceso a los datos.
• Actualizaciones de Firmware de OEM: Mantener la BIOS/UEFI de los equipos actualizada a la última versión proporcionada por el fabricante del hardware, ya que estas actualizaciones suelen incluir parches específicos para la gestión de la NVRAM y la DBX.

El descubrimiento de ESET nos recuerda que la ciberseguridad no es un estado estático, sino un proceso dinámico de gestión de la confianza. La firma digital de un gigante tecnológico es una garantía de origen, pero nunca una garantía de ausencia de errores. Mientras el software del pasado siga siendo aceptado por el hardware del presente, las puertas traseras de la confianza seguirán abiertas para quienes sepan encontrarlas.