🥇Descàrrega de confiança de Schrödinger. Intel Boot Guard

Proposem tornar a baixar al nivell baix i parlar de la seguretat de les plataformes informàtiques compatibles amb firmware x86. Aquesta vegada, l'ingredient principal de la investigació és Intel Boot Guard (que no s'ha de confondre amb Intel BIOS Guard!): una tecnologia d'arrencada de confiança de la BIOS compatible amb maquinari que un proveïdor de sistemes informàtics pot habilitar o desactivar permanentment en l'etapa de producció. Bé, ja coneixem la recepta de la investigació: retallar la implementació d'aquesta tecnologia mitjançant enginyeria inversa, descriure la seva arquitectura, omplir-la de detalls no documentats, amanir-la amb vectors d'atac per tastar-la i barrejar-la. Afegim foc amb una història sobre com un error clonat en la producció de diversos venedors durant anys permet a un atacant potencial utilitzar aquesta tecnologia per crear un rootkit ocult que no pot ser eliminat (ni tan sols per un programador) al sistema.

Per cert, l'article es basa en els informes "On Guard for Rootkits: Intel BootGuard" de la conferència ZeroNights 2016 i 29a reunió DefCon Rússia (ambdues presentacions aquí).

Firmware per a una plataforma informàtica amb arquitectura Intel 64

Per començar, responem a la pregunta: quin és el firmware d'una plataforma informàtica moderna amb l'arquitectura Intel 64? Per descomptat, UEFI BIOS. Però aquesta resposta no serà precisa. Fem una ullada a la figura, que mostra la versió d'escriptori (ordinador portàtil) d'aquesta arquitectura.

La base és l'enllaç:

Processador (CPU, Unitat central de processament), que, a més dels nuclis principals, té incorporat un nucli gràfic (no en tots els models) i un controlador de memòria (IMC, Integrated Memory Controller);
Chipset (PCH, Platform Controller Hub), que conté diversos controladors per interactuar amb dispositius perifèrics i gestionar subsistemes. Entre ells hi ha el famós Intel Management Engine (ME), que també té un firmware (Intel ME firmware).

Els ordinadors portàtils, a més de l'anterior, requereixen un controlador integrat (ACPI EC, Advanced Control and Power Interface Embedded Controller), que s'encarrega del funcionament del subsistema d'alimentació, touchpad, teclat, tecles Fn (lluminositat de la pantalla, volum de so, teclat). llum de fons, etc.) i més. I també té el seu propi firmware.

Per tant, la combinació del microprogramari anterior és el microprogramari de la plataforma de l'ordinador (firmware del sistema), que s'emmagatzema en una memòria flaix SPI comuna. Perquè els usuaris d'aquesta memòria no es confonguin on es troba algú, el contingut d'aquesta memòria es divideix en les regions següents (com es mostra a la figura):

UEFI BIOS;
El firmware ACPI EC (va aparèixer una regió separada amb la microarquitectura del processador Skylake (2015), però a la natura encara no hem vist exemples del seu ús, de manera que el microprogramari del controlador incrustat encara forma part de la BIOS UEFI);
firmware Intel ME;
configuració (adreça MAC, etc.) de l'adaptador de xarxa GbE (Gigabit Ethernet) integrat;
descriptors flash: la regió principal de la memòria flash, que conté punters a altres regions, així com permisos per accedir-hi.

La diferenciació de l'accés a les regions (d'acord amb els permisos especificats) la gestiona el mestre de bus SPI: el controlador SPI integrat al chipset, a través del qual s'accedeix a aquesta memòria. Si els permisos s'estableixen amb els valors recomanats (per raons de seguretat) per Intel, aleshores cada usuari del flash SPI només té accés complet (lectura/escriptura) a la seva regió. La resta són de només lectura o inaccessibles. Fet conegut: en molts sistemes, la CPU té accés complet a la UEFI BIOS i GbE, accés de lectura només als descriptors flash i cap accés a la regió Intel ME. Per què molts i no tots? El que es recomana és opcional. Més endavant us explicarem més a l'article.

Mecanismes per protegir el firmware d'una plataforma informàtica de modificacions

Òbviament, el microprogramari d'una plataforma informàtica hauria d'estar protegit de possibles compromisos, la qual cosa permetria a un potencial atacant agafar-hi peu (sobreviure a les actualitzacions/reinstal·lacions del sistema operatiu), executar el seu codi en els modes més privilegiats, etc. I delimitar l'accés a les regions de memòria flash SPI, per descomptat, no és suficient. Per tant, s'utilitzen diversos mecanismes específics de cada entorn d'execució per protegir el microprogramari de modificacions.

Per tant, el microprogramari Intel ME està signat per controlar la integritat i l'autenticitat, i el controlador ME el verifica cada vegada que es carrega a la memòria ME UMA. Aquest procés de verificació ja l'hem comentat en un dels articlesdedicat al subsistema Intel ME.

I el firmware ACPI EC, per regla general, només es comprova la integritat. Tanmateix, a causa del fet que aquest binari està inclòs a la UEFI BIOS, gairebé sempre està subjecte als mateixos mecanismes de protecció que utilitza la UEFI BIOS. Parlem d'ells.

Aquests mecanismes es poden dividir en dues categories.

Protecció d'escriptura a la regió UEFI BIOS

Protecció física del contingut de la memòria flash SPI amb un pont de protecció contra escriptura;
Protecció de la projecció de la regió UEFI BIOS a l'espai d'adreces de la CPU mitjançant els registres PRx del chipset;
Bloquejar els intents d'escriure a la regió UEFI BIOS generant i processant la interrupció SMI corresponent establint els bits BIOS_WE / BLE i SMM_BWP als registres del chipset;
Una versió més avançada d'aquesta protecció és Intel BIOS Guard (PFAT).

A més d'aquests mecanismes, els venedors poden desenvolupar i implementar les seves pròpies mesures de seguretat (per exemple, signar càpsules amb actualitzacions de BIOS UEFI).

És important tenir en compte que en un sistema específic (segons el venedor) no s'apliquen tots els mecanismes de protecció anteriors, és possible que no s'apliquen en absolut o que s'implementen d'una manera vulnerable. Podeu llegir més sobre aquests mecanismes i la situació amb la seva implementació a aquest article. Per als interessats, us recomanem que llegiu tota la sèrie d'articles sobre seguretat UEFI BIOS CodeRush.

Verificació d'autenticació UEFI BIOS

Quan parlem de tecnologies d'arrencada de confiança, el primer que ens ve al cap és l'arrencada segura. Tanmateix, arquitectònicament, està dissenyat per autenticar components externs a la UEFI BIOS (controladors, carregadors, etc.), i no el microprogramari en si.

Per tant, Intel en SoCs amb la microarquitectura Bay Trail (2012) va implementar un maquinari no commutable Secure Boot (Verified Boot), que no té res a veure amb la tecnologia Secure Boot esmentada anteriorment. Més tard (2013), aquest mecanisme es va millorar i, sota el nom d'Intel Boot Guard, es va llançar per a ordinadors de sobretaula amb la microarquitectura Haswell.

Abans de descriure Intel Boot Guard, mirem els temps d'execució de l'arquitectura Intel 64, que, en combinació, són les arrels de la confiança d'aquesta tecnologia d'arrencada de confiança.

CPU Intel

Cap suggereix que el processador és el principal entorn d'execució de l'arquitectura Intel 64. Per què també és l'arrel de la confiança? Resulta que és la possessió dels següents elements el que ho fa així:

Microcode ROM és una memòria no volàtil i no regrabable per emmagatzemar microcodi. Es creu que el microcodi és la implementació del sistema d'instruccions del processador en les instruccions més senzilles. També passa al microcodi errors. Així que a la BIOS podeu trobar binaris amb actualitzacions de microcodi (es superposen en el moment de l'arrencada, perquè la ROM no es pot sobreescriure). El contingut d'aquests binaris està xifrat, la qual cosa complica molt l'anàlisi (per tant, el contingut específic del microcodi només és conegut per qui el desenvolupa), i signat per controlar-ne la integritat i l'autenticitat;
Clau AES per desxifrar el contingut de les actualitzacions de microcodi;
un hash de la clau pública RSA que verifica la signatura de les actualitzacions del microcodi;
Hash de clau pública RSA, que verifica la signatura dels mòduls de codi ACM (Authenticated Code Module) desenvolupats per Intel, que la CPU pot executar abans que s'iniciï la BIOS (hola microcodi) o durant el seu funcionament, quan es produeixen alguns esdeveniments.

Intel ME

Aquest subsistema del nostre blog estava dedicat a dos Article. Recordem que aquest entorn executable es basa en el microcontrolador integrat al chipset i és el més amagat i privilegiat del sistema.

Malgrat el sigil, Intel ME també és l'arrel de la confiança, perquè té:

ME ROM: memòria no volàtil i no regrabable (no s'ofereix cap mètode d'actualització), que conté el codi d'inici, així com el hash SHA256 de la clau pública RSA, que verifica la signatura del microprogramari Intel ME;
clau AES per emmagatzemar informació secreta;
accés a un conjunt de fusibles (FPF, Fusibles programables de camp) integrats al chipset per a l'emmagatzematge permanent d'alguna informació, inclosa la informació especificada pel venedor del sistema informàtic.

Intel Boot Guard 1.x

Petita exempció de responsabilitat. Els números de versió de la tecnologia Intel Boot Guard que fem servir en aquest article són arbitraris i poden no tenir res a veure amb la numeració utilitzada a la documentació interna d'Intel. A més, la informació sobre la implementació d'aquesta tecnologia que s'ofereix aquí es va obtenir durant l'enginyeria inversa i pot contenir imprecisions en comparació amb l'especificació per a Intel Boot Guard, que és poc probable que es publiqui mai.

Per tant, Intel Boot Guard (BG) és una tecnologia d'autenticació UEFI BIOS compatible amb maquinari. A jutjar per la seva petita descripció al llibre [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], funciona com una cadena d'arrencada de confiança. I el primer enllaç és el codi d'arrencada (microcodi) dins de la CPU, que s'activa per l'esdeveniment RESET (que no s'ha de confondre amb el vector RESET a la BIOS!). La CPU troba un mòdul de codi (Intel BG startup ACM) desenvolupat i signat per Intel a la memòria flaix SPI, el carrega a la seva memòria cau, el verifica (ja es va assenyalar més amunt que la CPU té un hash de clau pública que verifica la signatura ACM). ) i comença.

Aquest mòdul de codi s'encarrega de verificar una petita part inicial de la UEFI BIOS - Initial Boot Block (IBB), que, al seu torn, conté la funcionalitat per verificar la part principal de la UEFI BIOS. Així, Intel BG us permet verificar l'autenticitat de la BIOS abans d'arrencar el sistema operatiu (que es pot realitzar sota la supervisió de la tecnologia Secure Boot).

La tecnologia Intel BG ofereix dos modes de funcionament (i un no interfereix amb l'altre, és a dir, els dos modes es poden activar al sistema i tots dos es poden desactivar).

Bota mesurada

En el mode d'arrencada mesurada (MB), cada component d'arrencada (començant per la ROM d'arrencada de la CPU) "mesura" el següent utilitzant les capacitats del mòdul de plataforma de confiança (TPM). Per als que no ho sàpiguen, m'ho expliquen.

TPM disposa de PCR (Registres de configuració de plataforma), que registren el resultat de l'operació hash segons la fórmula:

Aquells. el valor de PCR actual depèn de l'anterior, i aquests registres només es reinicien quan el sistema està RESET.

Així, en el mode MB, en algun moment, els PCR reflecteixen un identificador únic (dins de les capacitats de l'operació hash) del codi o de les dades que es van "mesurar". Els valors de PCR es poden utilitzar en l'operació de xifratge d'algunes dades (TPM_Seal). Després d'això, el seu desxifrat (TPM_Unseal) només serà possible si els valors de PCR no han canviat com a resultat de la càrrega (és a dir, no s'ha modificat cap component "mesurat").

Arrencada verificada

El més espantós per als que els agrada modificar la BIOS UEFI és el mode d'arrencada verificada (VB), en què cada component d'arrencada verifica criptogràficament la integritat i l'autenticitat del següent. I en cas d'error de verificació, es produeix (un dels següents):

apagat per temps d'espera d'1 minut a 30 minuts (perquè l'usuari tingui temps d'entendre per què el seu ordinador no arrenca i, si és possible, intentaria restaurar la BIOS);
tancament immediat (perquè l'usuari no tingui temps d'entendre i, a més, de fer);
continuació del treball amb cara recta (el cas en què no hi ha temps per a la seguretat, perquè hi ha coses més importants a fer).

L'elecció de l'acció depèn de la configuració especificada d'Intel BG (és a dir, de l'anomenada política d'aplicació), que el proveïdor de la plataforma informàtica registra permanentment en un emmagatzematge especialment dissenyat: fusibles de chipset (FPF). En aquest punt ens atendrem amb més detall més endavant.

A més de la configuració, el proveïdor genera dues claus RSA 2048 i crea dues estructures de dades (que es mostren a la figura):

El manifest de la clau arrel del proveïdor (KEYM, OEM Root Key Manifest), que posa el SVN (número de versió de seguretat) d'aquest manifest, el hash SHA256 de la clau pública del següent manifest, la clau pública RSA (és a dir, la part pública del manifest). clau arrel del proveïdor) per verificar la signatura d'aquest manifest i la pròpia signatura;
El manifest IBB (IBBM, Initial Boot Block Manifest), que posa el SVN d'aquest manifest, el hash SHA256 de l'IBB, la clau pública per verificar la signatura d'aquest manifest i la signatura mateixa.

El hash SHA256 de la clau arrel OEM s'escriu permanentment als fusibles del chipset (FPF), igual que la configuració d'Intel BG. Si la configuració d'Intel BG preveu la inclusió d'aquesta tecnologia, a partir d'ara aquest sistema només el propietari de la part privada de la clau arrel OEM pot actualitzar la BIOS (és a dir, poder recalcular aquests manifests), és a dir. venedor.

Quan mireu la imatge, immediatament sorgeixen dubtes sobre la necessitat d'una cadena de verificació tan llarga: podríeu haver utilitzat un manifest. Per què complicar-se?

De fet, Intel ofereix així al venedor l'oportunitat d'utilitzar diferents claus IBB per a diferents línies de productes i una com a arrel. Si es filtra la part privada de la clau IBB (que signa el segon manifest), l'incident afectarà només una línia de productes i només fins que el venedor generi un nou parell i habiliti els manifests recalculats a la propera actualització de la BIOS.

Però si la clau arrel està compromesa (amb la qual es signa el primer manifest), no serà possible substituir-la, no es preveu el procediment de revocació. el hash de la part pública d'aquesta clau es programa en FPF d'una vegada per totes.

Configuració d'Intel Boot Guard

Ara mirem més de prop la configuració d'Intel BG i el procés de creació. Si mireu la pestanya corresponent a la GUI de l'eina d'imatge Flash de l'Intel System Tool Kit (STK), notareu que la configuració d'Intel BG inclou un hash de la part pública de la clau arrel del venedor, un parell de claus obscures. valors, etc. Perfil Intel BG.

L'estructura d'aquest 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ó d'Intel BG és una entitat molt flexible. Considereu, per exemple, la bandera Force_Boot_Guard_ACM. Quan s'esborra, si no es troba el mòdul ACM d'inici de BG al flaix SPI, no es produirà cap arrencada de confiança. Serà poc fiable.

Ja hem escrit més amunt que la política d'aplicació per al mode VB es pot configurar de manera que si la verificació falla, de nou, es produirà una descàrrega no fiable.

Deixa coses com aquesta als venedors...

La GUI de la utilitat proporciona els següents perfils "preparats":

Número
Mode
Descripció

0
No_FVME
Tecnologia Intel BG desactivada

1
VE
Mode VB activat, apagat per temps d'espera

2
VME
tots dos modes estan habilitats (VB i MB), apagat per temps d'espera

3
VM
tots dos modes estan habilitats, sense apagar el sistema

4
FVE
Mode VB activat, tancament immediat

5
FVME
ambdós modes activats, tancament immediat

Com ja s'ha esmentat, el venedor del sistema ha d'escriure la configuració d'Intel BG d'una vegada per totes en fusibles de chipset (FPF): un petit emmagatzematge d'informació de maquinari (segons informació no verificada, només 256 bytes) dins del chipset, que es pot programar fora. de les instal·lacions de producció d'Intel (per això Camp programable fusibles).

És ideal per emmagatzemar la configuració perquè:

té una àrea d'emmagatzematge de dades programable una vegada (just on està escrita la configuració d'Intel BG);
només Intel ME el pot llegir i programar.

Per tant, per establir la configuració de la tecnologia Intel BG en un sistema específic, el venedor fa el següent durant la producció:

Mitjançant l'eina d'imatge Flash (d'Intel STK), es crea una imatge de microprogramari amb una configuració determinada d'Intel BG com a variables dins de la regió Intel ME (l'anomenat mirall temporal per als FPF);
Utilitzant l'eina de programació flash (d'Intel STK), escriu aquesta imatge a la memòria flaix SPI del sistema i tanca l'anomenada. mode de fabricació (en aquest cas, l'ordre corresponent s'envia a Intel ME).

Com a resultat d'aquestes operacions, Intel ME comprometrà als FPF els valors especificats del mirall per als FPF a la regió ME, establirà els permisos dels descriptors flash SPI als valors recomanats per Intel (descrits al principi de la article) i realitzeu un RESET del sistema.

Anàlisi d'implementació d'Intel Boot Guard

Per tal d'analitzar la implementació d'aquesta tecnologia en un exemple concret, vam comprovar els sistemes següents per detectar rastres de la tecnologia Intel BG:

Sistema
Nota

Gigabyte GA-H170-D3H
Skylake, hi ha suport

Gigabyte GA-Q170-D3H
Skylake, hi ha suport

Gigabyte GA-B150-HD3
Skylake, hi ha suport

MSI H170A Gaming Pro
Skylake, sense suport

Lenovo Thinkpad 460
Skylake, suport disponible, tecnologia habilitat

Lenovo Yoga 2 Pro
Haswell, sense suport

Lenovo U330p
Haswell, sense suport

"Suport" significa la presència del mòdul ACM d'inici d'Intel BG, els manifests esmentats anteriorment i el codi corresponent a la BIOS, és a dir. implementacions per a l'anàlisi.

Com a exemple, prenem el descarregat des de l'oficina. imatge del lloc del proveïdor de la memòria flash SPI per a Gigabyte GA-H170-D3H (versió F4).

ROM d'arrencada de la CPU Intel

En primer lloc, parlem de les accions del processador si la tecnologia Intel BG està habilitada.

No va ser possible trobar mostres del microcodi desxifrat, per tant, com s'implementen les accions descrites a continuació (en microcodi o en maquinari) és una qüestió oberta. No obstant això, el fet que els processadors Intel moderns "poguin" realitzar aquestes accions és un fet.

Després de sortir de l'estat RESET, el processador (en l'espai d'adreces del qual ja hi ha mapejat el contingut de la memòria flash) troba la FIT (Firmware Interface Table). Trobar-lo és fàcil, el punter a ell s'escriu a l'adreça FFFF FFC0h.

En aquest exemple, aquesta adreça conté el valor FFD6 9500h. Tornant a aquesta adreça, el processador veu la taula FIT, el contingut de la qual es divideix en registres. La primera entrada és l'encapçalament de l'estructura següent:

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

Per algun motiu desconegut, la suma de control no sempre es calcula en aquestes taules (el camp es deixa nul).

Les entrades restants apunten a diversos binaris que s'han d'analitzar / executar abans que s'executi la BIOS, és a dir. abans de canviar al vector RESET heretat (FFFF FFF0h). L'estructura de cada una d'aquestes entrades és la següent:

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 camp EntryType indica el tipus de bloc al qual apunta aquesta entrada. Coneixem de diversos tipus:

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

Ara és obvi que una de les entrades apunta a la ubicació del binari ACM d'inici d'Intel BG. L'estructura de capçalera d'aquest binari és típica dels mòduls de codi desenvolupats per Intel (ACM, actualitzacions de microcodi, seccions de codi 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 processador carrega aquest binari a la seva memòria cau, verifica i llança.

Inici Intel BG ACM

Com a resultat de l'anàlisi del treball d'aquest ACM, va quedar clar que fa el següent:

rep d'Intel ME la configuració Intel BG escrita als fusibles del chipset (FPF);
troba els manifests KEYM i IBBM, els verifica.

Per trobar aquests manifests, ACM també utilitza la taula FIT, que té dos tipus d'entrades per apuntar a aquestes estructures (vegeu FIT_ENTRY_TYPES més amunt).

Mirem més de prop els manifestos. A l'estructura del primer manifest, veiem diverses constants fosques, un hash de la clau pública del segon manifest i una clau arrel OEM pública signada com a estructura imbricada:

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

Per verificar la clau pública de la clau arrel OEM, recordem que s'utilitza el hash SHA256 dels fusibles, que en aquest moment ja s'ha rebut d'Intel ME.

Passem al segon manifest. Consta de tres estructures:

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

El primer conté unes constants:

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 segon conté el hash SHA256 de l'IBB i el nombre de descriptors que descriuen el contingut de l'IBB (és a dir, de què es 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;
};

Els descriptors IBB segueixen aquesta estructura, un darrere l'altre. El seu contingut té el format següent:

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

És senzill: cada descriptor conté l'adreça/mida d'un fragment IBB. Així, la concatenació dels blocs a què apunten aquests descriptors (en l'ordre dels mateixos descriptors) és IBB. I, per regla general, IBB és una combinació de tots els mòduls de les fases SEC i PEI.

El segon manifest acaba amb una estructura que conté la clau pública IBB (verificada pel hash SHA256 del primer manifest) i la signatura d'aquest manifest:

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

Així, fins i tot abans de l'inici de l'execució de la UEFI BIOS, el processador llançarà ACM, que verificarà l'autenticitat del contingut de les seccions amb el codi de fase SEC i PEI. A continuació, el processador surt de l'ACM, es mou al llarg del vector RESET i comença a executar la BIOS.

La partició verificada PEI ha de contenir un mòdul que comprovarà la resta de la BIOS (codi DXE). Aquest mòdul ja està sent desenvolupat per IBV (Independent BIOS Vendor) o el propi proveïdor del sistema. Perquè Només els sistemes Lenovo i Gigabyte van resultar estar a la nostra disposició i tenint suport Intel BG, considerem el codi extret d'aquests sistemes.

Mòdul UEFI BIOS LenovoVerifiedBootPei

En el cas de Lenovo, va resultar ser el mòdul LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, desenvolupat per Lenovo.

La seva feina és buscar (per GUID) una taula hash per al DXE i 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òdul UEFI BIOS BootGuardPei

En el cas de Gigabyte, va resultar ser el mòdul BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, desenvolupat per AMI i, per tant, present en qualsevol BIOS AMI amb suport Intel BG.

El seu algorisme de funcionament és una mica diferent, però es redueix al mateix:

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 taula hash {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} que cerca té el format següent:

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

Parlem breument d'una altra implementació d'Intel Boot Guard, que es va trobar en un sistema més nou basat en Intel SoC amb microarquitectura Apollo Lake: ASRock J4205-IT.

Tot i que aquesta versió només s'utilitzarà en SoC (els nous sistemes amb microarquitectura del processador Kaby Lake continuen utilitzant Intel Boot Guard 1.x), és de gran interès explorar una nova opció d'arquitectura per a plataformes basades en SoC Intel, que s'ha vist tangible. canvis, per exemple:

Les regions BIOS i Intel ME (o més aviat Intel TXE, segons la terminologia Intel SoC) són ara una regió IFWI;
tot i que Intel BG estava habilitat a la plataforma, no es van trobar estructures com FIT, KEYM, IBBM a la memòria flash;
a més dels nuclis TXE i ISH (x86), es va afegir un tercer nucli (de nou ARC, per cert) al conjunt de xips: PMC (controlador de gestió d'energia), associat a garantir l'operativitat del subsistema d'alimentació i la supervisió del rendiment.

El contingut de la nova regió IFWI és un conjunt dels mòduls següents:

Parcialitat
nom
Descripció

0000 2000 h
SMIP
alguna configuració de la plataforma, signada pel venedor

0000 6000 h
RBEP
Secció de codi de microprogramari Intel TXE, x86, signada per Intel

0001 0000 h
PMCP
secció de codi de microprogramari Intel PMC, ARC, signat per Intel

0002 0000 h
FTPR
Secció de codi de microprogramari Intel TXE, x86, signada per Intel

0007B000h
UCOD
Actualitzacions de microcodi de la CPU signades per Intel

0008 0000 h
IBBP
UEFI BIOS, fases SEC/PEI, x86, signat pel proveïdor

0021 8000 h
ISHC
secció de codi del microprogramari Intel ISH, x86, signat pel venedor

0025 8000 h
NFTP
Secció de codi de microprogramari Intel TXE, x86, signada per Intel

0036 1000 h
IUNP
desconegut

0038 1000 h
OBBP
UEFI BIOS, fase DXE, x86, sense signar

Durant l'anàlisi del firmware TXE, es va fer evident que després de RESET, TXE manté el processador en aquest estat fins que prepara el contingut bàsic de l'espai d'adreces per a la CPU (FIT, ACM, vector RESET...). A més, TXE col·loca aquestes dades a la seva SRAM, després d'això proporciona temporalment accés al processador i les "allibera" de RESET.

En guàrdia dels rootkits

Bé, ara passem al "calent". Una vegada vam descobrir que en molts sistemes, els descriptors flash SPI tenen permisos per accedir a regions de la memòria flash SPI perquè tots els usuaris d'aquesta memòria puguin escriure i llegir qualsevol regió. Aquells. de cap manera.

Després de comprovar amb la utilitat MEinfo (d'Intel STK), vam veure que el mode de fabricació d'aquests sistemes no estava tancat, per tant, els fusibles del chipset (FPF) es van deixar en un estat indeterminat. Sí, Intel BG no està ni activat ni desactivat en aquests casos.

Estem parlant dels sistemes següents (respecte a Intel BG i del que es descriu més endavant en l'article, parlarem de sistemes amb microarquitectura de processador Haswell i superior):

tots els productes Gigabyte;
tots els productes MSI;
21 models de portàtils Lenovo i 4 models de servidors Lenovo.

Per descomptat, vam informar de la troballa a aquests venedors, així com a Intel.

La resposta adequada només va seguir de Lenovoqui va reconèixer el problema i va llançar un pedaç.

Gigabyte Sembla que van acceptar informació sobre la vulnerabilitat, però no van comentar de cap manera.

Comunicació amb MSI completament estancat a la nostra sol·licitud d'enviar la nostra clau PGP pública (per tal d'enviar-los un avis de seguretat xifrat). Van afirmar que "són un fabricant de maquinari i no fabriquen claus PGP".

Però més al punt. Com que els fusibles es deixen en un estat indefinit, l'usuari (o atacant) pot programar-los ell mateix (el més difícil és trobar Intel STK). Això requereix els passos següents.

1. Arrenqueu al sistema operatiu Windows (en general, els passos descrits a continuació també es poden fer des de Linux, si desenvolupeu un anàleg d'Intel STK per al sistema operatiu desitjat). Mitjançant la utilitat MEinfo, assegureu-vos que els fusibles d'aquest sistema no estiguin programats.

2. Llegiu el contingut de la memòria flash mitjançant l'eina de programació flash.

3. Obriu la imatge de lectura mitjançant qualsevol eina d'edició de BIOS UEFI, feu els canvis necessaris (implementeu un rootkit, per exemple), creeu/editeu les estructures KEYM i IBBM existents a la regió ME.

La part pública de la clau RSA es destaca a la imatge, el hash de la qual es programarà als fusibles del chipset juntament amb la resta de la configuració d'Intel BG.

4. Amb l'eina d'imatge Flash, creeu una nova imatge de microprogramari (definint la configuració d'Intel BG).

5. Escriviu una imatge nova per flashejar amb l'eina de programació Flash, comproveu amb MEinfo que la regió ME ara conté la configuració d'Intel BG.

6. Utilitzeu l'eina de programació Flash per tancar el mode de fabricació.

7. El sistema es reiniciarà, després de la qual cosa, mitjançant MEinfo, podeu verificar que els FPF ja estan programats.

Aquestes accions per sempre habiliteu Intel BG en aquest sistema. Serà impossible desfer l'acció, el que significa:

només el propietari de la part privada de la clau arrel (és a dir, el que va habilitar Intel BG) podrà actualitzar la BIOS UEFI en aquest sistema;
si torneu el microprogramari original a aquest sistema, per exemple, amb un programador, ni tan sols s'activarà (una conseqüència de la política d'aplicació en cas d'error de verificació);
per desfer-se d'aquesta BIOS UEFI, heu de substituir el chipset amb FPF programats per un de "net" (és a dir, torneu el chipset si teniu accés a una estació de soldadura d'infrarojos al preu d'un cotxe, o simplement substituïu la placa base). ).

Per entendre què pot fer aquest rootkit, heu d'avaluar què fa possible executar el vostre codi en un entorn UEFI BIOS. Per exemple, en el mode més privilegiat del processador: SMM. Aquest rootkit pot tenir les propietats següents:

s'executarà en paral·lel amb el sistema operatiu (podeu configurar el processament generant una interrupció SMI, que serà activada per un temporitzador);
tenen tots els avantatges d'estar en mode SMM (accés complet als continguts de RAM i recursos de maquinari, secret des del sistema operatiu);
El codi rootkit es pot xifrar i desxifrar quan s'inicia en mode SMM. Qualsevol dada disponible només en mode SMM es pot utilitzar com a clau de xifratge. Per exemple, un hash d'un conjunt d'adreces a SMRAM. Per obtenir aquesta clau, haureu d'enfilar-vos a l'SMM. I això es pot fer de dues maneres. Trobeu el RCE al codi SMM i explota'l, o afegiu el vostre propi mòdul SMM a la BIOS, cosa que és impossible, ja que hem habilitat Boot Guard.

Per tant, aquesta vulnerabilitat permet a un atacant:

crear un rootkit ocult i inamovible de propòsit desconegut al sistema;
executeu el vostre codi en un dels nuclis del chipset dins de l'Intel SoC, és a dir, a l'Intel ISH (fegeu un cop d'ull a la imatge).

Tot i que encara no s'han explorat les capacitats del subsistema Intel ISH, sembla ser un vector d'atac interessant contra Intel ME.

Troballes

L'estudi va proporcionar una descripció tècnica de com funciona la tecnologia Intel Boot Guard. Menys un parell de secrets en la seguretat d'Intel mitjançant el model d'obscuritat.
Es presenta un escenari d'atac que permet crear un rootkit no extraïble al sistema.
Hem vist que els processadors Intel moderns són capaços d'executar molt codi propietari fins i tot abans que s'iniciï la BIOS.
Les plataformes amb arquitectura Intel 64 són cada cop menys adequades per executar programari lliure: verificació de maquinari, un nombre creixent de tecnologies i subsistemes propietaris (tres nuclis en el chipset SoC: x86 ME, x86 ISH i ARC PMC).

Mitigacions

Els venedors que deixen intencionadament el mode de fabricació obert haurien de tancar-lo definitivament. Fins ara, només tanquen els ulls i els nous sistemes Kaby Lake ho demostren.

Els usuaris poden desactivar Intel BG als seus sistemes (que es veuen afectats per la vulnerabilitat descrita) executant l'eina de programació Flash amb l'opció -closemnf. En primer lloc, hauríeu d'assegurar-vos (utilitzant MEinfo) que la configuració d'Intel BG a la regió ME proporciona exactament desactivar aquesta tecnologia després de programar-la en FPF.

Font: www.habr.com

La bota de confiança de Schrödinger. Intel Boot Guard