UEFI, Secure Boot y bootkits: cadena de confianza del arranque y cómo se rompe

El firmware UEFI es lo primero que ejecuta tu máquina al encenderse. Inicializa el hardware, decide qué sistema operativo arranca y le cede el control. Un atacante que consiga modificar ese firmware o el bootloader que le sigue obtiene persistencia por debajo del sistema operativo: ni reinstalar el SO, ni formatear el disco, ni en algunos casos cambiar el disco duro elimina la implantación.

El estándar UEFI sustituyó a la BIOS clásica a partir de 2012 e introdujo Secure Boot, un mecanismo de verificación criptográfica que solo permite arrancar código firmado por claves de confianza. Pero Secure Boot no es mágico: depende de que las claves estén bien gestionadas, de que el firmware no tenga vulnerabilidades y de que la base de datos de revocación se mantenga al día. Los bootkits reales que han aparecido en los últimos años demuestran que esas condiciones no siempre se cumplen. Esta lección cubre la cadena de arranque UEFI, el modelo de Secure Boot, los ataques documentados, y sobre todo cómo inspeccionar y fortificar el arranque de tus sistemas. Es la decimoquinta lección de la Tanda 7, la que la cierra.

Manipular firmware en equipos ajenos es ilegal. Todo lo que se describe aquí se practica en máquinas virtuales propias (QEMU + OVMF) o en hardware de laboratorio. Publicar hallazgos en firmware comercial sigue el proceso de divulgación coordinada con el fabricante.

Qué es UEFI y por qué importa#

UEFI (Unified Extensible Firmware Interface) define la interfaz entre el firmware de la placa base y el sistema operativo. Sustituye a la BIOS heredada con drivers modulares, shell, soporte de red, sistema de archivos FAT en la partición ESP (EFI System Partition) y un framework de verificación de firmas.

Fases del arranque#

El arranque UEFI pasa por varias fases, cada una con su propio nivel de privilegio:

SEC (Security Phase). El procesador sale de reset, ejecuta el primer bloque de código del chip SPI flash. Inicializa la caché como RAM temporal. Es el punto de mayor privilegio y el más difícil de comprometer (requiere modificar el chip flash).

PEI (Pre-EFI Initialization). Inicializa la memoria principal (DRAM). Los módulos PEI (PEIMs) configuran el chipset. Un implante aquí controla toda la memoria desde el principio.

DXE (Driver Execution Environment). Carga los drivers UEFI: almacenamiento, red, gráficos, USB. Es la fase más extensa y la que más superficie de ataque expone: cada driver DXE es un binario PE/COFF que el firmware ejecuta con privilegio máximo.

BDS (Boot Device Selection). Lee las variables UEFI de arranque, localiza el bootloader en la ESP y le transfiere el control.

Bootloader → Kernel. GRUB, Windows Boot Manager u otro bootloader carga el kernel del SO. Desde aquí el sistema operativo toma el control progresivamente.

Un atacante puede implantar código malicioso en cualquier fase. Cuanto más temprana, más difícil de detectar y de eliminar.

Por qué ocurre: la causa raíz#

La raíz del problema es la asimetría de confianza: el firmware confía en sí mismo incondicionalmente. Si un atacante modifica el contenido del chip SPI flash (por vulnerabilidad del propio firmware, por acceso físico, o por un driver DXE vulnerable), el firmware ejecuta ese código sin cuestionarlo, porque la verificación de Secure Boot ocurre después, cuando el firmware ya está corriendo.

Secure Boot protege la transición firmware → bootloader → kernel, pero no protege el firmware contra sí mismo. Y la cadena de confianza depende de decisiones humanas: qué claves se instalan, si la base de datos de revocación se actualiza, si el fabricante protege la escritura del flash.

Chip SPI flash
  └── Firmware UEFI (SEC, PEI, DXE)     ← No verificado por Secure Boot
        └── Bootloader (GRUB, Windows BM)  ← Verificado por Secure Boot (db)
              └── Kernel                     ← Verificado por Secure Boot (db)
                    └── Drivers del SO         ← Verificado por el kernel

Todo lo que está por encima de la línea de Secure Boot corre sin verificación criptográfica estándar. Las defensas existen (Boot Guard de Intel, Platform Secure Boot de AMD), pero son del fabricante de la placa, no del estándar UEFI, y no todos las activan.

Tipos de implantes de arranque#

Los bootkits de la era BIOS (MBR) son historia: UEFI y GPT los hicieron obsoletos. Los bootkits modernos atacan la ESP o el firmware directamente.

Secure Boot en detalle#

Secure Boot usa una jerarquía de claves y bases de datos almacenadas en variables UEFI no volátiles (NVRAM):

PK (Platform Key). Una sola clave, normalmente del fabricante OEM. Controla quién puede modificar KEK. Es la raíz de toda la cadena.

KEK (Key Exchange Key). Claves autorizadas a modificar db y dbx. Microsoft instala la suya; el OEM puede añadir otras.

db (Signature Database). Lista de certificados o hashes de binarios autorizados a arrancar. Aquí están los certificados de Microsoft que firman Windows Boot Manager y el shim de Linux.

dbx (Forbidden Signature Database). Lista negra: hashes o certificados revocados. Aquí se ponen los bootloaders vulnerables conocidos. Si un binario está en dbx, Secure Boot lo rechaza aunque su firma sea válida respecto a db.

Flujo de verificación#

Cuando Secure Boot está activo, el firmware verifica cada binario antes de ejecutarlo:

1. Lee el bootloader de la ESP.
2. Comprueba que NO esté en dbx (revocado).
3. Comprueba que SÍ esté firmado por un certificado en db.
4. Si pasa ambas comprobaciones, lo ejecuta. Si no, lo rechaza.

El bootloader, a su vez, verifica el kernel. Y el kernel puede verificar los módulos que carga (Secure Boot + Lockdown en Linux).

Measured Boot y TPM#

Secure Boot dice "sí o no" (arranca o no arranca). Measured Boot va más allá: registra un hash de cada componente que se carga en los PCR (Platform Configuration Registers) del TPM (Trusted Platform Module). No impide el arranque, pero deja un registro criptográfico inmutable de lo que arrancó.

Un servidor remoto puede pedir al TPM que firme los valores de los PCR (remote attestation): si un bootkit modificó cualquier componente, los hashes no coinciden y la máquina falla la atestación. BitLocker usa los PCR para sellar la clave de cifrado: si el arranque cambia, pide la clave de recuperación.

# Leer los PCR del TPM en Linux
tpm2_pcrread sha256:0,1,2,3,4,5,6,7

El PCR 0 contiene mediciones del firmware, el PCR 4 el bootloader, el PCR 5 la configuración GPT, y el PCR 7 la política de Secure Boot. Cualquier cambio en esos componentes produce valores distintos.

Dónde aparece: casos reales documentados#

LoJax (2018). Investigadores de ESET documentaron el primer rootkit UEFI encontrado en uso real, atribuido al grupo Sednit. Modificaba el firmware SPI flash para inyectar un módulo DXE que reinstalaba un agente en el sistema operativo cada vez que arrancaba. Sobrevivía al cambio de disco duro. La causa: la protección de escritura del SPI flash no estaba activada en las placas afectadas.

BlackLotus (2023). Primer bootkit UEFI documentado que evade Secure Boot en sistemas Windows parcheados. Explota CVE-2022-21894 (Baton Drop), una vulnerabilidad en el Boot Configuration Data que permite cargar código no firmado. Microsoft revocó los binarios vulnerables en dbx, pero la actualización de dbx es manual en muchas organizaciones. La NSA publicó una guía de mitigación en junio de 2023.

BootHole (CVE-2020-10713). Buffer overflow en el parser de configuración de GRUB2. Un atacante con acceso a la ESP podía modificar grub.cfg para ejecutar código antes del kernel, con Secure Boot activo. Afectó a prácticamente todas las distribuciones Linux. Corregirlo requirió actualizar GRUB, el shim y añadir los binarios viejos a dbx.

PKfail (2024). Investigadores de Binarly descubrieron que cientos de modelos de portátiles y servidores de múltiples fabricantes se habían enviado con una Platform Key de prueba de AMI marcada literalmente como "DO NOT TRUST". Cualquiera con esa clave (pública en un repositorio) podía firmar sus propios binarios de arranque y Secure Boot los aceptaría. La causa: el fabricante no reemplazó la clave de prueba por una de producción antes de enviar el producto.

Cómo se detecta#

Inspeccionar el estado de Secure Boot#

# Linux: comprobar si Secure Boot está activo
mokutil --sb-state

# Listar las claves y certificados de Secure Boot
mokutil --pk
mokutil --kek
mokutil --db
mokutil --dbx

# Ver variables UEFI directamente
efivar -l | grep -i secureboot
efivar -d -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot

CHIPSEC: auditoría de firmware#

CHIPSEC es un framework open-source de Intel para auditar la seguridad del firmware:

# Instalar (requiere acceso al hardware o VM con OVMF)
pip install chipsec

# Comprobar protección de escritura del SPI flash
sudo chipsec_main -m common.bios_wp

# Comprobar protecciones de acceso al SPI
sudo chipsec_main -m common.spi_lock

# Comprobar Secure Boot configurado correctamente
sudo chipsec_main -m common.uefi.s3bootscript

Un resultado FAILED en bios_wp significa que el flash es escribible por software: un atacante con privilegios de kernel podría inyectar un implante persistente como LoJax.

Verificar la cadena con fwupd#

# fwupd gestiona actualizaciones de firmware en Linux via LVFS
fwupdmgr get-devices      # listar firmware instalado
fwupdmgr get-updates       # comprobar si hay actualizaciones
fwupdmgr security          # resumen de seguridad del firmware

El comando fwupdmgr security muestra si la protección de escritura del SPI está activa, si el TPM funciona, si Secure Boot está habilitado y si Intel Boot Guard está configurado.

Señales de un bootkit activo#

• BitLocker pide la clave de recuperación sin motivo aparente (los PCR cambiaron).
• Los valores de PCR del TPM no coinciden con los de referencia.
• Archivos desconocidos en la ESP (ls /boot/efi/EFI/).
• CHIPSEC reporta modificaciones en la región de firmware.
• El sistema reinstalado vuelve a infectarse.

Explotación paso a paso en un laboratorio#

Este laboratorio usa QEMU + OVMF (una implementación open-source de UEFI) para inspeccionar la cadena de arranque en un entorno seguro. No se despliega ningún bootkit: el objetivo es aprender a auditar.

Paso 1: preparar la VM con UEFI#

# Instalar OVMF (Ubuntu/Debian)
sudo apt install ovmf qemu-system-x86

# Copiar el firmware UEFI (necesitas la copia para que sea escribible)
cp /usr/share/OVMF/OVMF_CODE_4M.secboot.fd ./ovmf_code.fd
cp /usr/share/OVMF/OVMF_VARS_4M.ms.fd ./ovmf_vars.fd

# Crear un disco virtual
qemu-img create -f qcow2 disco.qcow2 20G

Paso 2: arrancar con Secure Boot#

qemu-system-x86_64 \
  -machine q35,smm=on \
  -global driver=cfi.pflash01,property=secure,value=on \
  -drive if=pflash,format=raw,unit=0,file=ovmf_code.fd,readonly=on \
  -drive if=pflash,format=raw,unit=1,file=ovmf_vars.fd \
  -drive file=disco.qcow2,format=qcow2 \
  -m 4096 -smp 2 \
  -net nic -net user \
  -vga virtio

La opción smm=on activa System Management Mode, necesario para que Secure Boot funcione en QEMU. La variante ms de OVMF_VARS viene precargada con las claves de Microsoft.

Paso 3: inspeccionar desde dentro#

Una vez instalado un Linux en la VM:

# Verificar Secure Boot
mokutil --sb-state
# Debería decir: SecureBoot enabled

# Listar el contenido de la ESP
ls -la /boot/efi/EFI/

# Ver los binarios firmados
sbverify --cert /path/to/cert.pem /boot/efi/EFI/ubuntu/shimx64.efi

# Leer PCR del TPM (si el TPM está emulado con swtpm)
tpm2_pcrread sha256:0,4,7

Paso 4: probar qué pasa si se modifica la ESP#

# Copiar un binario no firmado a la ESP
cp /usr/bin/ls /boot/efi/EFI/BOOT/testboot.efi

# Intentar registrarlo como opción de arranque
efibootmgr -c -d /dev/vda -p 1 -l \\EFI\\BOOT\\testboot.efi -L "Test"

# Al reiniciar, Secure Boot rechazará testboot.efi
# porque no está firmado por ningún certificado en db

Este ejercicio demuestra que Secure Boot hace su trabajo: rechaza binarios no autorizados. El problema real aparece cuando el binario es antiguo, está firmado pero tiene una vulnerabilidad (como BootHole), y el fabricante no lo ha añadido a dbx.

Qué puede lograr un atacante#

Cómo se corrige#

Mantener Secure Boot activo. No lo desactives para instalar Linux: usa el shim firmado por Microsoft que incluyen Ubuntu, Fedora, Debian y otras distribuciones. El shim verifica GRUB con la clave de la distribución.

Actualizar dbx. La base de datos de revocación hay que mantenerla al día. En Windows, Windows Update la actualiza. En Linux:

# Descargar la dbx más reciente de UEFI.org
# https://uefi.org/revocationlistfile
# Aplicarla con fwupd
fwupdmgr update

Actualizar el firmware. Igual que parcheas el kernel, parchea el firmware. En Linux, fwupd + LVFS automatizan el proceso para muchos fabricantes. En Windows, usa la herramienta del fabricante o Windows Update si la soporta.

Proteger la ESP. La partición EFI es FAT32 sin permisos: cualquier proceso con privilegios de root o administrador puede escribir en ella. Monta la ESP como solo lectura excepto durante actualizaciones. En Linux, no montes /boot/efi por defecto en fstab.

Verificar la Platform Key. Confirma que la PK de tu equipo no sea una clave de prueba. En un equipo de producción, mokutil --pk debe mostrar un certificado del fabricante OEM, no de AMI ni marcado como test.

Habilitar protección de escritura del SPI. CHIPSEC te dice si está activa. Si no lo está, es un problema del fabricante: no hay forma estándar de activarla desde el SO. Pero saber que falta permite tomar decisiones informadas sobre qué equipos pueden almacenar datos sensibles.

Intel Boot Guard y AMD Platform Secure Boot. Verifican el firmware antes de que UEFI empiece. Si están activos, un atacante no puede modificar el firmware ni con acceso físico. Los configura el OEM en fábrica y no se pueden habilitar después.

Measured Boot + atestación remota. Para flotas corporativas, combinar TPM + atestación remota detecta cualquier cambio en la cadena de arranque. Keylime (open-source) automatiza la verificación de PCR.

Errores comunes al defenderse#

• Desactivar Secure Boot y olvidarse de reactivarlo. O dejarlo en "modo custom" sin claves, que es lo mismo que desactivado.
• Creer que Secure Boot protege el firmware. No: protege del firmware hacia abajo. El firmware se protege con escritura de flash bloqueada y Boot Guard.
• No actualizar dbx. Un bootloader vulnerable firmado por Microsoft es la puerta de entrada de BlackLotus.
• Asumir que "reinstalar resuelve todo". Un implante en SPI flash sobrevive a cualquier reinstalación.
• Ignorar la ESP porque "es solo la partición de arranque". Es el eslabón más accesible de la cadena.
• No verificar la PK en equipos nuevos. PKfail demostró que los fabricantes se equivocan.
• Desactivar BitLocker sin comprobar por qué pidió la clave de recuperación. Puede ser un cambio legítimo o un bootkit que alteró los PCR.

Preguntas frecuentes#

¿Puedo practicar sin hardware dedicado?#

Sí. QEMU + OVMF proporciona un entorno UEFI completo con Secure Boot funcional. Puedes añadir un TPM emulado con swtpm para practicar Measured Boot. Es exactamente como lo hacen los desarrolladores de GRUB y los investigadores de seguridad.

¿Secure Boot impide instalar Linux?#

No. Las distribuciones principales (Ubuntu, Fedora, Debian, openSUSE, RHEL) incluyen un shim firmado por Microsoft. Secure Boot verifica el shim, el shim verifica GRUB con la clave de la distribución, y GRUB verifica el kernel. La cadena funciona sin desactivar nada.

¿Cómo sé si mi equipo es vulnerable a PKfail?#

Ejecuta mokutil --pk y comprueba el campo CN (Common Name) del certificado. Si dice "DO NOT TRUST" o "AMI Test", tu Platform Key es de prueba y Secure Boot no protege nada. Contacta al fabricante para un parche de firmware.

¿Qué diferencia hay entre Secure Boot y Boot Guard?#

Secure Boot verifica el bootloader y el kernel: protege de la ESP hacia abajo. Boot Guard (Intel) o Platform Secure Boot (AMD) verifican el firmware antes de que UEFI empiece: protegen de la placa base hacia abajo. Son complementarios. Boot Guard lo configura el OEM en fábrica y no se puede habilitar después.

¿Un bootkit funciona en una VM?#

Un bootkit de ESP (BlackLotus) funciona en cualquier VM con UEFI. Un implante de SPI flash solo si la VM expone una interfaz de flash escribible. En la nube, el hipervisor proporciona el firmware y el inquilino no puede modificarlo.

Resumen#

• UEFI reemplaza a la BIOS con un entorno de firmware modular y extensible. Las fases SEC → PEI → DXE → BDS arrancan antes que el sistema operativo.
• Secure Boot verifica criptográficamente el bootloader y el kernel con claves en db/dbx, pero no protege el firmware contra sí mismo.
• Measured Boot + TPM registra hashes de la cadena en los PCR, detectando modificaciones por atestación.
• Bootkits reales: LoJax (SPI flash), BlackLotus (ESP, evade Secure Boot), BootHole (overflow en GRUB), PKfail (clave de prueba en producción).
• Defensa: mantener Secure Boot activo, actualizar dbx y firmware, proteger la ESP, verificar la PK, y usar Measured Boot con atestación remota en entornos corporativos.

Fuentes y lecturas recomendadas#

• Especificación UEFI
• ESET: LoJax
• NSA: BlackLotus Mitigation Guide (junio 2023)
• Binarly: PKfail
• Eclypsium: BootHole
• CHIPSEC
• fwupd / LVFS
• MITRE ATT&CK T1542: Pre-OS Boot
• Keylime (Remote Attestation)