Trusted Launch di Schrödinger. Intel Boot Guard

Propongo di scendere nuovamente a un livello inferiore e parlare della sicurezza dei firmware delle piattaforme informatiche compatibili x86. Questa volta, l'ingrediente principale della ricerca è Intel Boot Guard (non confondere con Intel BIOS Guard!) – una tecnologia di avvio fidata supportata da hardware, che il fornitore del sistema informatico può attivare o disattivare in modo permanente durante la produzione. E il nostro metodo di ricerca ci è già familiare: analizzare finemente l'implementazione di questa tecnologia tramite reverse engineering, descriverne l'architettura, arricchendola con dettagli non documentati, condirla a piacere con vettori di attacco e mescolare il tutto. Aggiungiamo pepe raccontando come un errore di produzione clone su più fornitori consenta a un potenziale malintenzionato di utilizzare questa tecnologia per creare nel sistema un rootkit nascosto non rimovibile (neppure da un programmatore).

A proposito, la base dell'articolo è costituita dalle relazioni "Alla guardia dei rootkit: Intel BootGuard" della conferenza ZeroNights 2016 e 29-esima riunione DefCon Russia (entrambe le presentazioni qui).

Firmware della piattaforma informatica con architettura Intel 64

Per iniziare, rispondiamo alla domanda: cos'è un firmware di una moderna piattaforma informatica con architettura Intel 64? Ovviamente, UEFI BIOS. Ma tale risposta non sarebbe precisa. Diamo un'occhiata all'immagine che mostra il modello desktop (notebook) di questa architettura.

La base è costituita da un insieme:

• Del processore (CPU, Central Processing Unit), nel quale, oltre ai core principali, è integrato un'unità grafica (non in tutti i modelli) e un controller di memoria (IMC, Integrated Memory Controller);
• Del chipset (PCH, Platform Controller Hub), che contiene vari controller per l'interazione con dispositivi periferici e per la gestione delle sottosistemi. Tra di essi c'è il notissimo Intel Management Engine (ME), che ha anche il suo firmware (firmware Intel ME).

I notebook, oltre a quanto sopra, prevedono la presenza di un controller integrato (ACPI EC, Advanced Control and Power Interface Embedded Controller), che è responsabile del funzionamento della sottosistema di alimentazione, del touchpad, della tastiera, dei tasti Fn (luminosità dello schermo, volume audio, retroilluminazione della tastiera, ecc.) e altro. Anche questo ha il suo firmware.

Quindi, la combinazione dei firmware sopra elencati è il firmware della piattaforma informatica (system firmware), che è memorizzato nella memoria flash SPI comune. Per evitare che gli utenti di questa memoria si confondano su dove si trovi ciascuno, il contenuto di questa memoria è suddiviso in diverse aree (come mostrato nell'immagine):

• UEFI BIOS;
• firmware ACPI EC (un'area separata è comparsa con l'architettura microprocessore Skylake (2015), ma finora non abbiamo visto esempi del suo utilizzo, quindi il firmware del controller integrato fa ancora parte dell'UEFI BIOS);
• firmware Intel ME;
• configurazione (indirizzo MAC, ecc.) dell'adattatore di rete GbE (Gigabit Ethernet) integrato;
• descrittori flash (Flash Descriptors) – la principale area della memoria flash che contiene puntatori ad altre aree, oltre alle autorizzazioni per accedervi.

La gestione dell'accesso alle aree (in conformità con le autorizzazioni stabilite) è effettuata dal master del bus SPI – un controller SPI integrato nel chipset, tramite il quale avviene l'accesso a questa memoria. Se le autorizzazioni sono impostate sui valori raccomandati (per motivi di sicurezza) da Intel, ogni utente della memoria flash SPI ha accesso completo (lettura/scrittura) solo alla propria area. Le altre aree sono accessibili solo in lettura oppure non sono accessibili affatto. È un fatto noto: su molti sistemi, la CPU ha accesso completo all'UEFI BIOS e a GbE, accesso in lettura solo ai descrittori flash, mentre l'area Intel ME non è accessibile affatto. Perché su molti, e non su tutti? Ciò che è raccomandato non è obbligatorio. Ne parleremo più dettagliatamente nel prossimo articolo.

Meccanismi di protezione del firmware della piattaforma informatica da modifiche

È evidente che il firmware della piattaforma informatica deve essere protetto da possibili compromissioni che consentirebbero a un potenziale attaccante di stabilirsi in esso (sopravvivere agli aggiornamenti/reinstallazioni del sistema operativo), eseguire il proprio codice nei regimi più privilegiati, ecc. E la gestione dell'accesso alle aree della memoria flash SPI, ovviamente, non è sufficiente. Pertanto, per proteggere il firmware dalle modifiche vengono utilizzati vari meccanismi, specifici per ogni ambiente di esecuzione.

Così, il firmware Intel ME è firmato per controllare l'integrità e l'autenticità ed è verificato dal controller ME ad ogni caricamento nella memoria ME UMA. Questo processo di verifica è già stato esaminato in uno dei articoli, dedicata al sottosistema Intel ME.

Il firmware ACPI EC, di solito, viene controllato solo per l'integrità. Tuttavia, poiché questo binario è incluso nel firmware UEFI BIOS, gli stessi meccanismi di protezione utilizzati dall'UEFI BIOS si applicano quasi sempre a questo. Di questi parleremo.

Questi meccanismi possono essere suddivisi in due categorie.

Protezione dalla scrittura nella regione dell'UEFI BIOS

1. Protezione fisica del contenuto della memoria flash SPI con un jumper di write-protect;
2. Protezione della proiezione della regione dell'UEFI BIOS nello spazio di indirizzamento della CPU tramite i registri PRx del chipset;
3. Blocco dei tentativi di scrittura nella regione dell'UEFI BIOS generando e gestendo l'interruzione SMI corrispondente mediante l'impostazione dei bit BIOS_WE/BLE e SMM_BWP nei registri del chipset;
4. Una variante più avanzata di tale protezione è Intel BIOS Guard (PFAT).

In aggiunta a questi meccanismi, i venditori possono sviluppare e implementare proprie misure di sicurezza (ad esempio, firmare i pacchetti di aggiornamento dell'UEFI BIOS).

È importante notare che non tutti i meccanismi di protezione sopra elencati possono essere applicati su un sistema specifico (dipende dal fornitore), potrebbero non essere applicati affatto o implementati in modo vulnerabile. Maggiori dettagli su questi meccanismi e sulla situazione della loro implementazione possono essere letti in questo articolo. Consigliamo a chi è interessato di approfondire l'intero ciclo di articoli sulla sicurezza dell'UEFI BIOS di CodeRush.

Verifica dell'autenticità dell'UEFI BIOS

Quando parliamo di tecnologie di avvio sicuro, la prima cosa che viene in mente è Secure Boot. Tuttavia, architettonicamente è progettato per verificare l'autenticità dei componenti esterni, rispetto all'UEFI BIOS, (driver, bootloader, ecc.), e non del firmware stesso.

Pertanto, nel 2012, Intel ha implementato la funzionalità di Secure Boot hardware non disattivabile (Verified Boot) nelle SoC con microarchitettura Bay Trail, che non ha nulla a che fare con la suddetta tecnologia Secure Boot. In seguito (2013) questo meccanismo è stato migliorato e rilasciato come Intel Boot Guard per desktop con microarchitettura Haswell.

Prima di descrivere Intel Boot Guard, esaminiamo gli ambienti di esecuzione nell'architettura Intel 64, che sono anche le radici di fiducia per questa tecnologia di avvio sicuro.

Intel CPU

Cap suggerisce che il processore è l'ambiente di esecuzione principale nell'architettura Intel 64. Perché è considerato la radice di fiducia? Si scopre che lo è grazie alla possesso dei seguenti elementi:

• Microcode ROM — memoria non volatile e non riscrivibile per la memorizzazione del microcodice. Si considera che il microcodice sia l'implementazione del set di istruzioni del processore su istruzioni di base. Anche nel microcodice possono verificarsi bug. Quindi nel BIOS è possibile trovare i binari con gli aggiornamenti del microcodice (applicati durante il caricamento, poiché la ROM non può essere riscritta). Il contenuto di questi binari è crittografato, il che complica notevolmente l'analisi (pertanto, il contenuto specifico del microcodice è noto solo a chi lo sviluppa), e firmato per il controllo dell'integrità e dell'autenticità;
• Chiave AES per decrittografare il contenuto degli aggiornamenti del microcodice;
• hash della chiave pubblica RSA, utilizzata per verificare la firma degli aggiornamenti del microcodice;
• hash della chiave pubblica RSA, utilizzata per verificare la firma dei moduli di codice autentico ACM (Authenticated Code Module) sviluppati da Intel, che la CPU può eseguire prima dell'esecuzione del BIOS (saluti al microcodice) o durante il suo funzionamento, in caso di alcuni eventi.

Intel ME

A questa sottosistema è stata dedicata persino due sul CommunityHelpWiki (sullo stesso dominio. Ricordiamo che questo ambiente eseguibile è basato su un microcontrollore integrato nel chipset e rappresenta la parte più nascosta e privilegiata del sistema.

Nonostante la sua riservatezza, Intel ME è anche una radice di fiducia, in quanto possiede:

• ME ROM — memoria non volatile e non riscrivibile (non è prevista alcuna modalità di aggiornamento), contenente il codice di avvio, nonché l'hash SHA256 della chiave pubblica RSA, utilizzata per verificare la firma del firmware Intel ME;
• Chiave AES per la memorizzazione di informazioni riservate;
• accesso a un insieme di fusibili programmabili sul campo (FPFs, Field Programmable Fuses) integrato nel chipset per la memorizzazione permanente di alcune informazioni, inclusi quelle fornite dal fornitore del sistema informatico.

Intel Boot Guard 1.x

Una piccola dichiarazione di non responsabilità. I numeri di versione della tecnologia Intel Boot Guard di cui parliamo in questo articolo sono convenzionali e potrebbero non avere nulla a che fare con la numerazione utilizzata nella documentazione interna di Intel. Inoltre, le informazioni qui presentate sull'implementazione di questa tecnologia sono state ottenute attraverso il reverse engineering e possono contenere imprecisioni rispetto alle specifiche di Intel Boot Guard, che probabilmente non saranno mai pubblicate.

Intel Boot Guard (BG) è una tecnologia di verifica dell'autenticità UEFI BIOS supportata hardware. A giudicare dalla sua breve descrizione nel libro [Platform Embedded Security Technology Revealed, capitolo Boot with Integrity, or Not Boot], funziona come una catena di avvio sicura. Il primo anello di questa catena è il codice di avvio (microcodice) all'interno della CPU, che viene eseguito in seguito a un evento RESET (non confondere con il vettore RESET nel BIOS!). La CPU trova nel flash SPI un modulo di codice progettato e firmato da Intel (Intel BG startup ACM), lo carica nella propria cache, lo verifica (come già accennato, la CPU possiede un hash della chiave pubblica con cui viene controllata la firma ACM) e lo avvia.

Questo modulo di codice è responsabile della verifica di una piccola parte iniziale dell'UEFI BIOS—l'Initial Boot Block (IBB)—che a sua volta contiene funzionalità per la verifica della parte principale dell'UEFI BIOS. In questo modo, Intel BG consente di garantire l'autenticità del BIOS prima dell'avvio del sistema operativo (che può essere eseguito sotto la supervisione della tecnologia Secure Boot).

La tecnologia Intel BG prevede due modalità operative (in cui l'una non interferisce con l'altra, cioè entrambe le modalità possono essere attive nel sistema, oppure entrambe possono essere disattivate).

Measured Boot

Nella modalità Measured Boot (MB), ogni componente di avvio (a partire dal CPU boot ROM) "misura" il successivo, utilizzando le capacità del TPM (Trusted Platform Module). Per coloro che non sono al corrente, facciamo una spiegazione.

Il TPM ha i PCR (Platform Configuration Registers), in cui viene registrato il risultato dell'operazione di hashing secondo la seguente formula:

Cioè, il valore attuale dei PCR dipende dal precedente, con la differenza che questi registri vengono azzerati solo al RESET del sistema.

In questo modo, in modalità MB, in un certo momento i PCR riflettono un identificatore unico (nelle possibilità dell'operazione di hashing) del codice o dei dati che sono stati "misurati". I valori dei PCR possono essere utilizzati nell'operazione di crittografia di alcuni dati (TPM_Seal). Successivamente, la loro decrittazione (TPM_Unseal) sarà possibile solo se i valori dei PCR non sono cambiati dopo il caricamento (cioè nessun componente "misurato" è stato modificato).

Verified Boot

La cosa più temuta per coloro che amano modificare l'UEFI BIOS è la modalità Verified Boot (VB), in cui ogni componente di avvio verifica cripto-graficamente l'integrità e l'autenticità del successivo. In caso di errore di verifica, si verifica (una delle seguenti):

• disattivazione per timeout da 1 minuto a 30 minuti (per consentire all'utente di capire perché il computer non si avvia e, se possibile, tentare di ripristinare il BIOS);
• spegnimento immediato (affinché l'utente non possa capire nulla e, tanto meno, fare qualcosa);
• continuare a lavorare con un atteggiamento imperturbabile (quella situazione in cui non ci si può preoccupare della sicurezza, perché ci sono questioni più importanti).

La scelta dell'azione dipende dalla configurazione prevista di Intel BG (ovvero dalla cosiddetta enforcement policy), che viene permanentemente registrata dal fornitore della piattaforma computeristica in uno specifico deposito - i fusi del chipset (FPF). Esamineremo questo punto più dettamente in seguito.

Oltre alla configurazione, il fornitore genera due chiavi RSA 2048 e crea due strutture dati (illustrate nell'immagine):

1. Il manifesto della chiave radice del fornitore (KEYM, OEM Root Key Manifest), in cui inserisce l'SVN (Security Version Number) di questo manifesto, l'hash SHA256 della chiave pubblica del manifesto successivo, la chiave pubblica RSA (cioè la parte pubblica della chiave radice del fornitore) per la verifica della firma di questo manifesto e la firma stessa;
2. Il manifesto IBB (IBBM, Initial Boot Block Manifest), in cui inserisce l'SVN di questo manifesto, l'hash SHA256 di IBB, la chiave pubblica per verificare la firma di questo manifesto e la firma stessa.

L'hash SHA256 della chiave pubblica OEM Root Key è registrato permanentemente nei fusi del chipset (FPF), così come la configurazione di Intel BG. Se la configurazione di Intel BG prevede l'attivazione di questa tecnologia, da quel momento in poi su questo sistema aggiornare il BIOS (cioè avere la possibilità di ricalcolare questi manifesti) può farlo solo il detentore della parte privata della OEM Root Key, cioè il fornitore.

Dando un'occhiata all'immagine sorgono immediatamente dei dubbi sulla necessità di una catena di verifica così lunga - si sarebbe potuto utilizzare un solo manifesto. Perché complicare le cose?

In realtà, la società Intel offre al fornitore la possibilità di utilizzare diverse chiavi IBB per diverse linee di prodotti e una come chiave radice. Se la parte privata della chiave IBB (che firma il secondo manifesto) dovesse essere compromessa, l'incidente riguarderebbe solo una linea di prodotti e solo fino a quando il fornitore non genera una nuova coppia e non integra i manifesti ricalcolati nel successivo aggiornamento del BIOS.

Ma se la chiave radice (quella utilizzata per firmare il primo manifesto) viene compromessa, non sarà possibile sostituirla, poiché non è prevista alcuna procedura di revoca, dato che l'hash della parte pubblica di questa chiave è programmato negli FPF una sola volta e per sempre.

Configurazione di Intel Boot Guard

Ora ci soffermeremo in dettaglio sulla configurazione di Intel BG e sul processo di creazione. Se si osserva la scheda corrispondente nell'interfaccia GUI dell'utensile Flash Image Tool del kit Intel System Tool Kit (STK), si può notare che la configurazione di Intel BG include l'hash della parte pubblica della chiave radice del fornitore, un paio di valori poco chiari e il cosiddetto profilo Intel BG.

Struttura di questo profilo:

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 – non fare nulla
                                             // 01b – spegnimento con timeout
                                             // 11b – spegnimento immediato
	unsigned long : 26;
};

In generale, la configurazione di Intel BG è un'entità molto flessibile. Prendiamo ad esempio il flag Force_Boot_Guard_ACM. Quando è disattivato, se il modulo BG startup ACM nella memoria flash SPI non viene trovato, non ci sarà alcun avvio fidato. Sarà non fidato.

Abbiamo già scritto che la policy di enforcement per la modalità VB può essere impostata in modo tale che in caso di errore di verifica si verifichi, ancora una volta, un avvio non fidato.

Lasciare tali cose alla discrezione dei fornitori...

L'interfaccia GUI dell'utensile prevede i seguenti profili "pronti":

Numero
Modalità
Descrizione

0
No_FVME
la tecnologia Intel BG è disattivata

1
VE
modalità VB attivata, spegnimento dopo timeout

2
VME
entrambi i moduli attivati (VB e MB), spegnimento dopo timeout

3
VM
entrambi i moduli attivati, senza spegnimento del sistema

4
FVE
modalità VB attivata, spegnimento immediato

5
FVME
entrambi i moduli attivati, spegnimento immediato

Come già detto, la configurazione di Intel BG deve essere una volta per tutte registrata dal fornitore del sistema nei fusibili del chipset (FPF) – una piccola (stando a informazioni non verificate, solo 256 byte) memoria hardware di stoccaggio all'interno del chipset, che può essere programmata al di fuori delle capacità produttive della Intel (quindi, proprio Field Programmable Fuses).

È ideale per memorizzare la configurazione, poiché:

• ha un'area one-time-programmable per la memorizzazione dei dati (è proprio lì che viene registrata la configurazione di Intel BG);
• può essere letta e programmata solo da Intel ME.

Quindi, per configurare la tecnologia Intel BG su un sistema specifico, il fornitore durante la produzione esegue le seguenti operazioni:

1. Utilizzando lo strumento Flash Image Tool (dall'Intel STK), crea un'immagine del firmware con una configurazione Intel BG definita sotto forma di variabili all'interno della regione Intel ME (il cosiddetto specchio temporaneo per gli FPF);
2. Utilizzando lo strumento Flash Programming Tool (dall'Intel STK), scrive questa immagine nella memoria flash SPI del sistema e chiude il cosiddetto manufacturing mode (nel processo, viene inviata la relativa comando a Intel ME).

A seguito di queste operazioni, Intel ME impegnerà nei FPF i valori definiti dallo specchio per gli FPF nella regione ME, imposterà i permessi nei descrittori flash SPI ai valori consigliati dalla Intel (come descritto all'inizio dell'articolo) ed eseguirà un RESET del sistema.

Analisi dell'implementazione di Intel Boot Guard

Per analizzare l'implementazione di questa tecnologia con un esempio specifico, abbiamo verificato i seguenti sistemi per la presenza di tracce della tecnologia Intel BG:

Sistema
Nota

Gigabyte GA-H170-D3H
Skylake, supporto disponibile

Gigabyte GA-Q170-D3H
Skylake, supporto disponibile

Gigabyte GA-B150-HD3
Skylake, supporto disponibile

MSI H170A Gaming Pro
Skylake, supporto non disponibile

Lenovo ThinkPad 460
Skylake, supporto disponibile, tecnologia attivata

Lenovo Yoga 2 Pro
Haswell, supporto non disponibile

Lenovo U330p
Haswell, supporto non disponibile

Per 'supporto' si intende la presenza di un modulo ACM di avvio Intel BG, dei manifesti sopra menzionati e del relativo codice nel BIOS, ovvero l'implementazione per l'analisi.

Come esempio, prendiamo l'immagine della memoria flash SPI scaricata dal sito ufficiale del fornitore per Gigabyte GA-H170-D3H (versione F4).

ROM di avvio del CPU Intel

Per prima cosa, discuteremo delle azioni del processore se la tecnologia Intel BG è attivata.

Non è stato possibile reperire esempi di microcodice decrittato, quindi il modo in cui le azioni descritte di seguito siano implementate (nel microcodice o in modo hardware) rimane una questione aperta. Tuttavia, è un dato di fatto che i moderni processori Intel sono in grado di eseguire queste azioni.

Dopo l'uscita dallo stato di RESET, il processore (la cui memoria flash è già mappata nello spazio degli indirizzi) trova la tabella FIT (Firmware Interface Table). È facile trovarla, il puntatore a essa è registrato all'indirizzo FFFF FFC0h.

Nell'esempio considerato, a questo indirizzo si trova il valore FFD6 9500h. Accedendo a questo indirizzo, il processore vede la tabella FIT, il cui contenuto è suddiviso in record. Il primo record è l'intestazione della seguente struttura:

typedef struct FIT_HEADER
{
	char           Tag[8];     // '_FIT_'
	unsigned long  NumEntries; // inclusa l'entrata dell'intestazione FIT
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

Per motivi sconosciuti, il checksum non è sempre calcolato in queste tabelle (il campo è lasciato a zero).

Le altre registrazioni indicano diversi binari che devono essere analizzati/eseguiti prima dell'esecuzione del BIOS, ovvero prima di passare al vettore RESET legacy (FFFF FFF0h). La struttura di ciascuna di queste registrazioni è la seguente:

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

Il campo EntryType indica il tipo di blocco a cui questa registrazione fa riferimento. Conosciamo diversi tipi:

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

Ora è evidente che una delle registrazioni indica la posizione del binario Intel BG startup ACM. La struttura dell'intestazione di questo binario è tipica dei moduli di codice sviluppati dalla società Intel (ACM, aggiornamenti del microcodice, sezioni di codice Intel ME, …).

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

Il processore carica questo binario nella memoria cache, lo verifica e lo avvia.

Intel BG startup ACM

Dall'analisi del funzionamento di questo ACM è emerso che compie le seguenti operazioni:

• ottiene da Intel ME la configurazione Intel BG, registrata nei fuse del chipset (FPF);
• trova i manifesti KEYM e IBBM, li verifica.

Per trovare questi manifesti, ACM utilizza anche la tabella FIT, in cui sono riservati due tipi di registrazioni per indicare i dati delle strutture (vedi FIT_ENTRY_TYPES sopra).

Fermiamoci un attimo sui manifesti. Nella struttura del primo manifesto vediamo diverse costanti poco chiare, l'hash della chiave pubblica dal secondo manifesto e la chiave pubblica OEM Root Key con la firma sotto forma di struttura annidata:

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 == dimensione hash?
	unsigned char  IbbmKeyHash[32]; // SHA256 di una chiave pubblica IBBM
	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 la verifica della chiave pubblica OEM Root Key, ricordiamo, si utilizza l'hash SHA256 ottenuto dai fusi, che è già stato ricevuto da Intel ME.

Passiamo al secondo manifesto. Esso è composto da tre strutture:

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Politiche di avvio
	IBBS Ibbs;         // Descrizione IBB
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // Firma IBBM
};

Nella prima – alcune costanti:

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

Nella seconda si trova l'hash SHA256 dell'IBB e il numero di descrittori che descrivono il contenuto dell'IBB (cioè cosa viene utilizzato per calcolare l'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 == dimensione hash ?
	unsigned char  IbbHash[32];       // SHA256 di un IBB
	unsigned char  NumIbbDescriptors;
};

I descrittori IBB seguono questa struttura, uno dopo l'altro. Il loro contenuto ha il seguente formato:

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

È semplice: ogni descrittore contiene indirizzo/dimensione di un pezzo di IBB. Pertanto, la concatenazione dei blocchi a cui puntano questi descrittori (nell'ordine in cui si trovano i descrittori stessi) forma l'IBB. E, di solito, l'IBB è un insieme di tutti i moduli delle fasi SEC e PEI.

Il secondo manifesto termina con una struttura che contiene la chiave pubblica IBB (verificata dall'hash SHA256 del primo manifesto) e la firma di questo manifesto:

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

Quindi, ancora prima dell'avvio dell'esecuzione del BIOS UEFI, il processore avvierà l'ACM, che verificherà l'autenticità del contenuto delle sezioni di codice delle fasi SEC e PEI. Successivamente, il processore uscirà dall'ACM, passerà al vettore RESET e inizierà a eseguire il BIOS.

La sezione PEI verificata deve contenere un modulo che verifichi il resto del BIOS (codice DXE). Questo modulo è sviluppato da un IBV (Independent BIOS Vendor) o dal fornitore del sistema stesso. Poiché i sistemi a nostra disposizione con supporto Intel BG sono solo Lenovo e Gigabyte, considereremo il codice estratto precisamente da questi sistemi.

Modulo UEFI BIOS LenovoVerifiedBootPei

Nel caso di Lenovo, questo è stato il modulo LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, sviluppato dall'azienda Lenovo.

Il suo compito consiste nel cercare (tramite GUID) la tabella hash per il DXE e nella verifica del DXE.

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

La tabella hash {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} ha il seguente formato:

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

Modulo UEFI BIOS BootGuardPei

Nel caso di Gigabyte, questo è stato il modulo BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, sviluppato dall'azienda AMI, e quindi presente in qualsiasi BIOS AMI con supporto Intel BG.

Il suo algoritmo di funzionamento è leggermente diverso, ma si riduce comunque a quanto segue:

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 tabella hash {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} che cerca ha il seguente 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

Parliamo brevemente di un'altra implementazione di Intel Boot Guard, che è stata trovata in un sistema più recente basato su Intel SoC con microarchitettura Apollo Lake - ASRock J4205-IT.

Sebbene questa versione sarà utilizzata solo negli SoC (i nuovi sistemi con architettura di processore Kaby Lake continuano a utilizzare Intel Boot Guard 1.x), rappresenta un grande interesse nello studio di una nuova variante di architettura per le piattaforme su Intel SoC, in cui sono avvenuti cambiamenti significativi, ad esempio:

• le regioni BIOS e Intel ME (meglio nota come Intel TXE, secondo la terminologia per Intel SoC) ora sono vere e proprie regioni IFWI;
• anche se sulla piattaforma era attivato Intel BG, strutture come FIT, KEYM, IBBM non sono state trovate nella memoria flash;
• oltre ai core TXE e ISH (x86), nel chipset è stato aggiunto un terzo core (di nuovo ARC, tra l'altro) – PMC (Power Management Controller), responsabile dell'assicurazione della funzionalità del sistema di alimentazione e del monitoraggio delle prestazioni.

Il contenuto della nuova regione IFWI è costituito da un insieme dei seguenti moduli:

Offset
Nome
Descrizione

0000 2000h
SMIP
una certa configurazione della piattaforma, firmata dal fornitore

0000 6000h
RBEP
sezione di codice del firmware Intel TXE, x86, firmata Intel

0001 0000h
PMCP
sezione di codice del firmware Intel PMC, ARC, firmata Intel

0002 0000h
FTPR
sezione di codice del firmware Intel TXE, x86, firmata Intel

0007 B000h
UCOD
aggiornamenti del microcodice per CPU, firmati Intel

0008 0000h
IBBP
UEFI BIOS, fasi SEC/PEI, x86, firmata dal fornitore

0021 8000h
ISHC
sezione di codice del firmware Intel ISH, x86, firmata dal fornitore

0025 8000h
NFTP
sezione di codice del firmware Intel TXE, x86, firmata Intel

0036 1000h
IUNP
sconosciuto

0038 1000h
OBBP
UEFI BIOS, fase DXE, x86, non firmata

Durante l'analisi del firmware TXE è diventato chiaro che dopo il RESET, TXE mantiene il processore in questo stato fino a quando non prepara il contenuto di base dello spazio indirizzabile per la CPU (FIT, ACM, vettore di RESET ...). TXE colloca questi dati nella sua SRAM, dopodiché fornisce temporaneamente al processore l'accesso a questi dati e lo 'libera' dal RESET.

In guardia contro i rootkit

Ora passiamo al 'caldo'. Una volta abbiamo scoperto che in molti sistemi nei descrittori SPI flash erano scritti diritti di accesso alle aree della memoria flash SPI in modo tale che tutti gli utenti di questa memoria possono sia scrivere che leggere qualsiasi area. Cioè, in nessun modo.

Dopo aver verificato utilizzando l'utility MEinfo (dalla Intel STK), abbiamo visto che la modalità manufacturing non era chiusa su questi sistemi, di conseguenza, i fusibili del chipset (FPF) erano lasciati in stato indeterminato. Sì, Intel BG in tali casi non è né attivato né disattivato.

Si tratta dei seguenti sistemi (per quanto riguarda Intel BG e ciò che verrà esposto successivamente nell'articolo, parleremo di sistemi con architettura microprocessore Haswell e oltre):

• tutti i prodotti Gigabyte;
• tutti i prodotti MSI;
• 21 modelli di laptop Lenovo e 4 modelli di server Lenovo.

Naturalmente, abbiamo segnalato questa scoperta a questi fornitori, così come alla società Intel.

Una reazione adeguata è seguita solo da Lenovo, che hanno riconosciuto il problema e hanno rilasciato una patch.

Gigabyte anche se hanno preso atto delle informazioni sulla vulnerabilità, non hanno fornito alcun commento.

Conversazione con MSI si è completamente fermato alla nostra richiesta di inviare la propria chiave PGP aperta (per inviare loro un advisory di sicurezza in forma crittografata). Hanno dichiarato di essere "produttori di hardware e non producono chiavi PGP".

Ma veniamo al sodo. Poiché i fusibili sono lasciati in uno stato indefinito, l'utente (o un malintenzionato) può programmarli autonomamente (la parte più complessa è trovare Intel STK). Per fare ciò è necessario eseguire le seguenti operazioni.

1. Avviare il sistema operativo Windows (infatti, le operazioni descritte di seguito possono essere effettuate anche da Linux, se si sviluppa un'analoga Intel STK per il sistema operativo desiderato). Utilizzando l'utilità MEinfo, assicurarsi che i fusibili su questo sistema non siano programmati.

2. Leggere il contenuto della memoria flash utilizzando il Flash Programming Tool.

3. Aprire l'immagine letta con qualsiasi strumento per la modifica del BIOS UEFI, apportare le modifiche necessarie (ad esempio, inserire un rootkit), creare/modificare le strutture KEYM e IBBM esistenti nella regione ME.

Nell'immagine è evidenziata la parte pubblica della chiave RSA, il cui hash sarà programmato nei fusibili del chipset insieme al resto della configurazione Intel BG.

4. Utilizzando il Flash Image Tool, creare una nuova immagine del firmware (impostando la configurazione Intel BG).

5. Scrivere la nuova immagine sulla memoria flash utilizzando il Flash Programming Tool, assicurandosi tramite MEinfo che la regione ME ora contenga la configurazione Intel BG.

6. Utilizzando il Flash Programming Tool, chiudere la modalità manufacturing mode.

7. Il sistema si riavvierà, dopo di che è possibile verificare con MEinfo che i FPF ora sono programmati.

Queste operazioni attiveranno definitivamente Intel BG su questo sistema. Non sarà possibile annullare questa azione, il che significa:

• l'aggiornamento del BIOS UEFI su questo sistema potrà essere effettuato solo dal possessore della parte privata della chiave radice (cioè colui che ha attivato Intel BG);
• se si ripristina a questo sistema il firmware originale, ad esempio utilizzando un programmatore, non si accenderà nemmeno (conseguenza della enforcement policy in caso di errore di verifica);
• per liberarsi di un tale BIOS UEFI, è necessario sostituire il chipset con FPF programmati con uno "pulito" (cioè risaldare il chipset, se si ha accesso a una stazione di saldatura a infrarossi dal costo di un'auto, oppure semplicemente sostituire la scheda madre).

Per comprendere cosa può combinare un tale rootkit, è necessario valutare cosa consenta di eseguire il proprio codice nell'ambiente UEFI BIOS. Ad esempio, nella modalità più privilegiata del processore – SMM. Un tale rootkit può avere le seguenti caratteristiche:

• eseguirsi parallelamente al sistema operativo (è possibile configurarne l'esecuzione tramite la generazione di un'interruzione SMI, che verrà attivata tramite un timer);
• avere tutti i vantaggi di trovarsi in modalità SMM (accesso completo al contenuto della memoria volatile e alle risorse hardware, invisibilità rispetto al sistema operativo);
• il codice del rootkit può trovarsi in forma crittografata e venire decrittografato al momento dell'avvio in modalità SMM. Come chiave per la crittografia si possono utilizzare dati accessibili solo in modalità SMM. Ad esempio, hash di un insieme di indirizzi in SMRAM. Per ottenere questa chiave, sarà necessario accedere a SMM. E questo può essere fatto in due modi. Trovare un RCE nel codice SMM e sfruttarlo, oppure aggiungere il proprio modulo SMM nel BIOS, il che non è possibile, poiché abbiamo attivato il Boot Guard.

Pertanto, questa vulnerabilità consente a un attaccante di:

• creare un rootkit nascosto e non rimovibile di scopo sconosciuto nel sistema;
• eseguire il proprio codice su uno dei core del chipset all'interno dell'Intel SoC, ovvero sull'Intel ISH (dai un'occhiata all'immagine).

Sebbene le capacità della sottosistema Intel ISH non siano ancora state esplorate, si presenta come un vettore di attacco interessante contro Intel ME.

Conclusioni

1. La ricerca ha permesso di ottenere una descrizione tecnica del funzionamento della tecnologia Intel Boot Guard. Un paio di misteri nel modello Intel di sicurezza tramite oscurità.
2. È stato presentato uno scenario di attacco che consente di creare un rootkit non rimovibile nel sistema.
3. Abbiamo visto che i moderni processori Intel sono in grado di eseguire molto codice proprietario ancor prima che il BIOS inizi a funzionare.
4. Le piattaforme con architettura Intel 64 stanno diventando sempre meno adatte all'esecuzione di software libero: verifica hardware, numero crescente di tecnologie e sottosistemi proprietari (tre core nel chipset SoC: x86 ME, x86 ISH e ARC PMC).

Mitigazioni

I fornitori che lasciano intenzionalmente aperta la manufacturing mode devono chiuderla assolutamente. Fino ad ora, si chiudono solo gli occhi e i nuovi sistemi Kaby Lake lo dimostrano.

Gli utenti possono disattivare Intel BG sui propri sistemi (che sono soggetti alla vulnerabilità descritta) avviando l'utility Flash Programming Tool con il parametro -closemnf. Prima di procedere, è necessario assicurarsi (con MEinfo) che la configurazione Intel BG nella regione ME preveda effettivamente la disattivazione di questa tecnologia dopo la programmazione nei FPF.

Fonte: habr.com