¿Qué nivel de seguridad nos proporciona el firmware de los procesadores de Intel?

Desde hace bastante tiempo llevo revisando el software de bajo nivel de las arquitecturas. Desde routers a procesadores. Me causa especial interés la arquitectura Intel. Es la que he llevado conmigo desde que me tengo memoria. Siempre he preferido Intel. Y así ha sido desde el 80286. Quedaré mal si digo que he aparcado numerosas tareas docentes, de investigación y de análisis de malware por sentarme a recopilar y organizar toda la información al respecto de la seguridad de la UEFI de los procesadores Intel. Y, claro, de su siempre cuestionado ME (Management Engine). Asi que vamos a ello.

Qué funciones tiene la UEFI BIOS e Intel ME

La BIOS moderna basada en UEFI (entendamos y esto es algo que trato de diferenciar mucho cuando desarrollo este tema, que BIOS y UEFI no es lo mismo) es el primer código que se ejecuta al encender el sistema y reemplaza a la BIOS tradicional. Se encarga de inicializar el hardware (POST, memoria, controladores básicos) y de cargar el gestor de arranque (bootloader) desde la partición EFI (un ESP en FAT32).

• ESP: Es un estándar para la interfaz de firmware extensible (EFI) y es necesario para que el sistema operativo pueda arrancar correctamente en sistemas que utilizan UEFI. La ESP es una partición pequeña, típicamente entre 100 y 200 MB, que contiene los archivos necesarios para el proceso de arranque. 

Tras la fase de arranque (SEC, PEI, DXE, BDS), UEFI transfiere el control al sistema operativo pero expone a este servicios de tiempo de ejecución (variables NVRAM, runtimes, controles de energía, etc.). Además implementa Secure Boot, que verifica las firmas de cargadores autorizados antes de ejecutar el sistema operativo. Por su parte, el Intel Management Engine (ME) es un microcontrolador integrado en el chipset, basado en arquitectura x86 interna, que funciona de forma independiente a la CPU principal. ME implementa funciones de administración remota (AMT) introducidas por Intel: inventario de hardware, servicios de actualización, diagnósticos, acceso remoto (KVM) y un servidor HTTP/HTTPS embebido para control fuera de banda (OOB, out of band); es decir, dispone de su propia interfaz de red y dirección MAC/IP, lo que permite el acceso y control remoto a través de una conexión de red, incluso cuando el sistema operativo principal está apagado. Este subsistema se mantiene activo mientras la fuente de alimentación esté conectada (incluso con el PC “apagado”, mientras la fuente esté conectada), y por diseño tiene acceso DMA completo a la RAM y a todos los dispositivos del sistema. En su implementación actual, el firmware de ME corre su propio sistema operativo interno, con módulos de kernel, drivers y servicios (p. ej. componentes AMT); en modo privilegiado el ME puede acceder a todo el hardware de la placa, prácticamente de manera transparente al sistema operativo del usuario.

Tipos de ataques posibles

Se pueden definir varias clases de ataque sobre el firmware UEFI/BIOS y el Intel ME. A continuación se definen los más evidentes:

Ataques al SMM (System Management Mode): El Modo de Gestión de Sistema es un contexto de ejecución privilegiado y oculto para el SO. Un atacante con privilegios puede generar una interrupción SMI y explotar vulnerabilidades en los manejadores SMM, inyectando código malicioso que se ejecutará con todos los privilegios (acceso total a RAM/dispositivos, con total transparencia al SO). De hecho, hasta 2015 muchas plataformas carecían de protecciones de memoria SMRR/TSEG, por lo que eran teóricamente vulnerables a estas inyecciones ocultas.

Manipulación de variables NVRAM (Setup): Los sistemas UEFI almacenan datos críticos en NVRAM (p. ej. claves Secure Boot, bit de bloqueo SPI, contraseña de BIOS). Si un atacante accede al UEFI Shell (por ejemplo, mediante una herramienta EFI cargada al arranque), puede usar el comando SetVar para cambiar variables. Con ello se puede por ejemplo deshabilitar el bit de bloqueo SPI (permitiendo reescribir el firmware) o borrar las claves de Secure Boot, forzando la BIOS a ignorar la firma digital.

Desactivación o subversión de Secure Boot: Secure Boot impide cargar código que no tenga una firma válida. Sin embargo, puede deshabilitarse si se eliminan las claves autorizadas en NVRAM o si se añade una clave maliciosa propia. Borrando las variables NVRAM relevantes (como las claves de Microsoft o las definidas en el Setup de la BIOS) el sistema cargará firmware no firmado, anulando Secure Boot. Este tipo de vector se implementa ya sea mediante UEFI Shell o aprovechando vulnerabilidades de la BIOS.

Ataques a Intel BIOS Guard / Boot Guard: Intel Boot Guard es un mecanismo hardware que verifica la firma del bloque inicial de la BIOS; Intel BIOS Guard hace algo similar en etapas posteriores. El documento indica que si no existe verificación de integridad, el firmware puede parchearse con un programador de flash externo; si sí existe, aun se podría eludir parcheando el propio código de verificación.

En la práctica, se ha demostrado que existen formas de desactivar o burlar estas protecciones mediante ingeniería inversa (Ermolov lo hizo en 2017:https://firmwaresecurity.com/2017/05/08/alexander-ermolov-on-intel-bootguard/).

Inyección de firmware de dispositivos PCI (Option ROM): Una ruta de ataque complementaria es reemplazar el firmware de tarjetas o periféricos (Ethernet, video, Thunderbolt, etc.) con código malicioso. Al cargarse estos Option ROM durante el arranque, el malware puede ejecutar instrucciones arbitrarias en etapa temprana, comprometiendo igualmente la seguridad global.

Estructura del firmware

El firmware de plataforma está contenido en un chip flash SPI compartido. Como ilustra la figura, Intel define regiones separadas: primero el Descriptor (gestiona permisos de acceso a la flash), seguido por la región GbE (firmware del adaptador de red integrado), luego la región de Intel ME (firmware del Management Engine) y finalmente la región de UEFI BIOS (firmware EFI principal) junto con la región PDR (módulos extra de proveedor). Cada bloque se puede proteger con bits de solo lectura, aunque muchos fabricantes antiguos dejaban deshabilitado el bloqueo de la región BIOS.

El firmware UEFI BIOS comienza en la fase SEC (verificación de integridad, carga de DRAM), continúa en PEI (inicialización de la RAM, copia de código a memoria) y en DXE (carga de drivers y servicios EFI). En DXE se inicializa el hardware restante y se crea la interfaz abstracta de dispositivos. Finalmente UEFI busca un cargador de sistema en la partición EFI del disco (FAT32). Si lo encuentra lo ejecuta; de lo contrario lanza error o pasa al gestor de arranque alternativo. El sistema operativo, una vez iniciado, puede invocar interfaces de firmware vía servicios de tiempo de ejecución EFI. Adicionalmente, durante DXE se reserva una subfase de System Management Mode (SMM).

La región Intel ME alberga su propio firmware aislado: el código está firmado con claves RSA y protegido con atributos de solo-lectura en flash. Internamente, el ME tiene un microkernel (núcleo de sistema operativo) y varios módulos: controladores del chip, servicios de AMT, bitlocker, contenedores de seguridad, etc. En modo privilegiado el ME puede acceder a todos los dispositivos y memorias del sistema. Esta separación de módulos permite al ME operar de forma paralela a la BIOS principal, ampliando sus funcionalidades sin intervención de la CPU.

Vulnerabilidades de Intel ME y su independencia de la CPU

El ME se ejecuta en un entorno aislado de muy bajo nivel (“anillo –3”) y disfruta de privilegios absolutos. La arquitectura actual lo hace indispensable: si un atacante lograra modificar su firmware tendría absoluto control y podría actuar con completo sigilo en la máquina. Por ejemplo, un código malicioso en el ME podría leer/escribir toda la RAM, monitorizar el tráfico de red o controlar periféricos de E/S sin que el sistema operativo lo detecte. Además, dado que Intel firma el firmware ME con clave privada y verifica la integridad al arrancar, su único mecanismo de defensa son estas firmas. Si dicha clave maestra se filtrara, el ME quedaría completamente vulnerable. No habría forma de detectar o impedir una reprogramación maliciosa. Aunque hasta la fecha no se han publicado ataques prácticos que hayan sido exitosos contra el ME, la mera posibilidad teórica es seria: con métodos de hardware (flasheadores externos) o incluso modos ocultos se puede deshabilitar o reescribir el ME por completo.

Esta independencia de la CPU y su capacidad de acceso DMA absoluto hacen que cualquier vulnerabilidad descubierta en el ME tenga implicaciones críticas. Por ejemplo, Positive Technologies ya ha cargado código no firmado en ME 11.x (Ermolov, otra vez), lo cual confirma que el aislamiento de ME no es infalible.

La seguridad del ME es autónoma del SO y del procesador principal; un compromiso en esa capa implica una llave maestra sobre la plataforma entera.

Herramientas para el análisis de firmware

Existen varias utilidades especializadas para inspeccionar y modificar imágenes de BIOS/UEFI y ME:

UEFITool: aplicación open-source (C++/Qt) que parsea imágenes de firmware UEFI en una estructura de árbol. Permite visualizar volúmenes FFS, módulos, verificaciones de integridad y extraer cada componente para análisis.

unME11 / unME12: scripts Python desarrollados por Sklyarov (Positive Technologies) para desempaquetar las regiones del firmware Intel ME versión 11.x y 12.x respectivamente. Extraen particiones, módulos y metadatos del blob de ME.

Chipsec (Intel): framework de pruebas de seguridad de plataforma que permite auditar configuraciones de firmware y registros críticos (en particular SMM, TPM, etc.).

Herramientas Intel oficiales: ME System Tools y Flash Programming Tool permiten obtener/actualizar imágenes ME, extraer dumps de memoria y flashear chips SPI. Aunque pensadas para servicio técnico, son empleadas por investigadores para obtener firmware legítimo.

Otros proyectos: UEFIExtract, UEFITool Engine, Fiano (Go) o FMMT (TianoCore) también pueden parsear imágenes EFI; UEFITools comunitarios (como UBU/WinToolkit) facilitan la descarga automática de firmware de fabricantes.

Configuraciones inseguras en las placa base

Muchos fabricantes configuran de manera poco apropiada el firmware de fábrica, abriendo la puerta a ataques triviales. Un problema común es no habilitar el bit de bloqueo SPI tras la programación inicial: muchos sistemas (sobre todo antiguos) permiten reescribir la región BIOS directamente por software porque la memoria flash no está en modo de solo-lectura. Asimismo, se reporta que suelen usarse BIOS de referencia de unos pocos proveedores (Intel, AMI, Phoenix, Insyde), por lo que hay herramientas e imágenes recicladas disponibles públicamente. De hecho, existen “rescue disks” y utilidades de flasheo (oficiales o filtradas) de firmas como Lenovo, HP, Dell, etc., que pueden descargarse de foros. Con ellas se puede sobrescribir el firmware original sin mayor restricción. Por ejemplo, páginas como BIOS-mods.com o win-raid.com alojan programas no oficiales que implementan el flasheo libre.

La falta de protecciones por hardware (SPI Lock) y la disponibilidad de firmware e imagenes de BIOS hacen muy sencilla la configuración de BIOS inseguras en la práctica.

Limitaciones actuales de las tecnologías de protección UEFI BIOS

Para terminar, las medidas de protección del firmware, aunque útiles, tienen limitaciones importantes. Las defensas basadas en integridad (Secure Boot, Boot Guard) pueden ser eludidas si un atacante logra parchear el código de verificación o extraer las claves maestras. Los ataques modernos a SMM siguen siendo factibles en sistemas sin mitigaciones avanzadas. Dado que Intel ME se ejecuta de manera aislada, cualquier brecha en su firmware comprometería todo lo demás. En la práctica, las implementaciones seguras (habilitación de SPI Lock, arranque seguro activo, actualización del ME, contraseñas BIOS fuertes) pueden incrementar la robustez, pero no garantizan invulnerabilidad.

Aún no existe una solución universal: técnicas como el flasheo por hardware o la modificación de variables NVRAM quedan fuera del alcance de las defensas estándar. Las tecnologías de protección actuales (Secure Boot, Boot Guard, etc.) reducen riesgos pero no eliminan la posibilidad de introducir malware en el firmware, especialmente si el atacante dispone de acceso local privilegiado.

Documentación

https://invisiblethingslab.com/resources/bh09usa/Ring%20-3%20Rootkits.pdf

https://people.kth.se/~maguire/DEGREE-PROJECT-REPORTS/100402-Vassilios_Ververis-with-cover.pdf

https://github.com/ptresearch/unME11

https://github.com/ptresearch/unME12

http://me.bios.io/images/c/ca/Rootkit_in_your_laptop.pdf

http://composter.com.ua/documents/Exploiting_Flash_Protection_Race_Condition.pdf