La bota de confianza de Schrödinger. Protector de arranque Intel

Proponemos bajar nuevamente al nivel bajo y hablar sobre la seguridad de las plataformas informáticas compatibles con firmware x86. Esta vez, el ingrediente principal del estudio es Intel Boot Guard (¡no debe confundirse con Intel BIOS Guard!), una tecnología de arranque fiable de BIOS compatible con hardware que un proveedor de sistemas informáticos puede activar o desactivar de forma permanente en la etapa de producción. Bueno, ya conocemos la receta de la investigación: cortar finamente la implementación de esta tecnología mediante ingeniería inversa, describir su arquitectura, llenarla de detalles indocumentados, aderezarla con vectores de ataque al gusto y mezclarla. Agreguemos fuego con una historia sobre cómo un error clonado en la producción de varios proveedores durante años permite que un atacante potencial use esta tecnología para crear un rootkit oculto que no puede eliminarse (ni siquiera por un programador) en el sistema.

Por cierto, el artículo se basa en los informes "On Guard for Rootkits: Intel BootGuard" de la conferencia Noches Cero 2016 y 29 reunión DefCon Rusia (ambas presentaciones aquí).

Firmware para una plataforma informática con arquitectura Intel 64

Para empezar, respondamos la pregunta: ¿cuál es el firmware de una plataforma informática moderna con la arquitectura Intel 64? Por supuesto, BIOS UEFI. Pero esta respuesta no será precisa. Echemos un vistazo a la figura, que muestra la versión de escritorio (portátil) de esta arquitectura.

La base es el enlace:

• Procesador (CPU, Central Processing Unit), que, además de los núcleos principales, tiene un núcleo de gráficos integrado (no en todos los modelos) y un controlador de memoria (IMC, Integrated Memory Controller);
• Conjunto de chips (PCH, Platform Controller Hub), que contiene varios controladores para interactuar con dispositivos periféricos y administrar subsistemas. Entre ellos se encuentra el notorio Intel Management Engine (ME), que también tiene un firmware (firmware Intel ME).

Las computadoras portátiles, además de las anteriores, requieren un controlador integrado (ACPI EC, Advanced Control and Power Interface Embedded Controller), que es responsable del funcionamiento del subsistema de alimentación, panel táctil, teclado, teclas Fn (brillo de pantalla, volumen de sonido, teclado luz de fondo, etc.) y más. Y también tiene su propio firmware.

Entonces, la combinación del firmware anterior es el firmware de la plataforma de la computadora (firmware del sistema), que se almacena en una memoria flash SPI común. Para que los usuarios de esta memoria no se confundan dónde miente alguien, el contenido de esta memoria se divide en las siguientes regiones (como se muestra en la figura):

• BIOS UEFI;
• Firmware ACPI EC (apareció una región separada con la microarquitectura del procesador Skylake (2015), pero aún no hemos visto ejemplos de su uso, por lo que el firmware del controlador integrado sigue siendo parte del UEFI BIOS);
• Firmware Intel ME;
• configuración (dirección MAC, etc.) del adaptador de red GbE (Gigabit Ethernet) incorporado;
• descriptores flash: la región principal de la memoria flash, que contiene punteros a otras regiones, así como permisos para acceder a ellas.

La diferenciación del acceso a las regiones (de acuerdo con los permisos especificados) es manejada por el maestro del bus SPI, el controlador SPI integrado en el conjunto de chips, a través del cual se accede a esta memoria. Si los permisos se establecen en los valores recomendados (por razones de seguridad) por Intel, entonces cada usuario de SPI flash tiene acceso completo (lectura/escritura) solo a su región. El resto son de solo lectura o inaccesibles. Hecho conocido: en muchos sistemas, la CPU tiene acceso completo al UEFI BIOS y GbE, acceso de lectura solo a los descriptores flash y ningún acceso a la región Intel ME en absoluto. ¿Por qué muchos y no todos? Lo recomendado es opcional. Te contamos más más adelante en el artículo.

Mecanismos para proteger el firmware de una plataforma informática contra modificaciones.

Obviamente, el firmware de una plataforma informática debe protegerse de un posible compromiso, lo que permitiría a un atacante potencial hacerse un hueco en él (sobrevivir a las actualizaciones/reinstalaciones del sistema operativo), ejecutar su código en los modos más privilegiados, etc. Y delimitar el acceso a las regiones de la memoria flash SPI, por supuesto, no es suficiente. Por lo tanto, se utilizan varios mecanismos específicos de cada entorno de ejecución para proteger el firmware de modificaciones.

Por lo tanto, el firmware Intel ME está firmado para el control de integridad y autenticidad, y el controlador ME lo verifica cada vez que se carga en la memoria ME UMA. Este proceso de verificación ya ha sido discutido por nosotros en uno de los artículosdedicado al subsistema Intel ME.

Y el firmware ACPI EC, por regla general, solo se verifica por su integridad. Sin embargo, debido a que este binario está incluido en UEFI BIOS, casi siempre está sujeto a los mismos mecanismos de protección que utiliza UEFI BIOS. Hablemos de ellos.

Estos mecanismos se pueden dividir en dos categorías.

Protección contra escritura en la región UEFI BIOS

1. Protección física del contenido de la memoria flash SPI con un puente de protección contra escritura;
2. Protección de la proyección de la región UEFI BIOS en el espacio de direcciones de la CPU utilizando los registros PRx del chipset;
3. Bloquear los intentos de escribir en la región UEFI BIOS generando y procesando la interrupción SMI correspondiente configurando los bits BIOS_WE / BLE y SMM_BWP en los registros del conjunto de chips;
4. Una versión más avanzada de esta protección es Intel BIOS Guard (PFAT).

Además de estos mecanismos, los proveedores pueden desarrollar e implementar sus propias medidas de seguridad (por ejemplo, firmando cápsulas con actualizaciones de UEFI BIOS).

Es importante tener en cuenta que en un sistema específico (según el proveedor), es posible que no se apliquen todos los mecanismos de protección anteriores, que no se apliquen en absoluto o que se implementen de forma vulnerable. Puede leer más sobre estos mecanismos y la situación con su implementación en este artículo. Para aquellos interesados, recomendamos que lean toda la serie de artículos sobre la seguridad UEFI BIOS de CodeRush.

Verificación de autenticación UEFI BIOS

Cuando hablamos de tecnologías de arranque confiables, lo primero que viene a la mente es Arranque seguro. Sin embargo, arquitectónicamente, está diseñado para autenticar componentes externos al UEFI BIOS (controladores, cargadores, etc.) y no el firmware en sí.

Por lo tanto, Intel en los SoC con la microarquitectura Bay Trail (2012) implementó un arranque seguro no conmutable por hardware (arranque verificado), que no tiene nada que ver con la tecnología de arranque seguro antes mencionada. Posteriormente (2013), se mejoró este mecanismo y, bajo el nombre de Intel Boot Guard, se lanzó para escritorios con la microarquitectura Haswell.

Antes de describir Intel Boot Guard, veamos los entornos de ejecución en la arquitectura Intel 64 que, en combinación, son las raíces de confianza para esta tecnología de arranque confiable.

CPU Intel

Cap sugiere que el procesador es el entorno de ejecución principal en la arquitectura Intel 64. ¿Por qué es también la raíz de la confianza? Resulta que es la posesión de los siguientes elementos lo que lo hace así:

• La ROM de microcódigo es una memoria no volátil y no regrabable para almacenar microcódigo. Se cree que el microcódigo es la implementación del sistema de instrucciones del procesador en las instrucciones más simples. Ocurre en microcódigo también bichos. Entonces, en el BIOS puede encontrar archivos binarios con actualizaciones de microcódigo (se superponen en el momento del arranque, porque la ROM no se puede sobrescribir). El contenido de estos binarios está encriptado, lo que complica mucho el análisis (por lo tanto, el contenido específico del microcódigo solo lo conocen quienes lo desarrollan), y firmado para controlar la integridad y autenticidad;
• Clave AES para descifrar el contenido de las actualizaciones de microcódigo;
• un hash de la clave pública RSA que verifica la firma de las actualizaciones del microcódigo;
• un hash de la clave pública RSA que verifica la firma de los módulos de código ACM (Authenticated Code Module) desarrollados por Intel que la CPU puede ejecutar antes de que se inicie el BIOS (hola microcódigo) o durante su funcionamiento, cuando ocurren algunos eventos.

Intel ME

Este subsistema en nuestro blog fue dedicado a две Artículo. Recordemos que este entorno ejecutable se basa en el microcontrolador integrado en el chipset y es el más oculto y privilegiado del sistema.

A pesar del sigilo, Intel ME también es la raíz de la confianza, porque tiene:

• ME ROM: memoria no volátil, no regrabable (no se proporciona un método de actualización), que contiene el código de inicio, así como el hash SHA256 de la clave pública RSA, que verifica la firma del firmware Intel ME;
• clave AES para almacenar información secreta;
• acceso a un conjunto de fusibles (FPF, Field Programmable Fuses) integrados en el conjunto de chips para el almacenamiento permanente de cierta información, incluida la información especificada por el proveedor del sistema informático.

Protector de arranque Intel 1.x

Pequeño descargo de responsabilidad. Los números de versión de la tecnología Intel Boot Guard que utilizamos en este artículo son arbitrarios y es posible que no tengan nada que ver con la numeración utilizada en la documentación interna de Intel. Además, la información sobre la implementación de esta tecnología proporcionada aquí se obtuvo durante la ingeniería inversa y puede contener inexactitudes en comparación con la especificación de Intel Boot Guard, que es poco probable que se publique.

Por lo tanto, Intel Boot Guard (BG) es una tecnología de autenticación UEFI BIOS compatible con hardware. A juzgar por su pequeña descripción en el libro [Revelación de la tecnología de seguridad integrada en la plataforma, Capítulo Arrancar con integridad o no arrancar], funciona como una cadena de arranque confiable. Y el primer enlace es el código de arranque (microcódigo) dentro de la CPU, que se activa con el evento RESET (¡no debe confundirse con el vector RESET en el BIOS!). La CPU encuentra un módulo de código (Intel BG startup ACM) desarrollado y firmado por Intel en la memoria flash SPI, lo carga en su caché, lo verifica (ya se señaló anteriormente que la CPU tiene un hash de clave pública que verifica la firma ACM ) y comienza.

Este módulo de código es responsable de verificar una pequeña parte inicial del UEFI BIOS - Initial Boot Block (IBB), que, a su vez, contiene la funcionalidad para verificar la parte principal del UEFI BIOS. Por lo tanto, Intel BG le permite verificar la autenticidad del BIOS antes de iniciar el sistema operativo (que se puede realizar bajo la supervisión de la tecnología Secure Boot).

La tecnología Intel BG proporciona dos modos de operación (y uno no interfiere con el otro, es decir, ambos modos se pueden habilitar en el sistema y ambos se pueden deshabilitar).

Bota medida

En el modo Arranque medido (MB), cada componente de arranque (comenzando con la ROM de arranque de la CPU) "mide" el siguiente utilizando las capacidades del Módulo de plataforma segura (TPM). Para los que no saben, déjame explicarte.

TPM dispone de PCR (Registros de Configuración de Plataforma), que registran el resultado de la operación de hashing según la fórmula:

Aquellos. el valor de PCR actual depende del anterior, y estos registros se reinician solo cuando el sistema está en RESET.

Por lo tanto, en el modo MB, en algún momento, las PCR reflejan un identificador único (dentro de las capacidades de la operación hash) del código o los datos que se "mediron". Los valores de PCR se pueden utilizar en la operación de cifrado de algunos datos (TPM_Seal). Después de eso, su descifrado (TPM_Unseal) solo será posible si los valores de PCR no han cambiado como resultado de la carga (es decir, no se ha modificado un solo componente "medido").

Arranque verificado

Lo más aterrador para aquellos a los que les gusta modificar el UEFI BIOS es el modo de arranque verificado (VB), en el que cada componente de arranque verifica criptográficamente la integridad y autenticidad del siguiente. Y en caso de un error de verificación, (uno de los siguientes) ocurre:

• apagado por tiempo de espera de 1 minuto a 30 minutos (para que el usuario tenga tiempo de comprender por qué su computadora no arranca y, si es posible, intente restaurar el BIOS);
• apagado inmediato (para que el usuario no tenga tiempo de entender y, además, de hacer);
• continuación del trabajo con cara seria (el caso cuando no hay tiempo para la seguridad, porque hay cosas más importantes que hacer).

La elección de la acción depende de la configuración específica de Intel BG (es decir, de la llamada política de aplicación), que el proveedor de la plataforma informática registra permanentemente en un almacenamiento especialmente diseñado: fusibles de chipset (FPF). Más adelante nos detendremos en este punto con más detalle.

Además de la configuración, el proveedor genera dos claves RSA 2048 y crea dos estructuras de datos (que se muestran en la figura):

1. El manifiesto de clave raíz del proveedor (KEYM, Manifiesto de clave raíz OEM), que coloca el SVN (Número de versión de seguridad) de este manifiesto, el hash SHA256 de la clave pública del siguiente manifiesto, la clave pública RSA (es decir, la parte pública del clave raíz del proveedor) para verificar la firma de este manifiesto y la firma misma;
2. El manifiesto de IBB (IBBM, Initial Boot Block Manifest), que pone el SVN de este manifiesto, el hash SHA256 del IBB, la clave pública para verificar la firma de este manifiesto y la firma misma.

El hash SHA256 de la clave raíz OEM se escribe de forma permanente en los fusibles del conjunto de chips (FPF), al igual que la configuración Intel BG. Si la configuración de Intel BG prevé la inclusión de esta tecnología, de ahora en adelante este sistema solo el propietario de la parte privada de la clave raíz OEM puede actualizar el BIOS (es decir, puede volver a calcular estos manifiestos), es decir, proveedor.

Cuando mira la imagen, inmediatamente surgen dudas sobre la necesidad de una cadena de verificación tan larga: podría haber usado un manifiesto. ¿Por qué complicar?

De hecho, Intel brinda al proveedor la oportunidad de utilizar diferentes claves IBB para diferentes líneas de productos y una como raíz. Si se filtra la parte privada de la clave IBB (que firma el segundo manifiesto), el incidente afectará solo a una línea de productos y solo hasta que el proveedor genere un nuevo par y habilite los manifiestos recalculados en la próxima actualización del BIOS.

Pero si la clave raíz está comprometida (con la que se firma el primer manifiesto), no será posible reemplazarla, no se proporciona el procedimiento de revocación. el hash de la parte pública de esta clave se programa en FPF de una vez por todas.

Configuración de Intel Boot Guard

Ahora echemos un vistazo más de cerca a la configuración de Intel BG y el proceso de su creación. Si observa la pestaña correspondiente en la GUI de Flash Image Tool del Intel System Tool Kit (STK), notará que la configuración de Intel BG incluye un hash de la parte pública de la clave raíz del proveedor, un par de oscuros valores, y así sucesivamente. Perfil Intel BG.

La estructura de este perfil:

typedef struct BG_PROFILE
{
	unsigned long Force_Boot_Guard_ACM : 1;
	unsigned long Verified_Boot : 1;
	unsigned long Measured_Boot : 1;
	unsigned long Protect_BIOS_Environment : 1;
	unsigned long Enforcement_Policy : 2; // 00b – do nothing
                                              // 01b – shutdown with timeout
                                              // 11b – immediate shutdown
	unsigned long : 26;
};

En general, la configuración Intel BG es una entidad muy flexible. Considere, por ejemplo, el indicador Force_Boot_Guard_ACM. Cuando se borra, si no se encuentra el módulo ACM de inicio de BG en la memoria flash SPI, no se producirá un arranque de confianza. Será desconfiado.

Ya escribimos anteriormente que la política de aplicación para el modo VB se puede configurar de modo que si falla la verificación, nuevamente, se producirá una descarga no confiable.

Deja cosas como esta en manos de los vendedores...

La GUI de la utilidad proporciona los siguientes perfiles "preparados":

número
régimen
Descripción

0
No_FVME
Tecnología Intel BG deshabilitada

1
VE
Modo VB habilitado, apagado por tiempo de espera

2
VME
ambos modos están habilitados (VB y MB), apagado por tiempo de espera

3
VM
ambos modos están habilitados, sin apagar el sistema

4
FVE
Modo VB habilitado, apagado inmediato

5
FVME
ambos modos habilitados, apagado inmediato

Como ya se mencionó, el proveedor del sistema debe escribir la configuración Intel BG de una vez por todas en los fusibles del conjunto de chips (FPF): un pequeño almacenamiento de información de hardware (según información no verificada, solo 256 bytes) dentro del conjunto de chips, que se puede programar fuera de las instalaciones de producción de Intel (por eso Programable en campo fusibles).

Es excelente para almacenar configuraciones porque:

• tiene un área de almacenamiento de datos programable una sola vez (justo donde está escrita la configuración Intel BG);
• solo Intel ME puede leerlo y programarlo.

Entonces, para establecer la configuración de la tecnología Intel BG en un sistema específico, el proveedor hace lo siguiente durante la producción:

1. Usando la utilidad Flash Image Tool (de Intel STK), crea una imagen de firmware con una configuración determinada de Intel BG como variables dentro de la región Intel ME (el llamado espejo temporal para FPF);
2. Usando la herramienta de programación Flash (de Intel STK), escribe esta imagen en la memoria flash SPI del sistema y cierra el llamado. modo de fabricación (en este caso, el comando correspondiente se envía a Intel ME).

Como resultado de estas operaciones, Intel ME asignará a los FPF los valores especificados del espejo para los FPF en la región ME, establecerá los permisos en los descriptores de flash SPI a los valores recomendados por Intel (descritos al comienzo de la artículo) y realice un RESET del sistema.

Análisis de implementación de Intel Boot Guard

Para analizar la implementación de esta tecnología en un ejemplo específico, verificamos los siguientes sistemas en busca de rastros de la tecnología Intel BG:

Sistema
Nota

Gigabyte GA-H170-D3H
Skylake, hay apoyo

Gigabyte GA-Q170-D3H
Skylake, hay apoyo

Gigabyte GA-B150-HD3
Skylake, hay apoyo

MSI H170A Juegos Pro
Skylake, sin apoyo

Lenovo ThinkPad 460
Skylake, soporte disponible, tecnología habilitada

Lenovo Yoga 2 Pro
Haswell, sin apoyo

Lenovo U330p
Haswell, sin apoyo

"Soporte" significa la presencia del módulo ACM de inicio Intel BG, los manifiestos mencionados anteriormente y el código correspondiente en el BIOS, es decir implementaciones para el análisis.

Como ejemplo, tomemos el descargado de la oficina. imagen del sitio del proveedor de la memoria flash SPI para Gigabyte GA-H170-D3H (versión F4).

ROM de arranque de CPU Intel

En primer lugar, hablemos de las acciones del procesador si la tecnología Intel BG está habilitada.

No fue posible encontrar muestras del microcódigo descifrado, por lo tanto, cómo se implementan las acciones descritas a continuación (en microcódigo o en hardware) es una pregunta abierta. Sin embargo, el hecho de que los procesadores Intel modernos "puedan" realizar estas acciones es un hecho.

Después de salir del estado RESET, el procesador (en cuyo espacio de direcciones ya está mapeado el contenido de la memoria flash) encuentra la FIT (Firmware Interface Table). Encontrarlo es fácil, el puntero está escrito en la dirección FFFF FFC0h.

En este ejemplo, esta dirección contiene el valor FFD6 9500h. En cuanto a esta dirección, el procesador ve la tabla FIT, cuyo contenido se divide en registros. La primera entrada es el encabezado de la siguiente estructura:

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_   ’
	unsigned long  NumEntries; // including FIT header entry
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

Por alguna razón desconocida, la suma de comprobación no siempre se calcula en estas tablas (el campo se deja nulo).

Las entradas restantes apuntan a varios binarios que deben analizarse/ejecutarse antes de que se ejecute el BIOS, es decir, antes de cambiar al vector RESET heredado (FFFF FFF0h). La estructura de cada entrada es la siguiente:

typedef struct FIT_ENTRY
{
	unsigned long  BaseAddress;
	unsigned long  : 32;
	unsigned long  Size;
	unsigned short Version;     // 1.0
	unsigned char  EntryType;
	unsigned char  Checksum;
};

El campo EntryType indica el tipo de bloque al que apunta esta entrada. Conocemos varios tipos:

enum FIT_ENTRY_TYPES
{
	FIT_HEADER = 0,
	MICROCODE_UPDATE,
	BG_ACM,
	BIOS_INIT = 7,
	TPM_POLICY,
	BIOS_POLICY,
	TXT_POLICY,
	BG_KEYM,
	BG_IBBM
};

Ahora es obvio que una de las entradas apunta a la ubicación del binario ACM de inicio de Intel BG. La estructura de encabezado de este binario es típica para los módulos de código desarrollados por Intel (ACM, actualizaciones de microcódigo, secciones de código Intel ME, ...).

typedef struct BG_ACM_HEADER
{
	unsigned short ModuleType;     // 2
	unsigned short ModuleSubType;  // 3
	unsigned long  HeaderLength;   // in dwords
	unsigned long  : 32;
	unsigned long  : 32;
	unsigned long  ModuleVendor;   // 8086h
	unsigned long  Date;           // in BCD format
	unsigned long  TotalSize;      // in dwords
	unsigned long  unknown1[6];
	unsigned long  EntryPoint;
	unsigned long  unknown2[16];
	unsigned long  RsaKeySize;     // in dwords
	unsigned long  ScratchSize;    // in dwords
	unsigned char  RsaPubMod[256];
	unsigned long  RsaPubExp;
	unsigned char  RsaSig[256];
};

El procesador carga este binario en su caché, lo verifica y lo inicia.

Intel BG inicio ACM

Como resultado del análisis del trabajo de esta ACM, quedó claro que hace lo siguiente:

• recibe de Intel ME la configuración Intel BG escrita en los fusibles del conjunto de chips (FPF);
• encuentra manifiestos KEYM e IBBM, los verifica.

Para encontrar estos manifiestos, ACM también usa la tabla FIT, que tiene dos tipos de entradas para apuntar a estas estructuras (consulte FIT_ENTRY_TYPES arriba).

Echemos un vistazo más de cerca a los manifiestos. En la estructura del primer manifiesto, vemos varias constantes oscuras, un hash de la clave pública del segundo manifiesto y una clave raíz OEM pública firmada como una estructura anidada:

typedef struct KEY_MANIFEST
{
	char           Tag[8];          // ‘__KEYM__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned char  : 8;             // 1
	unsigned short : 16;            // 0Bh
	unsigned short : 16;            // 20h == hash size?
	unsigned char  IbbmKeyHash[32]; // SHA256 of an IBBM public key
	BG_RSA_ENTRY   OemRootKey;
};

typedef struct BG_RSA_ENTRY
{
	unsigned char  : 8;             // 10h
	unsigned short : 16;            // 1
	unsigned char  : 8;             // 10h
	unsigned short RsaPubKeySize;   // 800h
	unsigned long  RsaPubExp;
	unsigned char  RsaPubKey[256];
	unsigned short : 16;            // 14
	unsigned char  : 8;             // 10h
	unsigned short RsaSigSize;      // 800h
	unsigned short : 16;            // 0Bh
	unsigned char  RsaSig[256];
};

Para verificar la clave pública de OEM Root Key, recordamos que se utiliza el hash SHA256 de los fusibles, que en este momento ya se ha recibido de Intel ME.

Pasemos al segundo manifiesto. Consta de tres estructuras:

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Boot policies
	IBBS Ibbs;         // IBB description
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // IBBM signature
};

El primero contiene algunas constantes:

typedef struct ACBP
{
	char           Tag[8];          // ‘__ACBP__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 1
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned short : 16;            // x & F0h = 0
	unsigned short : 16;            // 0 < x <= 400h
};

El segundo contiene el hash SHA256 de la IBB y el número de descriptores que describen el contenido de la IBB (es decir, a partir de qué se calcula el hash):

typedef struct IBBS
{
	char           Tag[8];            // ‘__IBBS__’
	unsigned char  : 8;               // 10h
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // x <= 0Fh
	unsigned long  : 32;              // x & FFFFFFF8h = 0
	unsigned long  Unknown[20];
	unsigned short : 16;              // 0Bh
	unsigned short : 16;              // 20h == hash size ?
	unsigned char  IbbHash[32];       // SHA256 of an IBB
	unsigned char  NumIbbDescriptors;
};

Los descriptores IBB siguen esta estructura, uno tras otro. Su contenido tiene el siguiente formato:

typedef struct IBB_DESCRIPTOR
{
	unsigned long  : 32;
	unsigned long  BaseAddress;
	unsigned long  Size;
};

Es simple: cada descriptor contiene la dirección/tamaño de un fragmento IBB. Así, la concatenación de los bloques señalados por estos descriptores (en el orden de los propios descriptores) es IBB. Y, por regla general, IBB es una combinación de todos los módulos de las fases SEC y PEI.

El segundo manifiesto finaliza con una estructura que contiene la clave pública de IBB (verificada por el hash SHA256 del primer manifiesto) y la firma de este manifiesto:

typedef struct PMSG
{
	char           Tag[8];            // ‘__PMSG__’
	unsigned char  : 8;               // 10h
	BG_RSA_ENTRY   IbbKey;
};

Entonces, incluso antes del inicio de la ejecución de UEFI BIOS, el procesador lanzará ACM, que verificará la autenticidad del contenido de las secciones con el código de fase SEC y PEI. Luego, el procesador sale del ACM, se mueve a lo largo del vector RESET y comienza a ejecutar el BIOS.

La partición verificada por PEI debe contener un módulo que verificará el resto del BIOS (código DXE). Este módulo ya está siendo desarrollado por IBV (Independent BIOS Vendor) o el propio proveedor del sistema. Porque Solo los sistemas Lenovo y Gigabyte resultaron estar a nuestra disposición y tener soporte Intel BG, consideremos el código extraído de estos sistemas.

Módulo UEFI BIOS LenovoVerifiedBootPei

En el caso de Lenovo resultó ser el módulo LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, desarrollado por Lenovo.

Su trabajo es buscar (por GUID) una tabla hash para el DXE y verificar el DXE.

if (EFI_PEI_SERVICES->GetBootMode() != BOOT_ON_S3_RESUME)
{
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	if (!VerifyDxe())
		return EFI_SECURITY_VIOLATION;
}

Хеш таблица {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} имеет следующий формат:

typedef struct HASH_TABLE
{
	char          Tag[8];            // ‘$HASHTBL’
	unsigned long NumDxeDescriptors;
	DXE_DESCRIPTORS[];
};

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long Offset;
	unsigned long Size;
};

Módulo UEFI BIOS BootGuardPei

En el caso de Gigabyte resultó ser el módulo BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, desarrollado por AMI, y por tanto presente en cualquier BIOS AMI con soporte Intel BG.

Su algoritmo de operación es algo diferente, sin embargo, se reduce a lo mismo:

int bootMode = EFI_PEI_SERVICES->GetBootMode();

if (bootMode != BOOT_ON_S3_RESUME &&
    bootMode != BOOT_ON_FLASH_UPDATE &&
    bootMode != BOOT_IN_RECOVERY_MODE)
{
	HOB* h = CreateHob();
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	WriteHob(&h, VerifyDxe());
	return h;
}

La tabla hash {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} que busca tiene el siguiente formato:

typedef HASH_TABLE DXE_DESCRIPTORS[];

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long BaseAddress;
	unsigned long Size;
};

Protector de arranque Intel 2.x

Hablemos brevemente sobre otra implementación de Intel Boot Guard, que se encontró en un sistema más nuevo basado en Intel SoC con microarquitectura Apollo Lake: ASRock J4205-IT.

Si bien esta versión solo se utilizará en SoCs (los nuevos sistemas con microarquitectura de procesador Kaby Lake continúan usando Intel Boot Guard 1.x), es de gran interés explorar una nueva opción de arquitectura para plataformas basadas en Intel SoCs, que se ha visto tangible cambios, por ejemplo:

• Las regiones BIOS e Intel ME (o más bien Intel TXE, según la terminología Intel SoC) ahora son una región IFWI;
• aunque Intel BG estaba habilitado en la plataforma, estructuras como FIT, KEYM, IBBM no se encontraron en la memoria flash;
• Además de los núcleos TXE e ISH (x86), se agregó un tercer núcleo (nuevamente ARC, por cierto) al conjunto de chips: PMC (Controlador de administración de energía), asociado con garantizar la operatividad del subsistema de energía y el monitoreo del rendimiento.

El contenido de la nueva región IFWI es un conjunto de los siguientes módulos:

Desplazamiento
nombre
Descripción

0000 2000h
SMIP
alguna configuración de plataforma, firmada por el vendedor

0000 6000h
rbep
Sección de código de firmware Intel TXE, x86, firmada por Intel

0001 0000h
PMCP
sección de código de firmware Intel PMC, ARC, firmado por Intel

0002 0000h
FTPR
Sección de código de firmware Intel TXE, x86, firmada por Intel

0007B000h
UCOD
Actualizaciones de microcódigo de CPU firmadas por Intel

0008 0000h
IBBP
BIOS UEFI, fases SEC/PEI, x86, firmado por el proveedor

0021 8000h
ISHC
sección de código del firmware Intel ISH, x86, firmado por el proveedor

0025 8000h
FTP
Sección de código de firmware Intel TXE, x86, firmada por Intel

0036 1000h
UINP
desconocido

0038 1000h
OBBP
UEFI BIOS, fase DXE, x86, sin firmar

Durante el análisis del firmware de TXE, se hizo evidente que después de RESET, TXE mantiene el procesador en este estado hasta que prepara los contenidos básicos del espacio de direcciones para la CPU (FIT, ACM, vector RESET ...). Además, TXE coloca estos datos en su SRAM, después de lo cual proporciona temporalmente al procesador acceso allí y los "libera" de RESET.

En guardia contra los rootkits

Bueno, ahora pasemos a lo "caliente". Una vez descubrimos que en muchos sistemas, los descriptores flash SPI tienen permisos para acceder a regiones de la memoria flash SPI para que todos los usuarios de esta memoria puedan escribir y leer cualquier región. Aquellos. de ninguna manera.

Después de consultar con la utilidad MEinfo (de Intel STK), vimos que el modo de fabricación en estos sistemas no estaba cerrado, por lo tanto, los fusibles del chipset (FPF) quedaron en un estado indeterminado. Sí, Intel BG no está habilitado ni deshabilitado en tales casos.

Estamos hablando de los siguientes sistemas (con respecto a Intel BG y lo que se describirá más adelante en el artículo, hablaremos de sistemas con microarquitectura de procesador Haswell y superior):

• todos los productos Gigabyte;
• todos los productos MSI;
• 21 modelos de portátiles Lenovo y 4 modelos de servidores Lenovo.

Por supuesto, informamos del hallazgo a estos proveedores, así como a Intel.

La respuesta adecuada siguió sólo de Lenovoque reconoció el problema y lanzó un parche.

Gigabyte Parece que aceptaron información sobre la vulnerabilidad, pero no comentaron de ninguna manera.

Comunicación con MSI completamente estancado en nuestra solicitud de enviar nuestra clave PGP pública (para enviarles un aviso de seguridad encriptado). Afirmaron que "son un fabricante de hardware y no fabrican claves PGP".

Pero más al grano. Dado que los fusibles se dejan en un estado indefinido, el usuario (o atacante) puede programarlos él mismo (lo más difícil es encontrar Intel STK). Esto requiere los siguientes pasos.

1. Inicie el sistema operativo Windows (en general, los pasos que se describen a continuación también se pueden realizar desde Linux, si desarrolla un análogo de Intel STK para el sistema operativo deseado). Con la utilidad MEinfo, asegúrese de que los fusibles de este sistema no estén programados.

2. Lea el contenido de la memoria flash utilizando la herramienta de programación Flash.

3. Abra la imagen de lectura con cualquier herramienta de edición UEFI BIOS, realice los cambios necesarios (implemente un rootkit, por ejemplo), cree/edite las estructuras KEYM e IBBM existentes en la región ME.

La parte pública de la clave RSA se destaca en la imagen, cuyo hash se programará en los fusibles del conjunto de chips junto con el resto de la configuración de Intel BG.

4. Usando Flash Image Tool, cree una nueva imagen de firmware (estableciendo la configuración de Intel BG).

5. Escriba una nueva imagen para flashear usando la herramienta de programación Flash, verifique usando MEinfo que la región ME ahora contiene la configuración de Intel BG.

6. Utilice la herramienta de programación Flash para cerrar el modo de fabricación.

7. El sistema se reiniciará, después de lo cual, utilizando MEinfo, puede verificar que los FPF ahora están programados.

estas acciones por siempre habilite Intel BG en este sistema. Será imposible deshacer la acción, lo que significa:

• solo el propietario de la parte privada de la clave raíz (es decir, el que habilitó Intel BG) podrá actualizar el UEFI BIOS en este sistema;
• si devuelve el firmware original a este sistema, por ejemplo, utilizando un programador, ni siquiera se encenderá (una consecuencia de la política de aplicación en caso de un error de verificación);
• para deshacerse de un BIOS UEFI de este tipo, debe reemplazar el conjunto de chips con FPF programados por uno "limpio" (es decir, vuelva a soldar el conjunto de chips si tiene acceso a una estación de soldadura infrarroja al precio de un automóvil, o simplemente reemplace la placa base ).

Para comprender lo que puede hacer un rootkit de este tipo, debe evaluar qué hace posible ejecutar su código en un entorno UEFI BIOS. Digamos, en el modo más privilegiado del procesador: SMM. Tal rootkit puede tener las siguientes propiedades:

• ejecutarse en paralelo con el sistema operativo (puede configurar el procesamiento generando una interrupción SMI, que será activada por un temporizador);
• tener todas las ventajas de estar en modo SMM (acceso completo al contenido de RAM y recursos de hardware, secreto del sistema operativo);
• El código del rootkit se puede cifrar y descifrar cuando se inicia en modo SMM. Cualquier dato disponible solo en el modo SMM se puede utilizar como clave de cifrado. Por ejemplo, un hash de un conjunto de direcciones en SMRAM. Para obtener esta clave, deberá ingresar al SMM. Y esto se puede hacer de dos maneras. Encuentre el RCE en el código SMM y explótelo, o agregue su propio módulo SMM al BIOS, lo cual es imposible, ya que habilitamos Boot Guard.

Por lo tanto, esta vulnerabilidad permite a un atacante:

• crear un rootkit oculto e inamovible de propósito desconocido en el sistema;
• ejecute su código en uno de los núcleos del conjunto de chips dentro del Intel SoC, es decir, en Intel ISH (eche un vistazo más de cerca a la imagen).

Aunque aún no se han explorado las capacidades del subsistema Intel ISH, parece ser un vector de ataque interesante contra Intel ME.

Hallazgos

1. El estudio proporcionó una descripción técnica de cómo funciona la tecnología Intel Boot Guard. Menos un par de secretos en la seguridad de Intel a través del modelo de oscuridad.
2. Se presenta un escenario de ataque que permite crear un rootkit inamovible en el sistema.
3. Hemos visto que los procesadores Intel modernos pueden ejecutar una gran cantidad de código propietario incluso antes de que se inicie el BIOS.
4. Las plataformas con arquitectura Intel 64 son cada vez menos adecuadas para ejecutar software libre: verificación de hardware, un número cada vez mayor de tecnologías propietarias y subsistemas (tres núcleos en el chipset SoC: x86 ME, x86 ISH y ARC PMC).

Mitigaciones

Los proveedores que intencionalmente dejan abierto el modo de fabricación definitivamente deberían cerrarlo. Hasta ahora, solo están cerrando los ojos y los nuevos sistemas Kaby Lake lo demuestran.

Los usuarios pueden deshabilitar Intel BG en sus sistemas (que se ven afectados por la vulnerabilidad descrita) ejecutando la herramienta de programación Flash con la opción -closemnf. En primer lugar, debe asegurarse (usando MEinfo) de que la configuración de Intel BG en la región ME permita desactivar exactamente esta tecnología después de programar en FPF.

Fuente: habr.com