🥇 Descarga de confianza de Schrödinger. Intel Boot Guard

Propoñemos baixar de novo ao nivel baixo e falar da seguridade das plataformas informáticas compatibles con firmware x86. Esta vez, o ingrediente principal do estudo é Intel Boot Guard (non debe confundirse con Intel BIOS Guard!), unha tecnoloxía de arranque de confianza BIOS compatible con hardware que un vendedor de sistemas informáticos pode activar ou desactivar permanentemente na fase de produción. Pois xa coñecemos a receita da investigación: recortar finamente a implementación desta tecnoloxía mediante enxeñaría inversa, describir a súa arquitectura, enchela de detalles indocumentados, sazonala con vectores de ataque para degustala e mesturala. Imos engadir lume cunha historia sobre como un erro clonado na produción de varios provedores durante anos permite que un potencial atacante use esta tecnoloxía para crear un rootkit oculto que non pode ser eliminado (nin sequera por un programador) no sistema.

Por certo, o artigo baséase nos informes "On Guard for Rootkits: Intel BootGuard" da conferencia ZeroNights 2016 e 29a reunión DefCon Rusia (ambas presentacións aquí).

Firmware para plataforma informática con arquitectura Intel 64

Para comezar, imos responder á pregunta: cal é o firmware dunha plataforma informática moderna coa arquitectura Intel 64? Por suposto, UEFI BIOS. Pero esta resposta non será precisa. Vexamos a figura, que mostra a versión de escritorio (portátil) desta arquitectura.

A ligazón é a base:

Procesador (CPU, Unidade Central de Procesamento), que, ademais dos núcleos principais, ten incorporado un núcleo gráfico (non en todos os modelos) e un controlador de memoria (IMC, Integrated Memory Controller);
Chipset (PCH, Platform Controller Hub), que contén varios controladores para interactuar con dispositivos periféricos e xestionar subsistemas. Entre eles está o notorio Intel Management Engine (ME), que tamén conta cun firmware (Intel ME firmware).

Os portátiles, ademais do anterior, requiren un controlador integrado (ACPI EC, Advanced Control and Power Interface Embedded Controller), que se encarga do funcionamento do subsistema de alimentación, touchpad, teclado, teclas Fn (brillo da pantalla, volume de son, teclado). retroiluminación, etc.) ) e moito máis. E tamén ten o seu propio firmware.

Entón, a combinación do firmware anterior é o firmware da plataforma informática (firmware do sistema), que se almacena nunha memoria flash SPI común. Para que os usuarios desta memoria non se confundan onde está alguén, o contido desta memoria divídese nas seguintes rexións (como se mostra na figura):

UEFI BIOS;
Firmware ACPI EC (apareceu unha rexión separada coa microarquitectura do procesador Skylake (2015), pero de xeito natural aínda non vimos exemplos do seu uso, polo que o firmware do controlador integrado aínda forma parte da UEFI BIOS);
firmware Intel ME;
configuración (enderezo MAC, etc.) do adaptador de rede GbE (Gigabit Ethernet) integrado;
descriptores flash: a rexión principal da memoria flash, que contén punteiros a outras rexións, así como permisos para acceder a elas.

A diferenciación do acceso ás rexións (de acordo cos permisos especificados) é xestionada polo mestre de bus SPI - o controlador SPI integrado no chipset, a través do cal se accede a esta memoria. Se os permisos están configurados cos valores recomendados (por razóns de seguridade) por Intel, entón cada usuario do flash SPI só ten acceso total (lectura/escritura) á súa rexión. O resto son de só lectura ou inaccesibles. Feito coñecido: en moitos sistemas, a CPU ten acceso total á UEFI BIOS e GbE, acceso de lectura só aos descritores flash e sen acceso á rexión Intel ME. Por que moitos e non todos? O que se recomenda é opcional. Contarémosche máis máis adiante no artigo.

Mecanismos para protexer o firmware dunha plataforma informática da modificación

Obviamente, o firmware dunha plataforma informática debería estar protexido de posibles compromisos, o que permitiría que un potencial atacante se afianzase nela (sobrevivir ás actualizacións/reinstalacións do SO), executar o seu código nos modos máis privilexiados, etc. E delimitar o acceso ás rexións de memoria flash SPI, por suposto, non é suficiente. Polo tanto, utilízanse diversos mecanismos específicos de cada contorno de execución para protexer o firmware de modificacións.

Así, o firmware Intel ME está asinado para o control de integridade e autenticidade, e o controlador ME comproba cada vez que se carga na memoria ME UMA. Este proceso de verificación xa foi discutido por nós nun dos artigosdedicado ao subsistema Intel ME.

E o firmware ACPI EC, por regra xeral, só se verifica a súa integridade. Non obstante, debido ao feito de que este binario está incluído na UEFI BIOS, case sempre está suxeito aos mesmos mecanismos de protección que usa a UEFI BIOS. Falemos deles.

Estes mecanismos pódense dividir en dúas categorías.

Protección contra escritura na rexión da BIOS UEFI

Protección física do contido da memoria flash SPI cun puente de protección contra escritura;
Protección da proxección da rexión UEFI BIOS no espazo de enderezos da CPU mediante os rexistros PRx do chipset;
Bloquear os intentos de escribir na rexión UEFI BIOS xerando e procesando a interrupción SMI correspondente configurando os bits BIOS_WE / BLE e SMM_BWP nos rexistros do chipset;
Unha versión máis avanzada desta protección é Intel BIOS Guard (PFAT).

Ademais destes mecanismos, os provedores poden desenvolver e implementar as súas propias medidas de seguridade (por exemplo, asinar cápsulas con actualizacións de BIOS UEFI).

É importante ter en conta que nun sistema específico (dependendo do provedor), non se poden aplicar todos os mecanismos de protección anteriores, poden non aplicarse en absoluto ou poden implementarse de forma vulnerable. Podes ler máis sobre estes mecanismos e a situación coa súa implementación en Este artigo. Para os interesados, recomendámoslle que lea toda a serie de artigos sobre seguridade da BIOS UEFI desde CodeRush.

Verificación de autenticación UEFI BIOS

Cando falamos de tecnoloxías de arranque de confianza, o primeiro que se nos ocorre é o arranque seguro. Non obstante, arquitectónicamente, está deseñado para autenticar compoñentes externos á UEFI BIOS (controladores, cargadores, etc.), e non o propio firmware.

Polo tanto, Intel nos SoC coa microarquitectura Bay Trail (2012) implementou un arranque seguro de hardware non conmutable (Arranque verificado), que non ten nada que ver coa tecnoloxía de arranque seguro mencionada anteriormente. Máis tarde (2013), este mecanismo foi mellorado e, baixo o nome de Intel Boot Guard, lanzouse para escritorios coa microarquitectura Haswell.

Antes de describir Intel Boot Guard, vexamos os tempos de execución na arquitectura Intel 64, que, en combinación, son as raíces da confianza para esta tecnoloxía de arranque de confianza.

CPU Intel

Cap suxire que o procesador é o principal ambiente de execución na arquitectura Intel 64. Por que tamén é a raíz da confianza? Resulta que é a posesión dos seguintes elementos o que o fai así:

Microcode ROM é unha memoria non volátil e non regrabable para almacenar microcódigos. Crese que o microcódigo é a implementación do sistema de instrucións do procesador nas instrucións máis sinxelas. Tamén ocorre no microcódigo erros. Polo tanto, na BIOS podes atopar binarios con actualizacións de microcódigos (superpoñense no momento do arranque, porque a ROM non se pode sobrescribir). O contido destes binarios está cifrado, o que dificulta moito a análise (polo tanto, o contido específico do microcódigo é coñecido só por quen o desenvolve), e asinado para controlar a integridade e autenticidade;
Chave AES para descifrar o contido das actualizacións de microcódigos;
un hash da clave pública RSA que verifica a sinatura das actualizacións do microcódigo;
Hash de chave pública RSA, que comproba a sinatura dos módulos de código ACM (Authenticated Code Module) desenvolvidos por Intel, que a CPU pode executar antes de que se inicie o BIOS (hola microcódigo) ou durante o seu funcionamento, cando ocorren algúns eventos.

Intel ME

Este subsistema do noso blog estaba dedicado dous Artigo. Recordemos que este entorno executable baséase no microcontrolador integrado no chipset e é o máis oculto e privilexiado do sistema.

A pesar do sigilo, Intel ME tamén é a raíz da confianza, porque ten:

ME ROM - memoria non volátil e non reescribible (non se proporciona ningún método de actualización), que contén o código de inicio, así como o hash SHA256 da clave pública RSA, que verifica a sinatura do firmware Intel ME;
chave AES para almacenar información secreta;
acceso a un conxunto de fusibles (FPF, Field Programmable Fuses) integrados no chipset para o almacenamento permanente dalgunha información, incluída a información especificada polo vendedor do sistema informático.

Intel Boot Guard 1.x

Pequena exención de responsabilidade. Os números de versión da tecnoloxía Intel Boot Guard que usamos neste artigo son arbitrarios e poden non ter nada que ver coa numeración utilizada na documentación interna de Intel. Ademais, a información sobre a implementación desta tecnoloxía que se ofrece aquí foi obtida durante a enxeñaría inversa e pode conter imprecisións en comparación coa especificación de Intel Boot Guard, que é pouco probable que se publique.

Entón, Intel Boot Guard (BG) é unha tecnoloxía de autenticación UEFI BIOS compatible con hardware. A xulgar pola súa pequena descrición no libro [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], funciona como unha cadea de arranque de confianza. E a primeira ligazón é o código de arranque (microcódigo) dentro da CPU, que se activa polo evento RESET (que non debe confundirse co vector RESET da BIOS!). A CPU atopa un módulo de código (Intel BG startup ACM) desenvolvido e asinado por Intel na memoria flash SPI, cárgao na súa caché, verifícao (xa se indicou anteriormente que a CPU ten un hash de chave pública que verifica a sinatura ACM). ) e comeza.

Este módulo de código encárgase de verificar unha pequena parte inicial da UEFI BIOS - Initial Boot Block (IBB), que, á súa vez, contén a funcionalidade para verificar a parte principal da UEFI BIOS. Así, Intel BG permítelle verificar a autenticidade da BIOS antes de iniciar o SO (que se pode realizar baixo a supervisión da tecnoloxía Secure Boot).

A tecnoloxía Intel BG ofrece dous modos de funcionamento (e un non interfire co outro, é dicir, ambos os dous modos pódense activar no sistema e ambos poden desactivarse).

Arranque medido

No modo de arranque medido (MB), cada compoñente de arranque (comezando pola ROM de inicio da CPU) "mide" o seguinte usando as capacidades do módulo de plataforma de confianza (TPM). Para quen non o saiba, déixame explicar.

TPM ten PCR (Rexistros de Configuración de Plataforma), que rexistran o resultado da operación de hash segundo a fórmula:

Eses. o valor actual de PCR depende do anterior, e estes rexistros só se restablecen cando o sistema se RESET.

Así, no modo MB, nalgún momento, os PCR reflicten un identificador único (dentro das capacidades da operación hash) do código ou dos datos que se "mediron". Os valores de PCR pódense usar na operación de cifrado dalgúns datos (TPM_Seal). Despois diso, o seu descifrado (TPM_Unseal) só será posible se os valores de PCR non cambiaron como resultado da carga (é dicir, non se modificou ningún compoñente "medido").

Arranque verificado

O máis asustado para os que lles gusta modificar a UEFI BIOS é o modo de arranque verificado (VB), no que cada compoñente de arranque verifica criptograficamente a integridade e autenticidade do seguinte. E no caso de producirse un erro de verificación (un dos seguintes):

apagado por tempo de espera de 1 minuto a 30 minutos (para que o usuario teña tempo para entender por que o seu ordenador non se inicia e, se é posible, tentaría restaurar a BIOS);
apagado inmediato (para que o usuario non teña tempo de entender e, ademais, de facer);
continuación do traballo con cara recta (o caso no que non hai tempo para a seguridade, porque hai cousas máis importantes que facer).

A elección da acción depende da configuración especificada de Intel BG (é dicir, da chamada política de aplicación), que o vendedor da plataforma informática rexistra permanentemente nun almacenamento especialmente deseñado: fusibles de chipset (FPF). Deterémonos neste punto con máis detalle máis adiante.

Ademais da configuración, o provedor xera dúas claves RSA 2048 e crea dúas estruturas de datos (mostradas na figura):

O manifesto da clave raíz do vendedor (KEYM, OEM Root Key Manifest), que pon o SVN (número de versión de seguranza) deste manifesto, o hash SHA256 da clave pública do seguinte manifesto, a clave pública RSA (é dicir, a parte pública do clave raíz do provedor) para verificar a sinatura deste manifesto e a propia sinatura;
O Manifesto IBB (IBBM, Initial Boot Block Manifest), que pon o SVN deste manifesto, o hash SHA256 do IBB, a clave pública para verificar a sinatura deste manifesto e a propia sinatura.

O hash SHA256 da clave raíz OEM está escrito permanentemente nos fusibles do chipset (FPF), do mesmo xeito que a configuración de Intel BG. Se a configuración de Intel BG prevé a inclusión desta tecnoloxía, a partir de agora este sistema só o propietario da parte privada da clave raíz OEM pode actualizar o BIOS (é dicir, poder recalcular estes manifestos), é dicir. provedor.

Cando miras a imaxe, inmediatamente xorden dúbidas sobre a necesidade dunha cadea de verificación tan longa: poderías ter usado un manifesto. Por que complicar?

De feito, Intel ofrece así ao vendedor a oportunidade de usar diferentes claves IBB para diferentes liñas de produtos e unha como raíz. Se se filtra a parte privada da clave IBB (que asina o segundo manifesto), o incidente afectará só a unha liña de produtos e só ata que o provedor xere un novo par e habilite os manifestos recalculados na próxima actualización da BIOS.

Pero se a clave raíz está comprometida (coa que se asina o primeiro manifesto), non será posible substituíla, non se proporciona o procedemento de revogación. o hash da parte pública desta chave está programado en FPF dunha vez por todas.

Configuración de Intel Boot Guard

Agora vexamos máis de cerca a configuración de Intel BG e o proceso da súa creación. Se miras a pestana correspondente na GUI da ferramenta de imaxe Flash do Kit de ferramentas do sistema Intel (STK), notarás que a configuración de Intel BG inclúe un hash da parte pública da clave raíz do vendedor, un par de escuras. valores, etc. Perfil Intel BG.

Estrutura deste 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 xeral, a configuración de Intel BG é unha entidade moi flexible. Considere, por exemplo, a bandeira Force_Boot_Guard_ACM. Cando se borra, se non se atopa o módulo ACM de inicio de BG no flash SPI, non se producirá ningún arranque de confianza. Será pouco fiable.

Xa escribimos anteriormente que a política de aplicación para o modo VB pódese configurar para que, se a verificación falla, de novo, se producirá unha descarga non fiable.

Deixa cousas así aos vendedores...

A GUI da utilidade ofrece os seguintes perfís "preparados":

Non
Modo
Descrición

0
Non_FVME
Tecnoloxía Intel BG desactivada

1
VE
Modo VB activado, apagado por tempo de espera

2
VME
ambos os modos están habilitados (VB e MB), apagado por tempo de espera

3
VM
ambos os modos están habilitados, sen apagar o sistema

4
FVE
Modo VB activado, apagado inmediato

5
FVME
ambos modos activados, apagado inmediato

Como xa se mencionou, a configuración de Intel BG debe ser escrita dunha vez por todas polo vendedor do sistema en fusibles de chipset (FPF): un pequeno almacenamento de información de hardware (segundo información non verificada, só 256 bytes) dentro do chipset, que se pode programar fóra. das instalacións de produción de Intel (polo que é por iso Programable en campo fusibles).

É ideal para almacenar a configuración porque:

ten unha área de almacenamento de datos programable unha soa vez (xusto onde está escrita a configuración de Intel BG);
só Intel ME pode lelo e programalo.

Así, para establecer a configuración para a tecnoloxía Intel BG nun sistema específico, o vendedor fai o seguinte durante a produción:

Usando a utilidade Flash Image Tool (de Intel STK), crea unha imaxe de firmware cunha determinada configuración de Intel BG como variables dentro da rexión Intel ME (o chamado espello temporal para FPF);
Usando a ferramenta de programación Flash (de Intel STK), escribe esta imaxe na memoria flash SPI do sistema e pecha o chamado. modo de fabricación (neste caso, o comando correspondente envíase a Intel ME).

Como resultado destas operacións, Intel ME comprometerá aos FPF os valores dados do espello para os FPF na rexión ME, establecerá os permisos nos descritores flash SPI cos valores recomendados por Intel (descritos ao comezo do artigo) e realice un RESET do sistema.

Análise de implementación de Intel Boot Guard

Para analizar a implementación desta tecnoloxía nun exemplo específico, comprobamos os seguintes sistemas para detectar rastros da tecnoloxía Intel BG:

Sistema
Nota

Gigabyte GA-H170-D3H
Skylake, hai apoio

Gigabyte GA-Q170-D3H
Skylake, hai apoio

Gigabyte GA-B150-HD3
Skylake, hai apoio

MSI H170A Gaming Pro
Skylake, sen apoio

Lenovo ThinkPad 460
Skylake, soporte dispoñible, tecnoloxía habilitada

Lenovo Yoga 2 Pro
Haswell, sen apoio

Lenovo U330p
Haswell, sen apoio

"Soporte" significa a presenza do módulo ACM de inicio Intel BG, os manifestos mencionados anteriormente e o código correspondente na BIOS, é dicir. implementacións para análise.

Como exemplo, poñamos o descargado da oficina. Imaxe do sitio do provedor da memoria flash SPI para Gigabyte GA-H170-D3H (versión F4).

ROM de arranque da CPU Intel

En primeiro lugar, imos falar sobre as accións do procesador se a tecnoloxía Intel BG está activada.

Non foi posible atopar mostras do microcódigo descifrado, polo tanto, como se implementan as accións descritas a continuación (en microcódigo ou en hardware) é unha cuestión aberta. Non obstante, o feito de que os procesadores Intel modernos "poden" realizar estas accións é un feito.

Despois de saír do estado RESET, o procesador (en cuxo espazo de enderezos xa está mapeado o contido da memoria flash) atopa a FIT (Firmware Interface Table). Buscalo é doado, o punteiro a el está escrito no enderezo FFFF FFC0h.

Neste exemplo, este enderezo contén o valor FFD6 9500h. Volvendo a este enderezo, o procesador ve a táboa FIT, cuxo contido está dividido en rexistros. A primeira entrada é o título da seguinte estrutura:

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 algún motivo descoñecido, a suma de verificación non sempre se calcula nestas táboas (o campo queda nulo).

As entradas restantes apuntan a varios binarios que deben ser analizados/executados antes de executar a BIOS, é dicir. antes de cambiar ao vector RESET heredado (FFFF FFF0h). A estrutura de cada unha destas entradas é a seguinte:

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

O campo EntryType indica o tipo de bloque ao que apunta esta entrada. Coñecemos 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
};

Agora é obvio que unha das entradas apunta á localización do binario ACM de inicio de Intel BG. A estrutura de cabeceira deste binario é típica dos módulos de código desenvolvidos por Intel (ACM, actualizacións de microcódigos, seccións 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];
};

O procesador carga este binario na súa caché, verifica e lánzao.

Inicio Intel BG ACM

Como resultado da análise do traballo desta ACM, quedou claro que fai o seguinte:

recibe de Intel ME a configuración Intel BG escrita nos fusibles do chipset (FPF);
atopa os manifestos de KEYM e IBBM, verifícaos.

Para atopar estes manifestos, ACM tamén usa a táboa FIT, que ten dous tipos de entradas para apuntar a estas estruturas (consulte FIT_ENTRY_TYPES arriba).

Vexamos máis de cerca os manifestos. Na estrutura do primeiro manifesto, vemos varias constantes escuras, un hash da chave pública do segundo manifesto e unha clave raíz OEM pública asinada como unha estrutura aniñada:

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 a clave pública da clave raíz OEM, recordamos que se utiliza o hash SHA256 dos fusibles, que neste momento xa se recibiu de Intel ME.

Pasemos ao segundo manifesto. Consta de tres estruturas:

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

O primeiro contén algunhas 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
};

O segundo contén o hash SHA256 do IBB e o número de descritores que describen o contido do IBB (é dicir, a partir de que se calcula o 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;
};

Os descritores IBB seguen esta estrutura, un despois do outro. O seu contido ten o seguinte formato:

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

É sinxelo: cada descritor contén o enderezo/tamaño dun fragmento IBB. Así, a concatenación dos bloques sinalados por estes descritores (na orde dos propios descritores) é IBB. E, por regra xeral, IBB é unha combinación de todos os módulos das fases SEC e PEI.

O segundo manifesto remata cunha estrutura que contén a clave pública IBB (verificada polo hash SHA256 do primeiro manifesto) e a sinatura deste manifesto:

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

Así, mesmo antes do inicio da execución da UEFI BIOS, o procesador lanzará ACM, que verificará a autenticidade do contido das seccións co código de fase SEC e PEI. A continuación, o procesador sae do ACM, móvese ao longo do vector RESET e comeza a executar o BIOS.

A partición verificada PEI debe conter un módulo que comprobará o resto da BIOS (código DXE). Este módulo xa está sendo desenvolvido polo IBV (Independent BIOS Vendor) ou polo propio vendedor do sistema. Porque Só os sistemas Lenovo e Gigabyte resultaron estar á nosa disposición e contando con soporte Intel BG, consideremos o código extraído destes sistemas.

Módulo UEFI BIOS LenovoVerifiedBootPei

No caso de Lenovo, resultou ser o módulo LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, desenvolvido por Lenovo.

O seu traballo é buscar (por GUID) unha táboa hash para o DXE e verificar o 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

No caso de Gigabyte, resultou ser o módulo BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, desenvolvido por AMI e, polo tanto, presente en calquera BIOS AMI con soporte Intel BG.

O seu algoritmo de funcionamento é algo diferente, con todo, redúcese ao mesmo:

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;
}

A táboa hash {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} que busca ten o seguinte formato:

typedef HASH_TABLE DXE_DESCRIPTORS[];

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

Intel Boot Guard 2.x

Falemos brevemente doutra implementación de Intel Boot Guard, que se atopou nun sistema máis novo baseado en Intel SoC con microarquitectura Apollo Lake: ASRock J4205-IT.

Aínda que esta versión só se utilizará en SoC (os novos sistemas con microarquitectura do procesador Kaby Lake seguen utilizando Intel Boot Guard 1.x), é de gran interese explorar unha nova opción de arquitectura para plataformas baseadas en SoC Intel, que se viu tanxible. cambios, por exemplo:

As rexións da BIOS e Intel ME (ou máis ben Intel TXE, segundo a terminoloxía Intel SoC) son agora unha rexión IFWI;
aínda que Intel BG estaba habilitado na plataforma, estruturas como FIT, KEYM, IBBM non se atoparon na memoria flash;
Ademais dos núcleos TXE e ISH (x86), engadiuse ao chipset un terceiro núcleo (de novo ARC, por certo) - PMC (Controlador de Xestión de Energía), asociado a garantir a operatividade do subsistema de alimentación e o seguimento do rendemento.

O contido da nova rexión IFWI é un conxunto dos seguintes módulos:

Parcialidade
nome
Descrición

0000 2000 horas
SMIP
algunha configuración da plataforma, asinada polo vendedor

0000 6000 horas
RBEP
Sección de código de firmware Intel TXE, x86, asinado por Intel

0001 0000 horas
PMCP
sección de código de firmware Intel PMC, ARC, asinada por Intel

0002 0000 horas
FTPR
Sección de código de firmware Intel TXE, x86, asinado por Intel

0007B000h
UCOD
Actualizacións de microcódigos da CPU asinadas por Intel

0008 0000 horas
IBBP
UEFI BIOS, fases SEC/PEI, x86, asinado polo provedor

0021 8000 horas
ISHC
sección de código do firmware Intel ISH, x86, asinado polo vendedor

0025 8000 horas
NFTP
Sección de código de firmware Intel TXE, x86, asinado por Intel

0036 1000 horas
IUNP
é descoñecido

0038 1000 horas
OBBP
UEFI BIOS, fase DXE, x86, sen asinar

Durante a análise do firmware TXE, fíxose evidente que despois do RESET, TXE mantén o procesador neste estado ata que prepara os contidos básicos do espazo de enderezos para a CPU (FIT, ACM, vector RESET...). Ademais, TXE coloca estes datos na súa SRAM, despois de que proporciona acceso temporalmente ao procesador alí e "libera" de RESET.

En garda dos rootkits

Ben, agora imos pasar ao "quente". Unha vez descubrimos que en moitos sistemas, os descritores flash SPI teñen permisos para acceder a rexións da memoria flash SPI para que todos os usuarios desta memoria poidan escribir e ler calquera rexión. Eses. de ningún xeito.

Despois de comprobar coa utilidade MEinfo (de Intel STK), vimos que o modo de fabricación destes sistemas non estaba pechado, polo tanto, os fusibles do chipset (FPF) quedaron nun estado indeterminado. Si, Intel BG non está nin activado nin desactivado nestes casos.

Estamos a falar dos seguintes sistemas (respecto de Intel BG e do que se describirá máis adiante no artigo, falaremos de sistemas con microarquitectura do procesador Haswell e superior):

todos os produtos Gigabyte;
todos os produtos MSI;
21 modelos de portátiles Lenovo e 4 modelos de servidores Lenovo.

Por suposto, informamos do achado a estes provedores, así como a Intel.

A resposta adecuada só seguía de Lenovoquen recoñeceu o problema e lanzou un parche.

Gigabyte Parece que aceptaron información sobre a vulnerabilidade, pero non comentaron de ningún xeito.

Comunicación con MSI completamente paralizado a nosa solicitude para enviar a nosa clave PGP pública (para enviarlles un aviso de seguridade cifrado). Afirmaron que "son un fabricante de hardware e non fabrican chaves PGP".

Pero máis ao punto. Dado que os fusibles quedan nun estado indefinido, o usuario (ou atacante) pode programalos el mesmo (o máis difícil é atopar Intel STK). Isto require os seguintes pasos.

1. Arranque no sistema operativo Windows (en xeral, os pasos descritos a continuación tamén se poden facer desde Linux, se desenvolve un análogo de Intel STK para o sistema operativo desexado). Usando a utilidade MEinfo, asegúrese de que os fusibles deste sistema non estean programados.

2. Le o contido da memoria flash usando a ferramenta de programación flash.

3. Abra a imaxe lida usando calquera ferramenta de edición da BIOS UEFI, faga os cambios necesarios (implemente un rootkit, por exemplo), cree / edite as estruturas KEYM e IBBM existentes na rexión ME.

Na imaxe destaca a parte pública da clave RSA, cuxo hash se programará nos fusibles do chipset xunto co resto da configuración de Intel BG.

4. Usando a ferramenta de imaxe Flash, crea unha nova imaxe de firmware (configurando a configuración de Intel BG).

5. Escriba unha nova imaxe para flashear usando a ferramenta de programación Flash, verifique con MEinfo que a rexión ME contén agora a configuración Intel BG.

6. Use a ferramenta de programación Flash para pechar o modo de fabricación.

7. O sistema reiniciarase, despois de que, usando MEinfo, pode comprobar que os FPF están agora programados.

Estas accións para sempre habilite Intel BG neste sistema. Será imposible desfacer a acción, o que significa:

só o propietario da parte privada da clave raíz (é dicir, o que activou Intel BG) poderá actualizar a UEFI BIOS neste sistema;
se devolves o firmware orixinal a este sistema, por exemplo, usando un programador, nin sequera se acenderá (unha consecuencia da política de aplicación en caso de erro de verificación);
para desfacerse deste tipo de BIOS UEFI, cómpre substituír o chipset con FPF programados por un "limpio" (é dicir, volver a soldar o chipset se ten acceso a unha estación de soldadura por infravermellos ao prezo dun coche, ou simplemente substituír a placa base). ).

Para comprender o que pode facer un rootkit deste tipo, cómpre avaliar o que fai posible executar o seu código nun ambiente UEFI BIOS. Digamos, no modo máis privilexiado do procesador - SMM. Este rootkit pode ter as seguintes propiedades:

executarse en paralelo co SO (pode configurar o procesamento xerando unha interrupción SMI, que se activará mediante un temporizador);
ten todas as vantaxes de estar en modo SMM (acceso completo ao contido da RAM e aos recursos de hardware, segredo desde o SO);
O código rootkit pódese cifrar e descifrar cando se inicia no modo SMM. Calquera dato dispoñible só no modo SMM pódese usar como clave de cifrado. Por exemplo, un hash dun conxunto de enderezos en SMRAM. Para obter esta chave, terás que subir ao SMM. E isto pódese facer de dúas maneiras. Busca o RCE no código SMM e explota-lo, ou engade o teu propio módulo SMM á BIOS, o que é imposible, xa que activamos Boot Guard.

Así, esta vulnerabilidade permite que un atacante:

crear un rootkit oculto e irremovible de propósito descoñecido no sistema;
executa o teu código nun dos núcleos do chipset dentro do Intel SoC, é dicir, no Intel ISH (bóllalle máis de preto a imaxe).

Aínda que aínda non se exploraron as capacidades do subsistema Intel ISH, parece ser un vector de ataque interesante contra Intel ME.

Descubrimentos

O estudo proporcionou unha descrición técnica de como funciona a tecnoloxía Intel Boot Guard. Menos un par de segredos na seguridade de Intel a través do modelo de escuridade.
Preséntase un escenario de ataque que permite crear un rootkit non extraíble no sistema.
Vimos que os procesadores Intel modernos son capaces de executar moito código propietario mesmo antes de que se inicie a BIOS.
As plataformas con arquitectura Intel 64 son cada vez menos adecuadas para executar software libre: verificación de hardware, un número crecente de tecnoloxías e subsistemas propietarios (tres núcleos no chipset SoC: x86 ME, x86 ISH e ARC PMC).

Mitigacións

Os provedores que deixan aberto o modo de fabricación intencionalmente deberían pechalo definitivamente. Ata agora, só están pechando os ollos e os novos sistemas Kaby Lake así o demostran.

Os usuarios poden desactivar Intel BG nos seus sistemas (que están afectados pola vulnerabilidade descrita) executando a ferramenta de programación Flash coa opción -closemnf. En primeiro lugar, debes asegurarte (usando MEinfo) de que a configuración de Intel BG na rexión ME prevé desactivar exactamente esta tecnoloxía despois da programación en FPF.

Fonte: www.habr.com

A bota de confianza de Schrödinger. Intel Boot Guard