Avvio fidato di Schrödinger. Intel Boot Guard

Torniamo a un argomento di base e parliamo della sicurezza dei firmware nelle piattaforme informatiche compatibili con x86. Questa volta il principale ingrediente della ricerca è Intel Boot Guard (da non confondere con Intel BIOS Guard!) – una tecnologia di avvio affidabile basata su hardware, che il fornitore del sistema informatico può attivare o disattivare permanentemente in fase di produzione. E il metodo di ricerca ci è già familiare: analizzare con cura il reverse engineering dell'implementazione di questa tecnologia, descriverne l'architettura, arricchirla con dettagli non documentati, aggiungere a piacere vettori di attacco e mescolare il tutto. Aggiungiamo un po' di pepe raccontando come un difetto di produzione clonabile da anni da diversi fornitori consenta a un potenziale aggressore di utilizzare questa tecnologia per creare un rootkit nascosto nel sistema che non può essere rimosso nemmeno da un programmatore.

A proposito, la base dell'articolo è rappresentata dalle presentazioni "In Difesa dei Rootkit: Intel BootGuard" tenute alla conferenza ZeroNights 2016 e al 29° incontro DefCon Russia (entrambe le presentazioni qui).

Firmware della piattaforma informatica con architettura Intel 64

Iniziamo rispondendo alla domanda: quale firmware è alla base della moderna piattaforma informatica con architettura Intel 64? Certamente, UEFI BIOS. Ma tale risposta non sarebbe del tutto precisa. Diamo un'occhiata all'immagine che mostra la variante desktop (o laptop) di questa architettura.

La base è un insieme:

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

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

Quindi, la combinazione dei firmwares sopra menzionati costituisce il firmware della piattaforma informatica (system firmware), che è memorizzato nella memoria flash SPI comune. Per evitare confusione tra gli utenti riguardo a chi possiede cosa, il contenuto di questa memoria è suddiviso in diverse aree (come mostrato nell'immagine):

• UEFI BIOS;
• firmware ACPI EC (un'area separata è emersa con l'architettura microprocessore Skylake (2015), ma in situazioni reali non abbiamo ancora visto esempi del suo utilizzo, quindi il firmware del controller integrato è ancora parte di UEFI BIOS);
• firmware Intel ME;
• configurazione (indirizzo MAC, ecc.) dell'adattatore di rete integrato GbE (Gigabit Ethernet);
• descrittori flash (Flash Descriptors) – l'area principale della memoria flash, che contiene puntatori ad altre aree, nonché le autorizzazioni per l'accesso a queste.

La gestione dell'accesso alle aree (in base ai permessi impostati) è responsabilità del master del bus SPI, integrato nel controller SPI, attraverso il quale avviene l'accesso a questa memoria. Se i permessi sono impostati ai valori consigliati (per motivi di sicurezza) dalla Intel, ogni utente della memoria flash SPI ha accesso completo (lettura/scrittura) solo alla propria area. Le altre aree sono disponibili solo in lettura o non sono accessibili. È un fatto noto: in molti sistemi, la CPU ha accesso completo al UEFI BIOS e a GbE, accesso in lettura solo ai flash descriptor, mentre l'accesso all'area Intel ME è completamente assente. Perché in molti casi, e non in tutti? Ciò che è raccomandato non è necessariamente obbligatorio. Approfondiremo ulteriormente nell'articolo.

Meccanismi di protezione del firmware della piattaforma informatica contro le modifiche.

È evidente che il firmware della piattaforma informatica debba essere protetto da possibili compromissioni che consentirebbero a un potenziale attaccante di insediarsi in esso (sopravvivendo agli aggiornamenti/reinstallazioni del sistema operativo), eseguire il proprio codice in modalità altamente privilegiate, e così via. E la semplice delimitazione dell'accesso alle aree della memoria flash SPI, ovviamente, non è sufficiente. Pertanto, per proteggere il firmware da modifiche vengono applicati vari meccanismi specifici per ciascun ambiente di esecuzione.

Ad esempio, il firmware Intel ME è firmato per garantire integrità e autenticità, e viene verificato dal controller ME ad ogni caricamento nella memoria ME UMA. Questo processo di verifica è stato già trattato in uno dei nostri articoli, dedicato al sottosistema Intel ME.

Il firmware ACPI EC, generalmente, viene verificato solo per integrità. Tuttavia, essendo questo binario incluso nel firmware UEFI BIOS, quasi sempre si applicano le stesse meccaniche di protezione utilizzate per l'UEFI BIOS. Di questo parleremo.

Questi meccanismi possono essere suddivisi in due categorie.

Protezione da scrittura nella regione UEFI BIOS

1. Protezione fisica del contenuto della memoria flash SPI tramite un jumper di protezione da scrittura;
2. Protezione della proiezione della regione UEFI BIOS nello spazio degli indirizzi CPU tramite i registri PRx del chipset;
3. Blocco dei tentativi di scrittura nella regione UEFI BIOS generando e gestendo l'interruzione SMI corrispondente, impostando i 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 fornitori possono sviluppare e applicare misure di sicurezza proprie (ad esempio, la firma delle capsule con gli aggiornamenti UEFI BIOS).

È importante notare che su un sistema specifico (a seconda del fornitore) potrebbero non essere applicati tutti i meccanismi di protezione sopra menzionati, potrebbero non essere applicati affatto o potrebbero essere implementati in modo vulnerabile. Maggiori dettagli su questi meccanismi e sulla situazione relativa alla loro implementazione possono essere letti in questo articolo. Consigliamo agli interessati di dare un'occhiata all'intero ciclo di articoli sulla sicurezza del UEFI BIOS di CodeRush.

Verifica dell'autenticità del UEFI BIOS

Quando parliamo di tecnologie di avvio fidato, ciò che ci viene in mente per primo è Secure Boot. Tuttavia, architettonicamente è progettato per autenticare componenti esterni, rispetto al BIOS UEFI, come driver, bootloader, ecc., e non il firmware stesso.

Pertanto, nel 2012, Intel ha implementato Secure Boot hardware non disattivabile (Verified Boot) nei SoC con microarchitettura Bay Trail, che non ha nulla a che fare con la tecnologia Secure Boot sopra menzionata. Successivamente, nel 2013, questo meccanismo è stato migliorato e rilasciato come Intel Boot Guard per desktop con microarchitettura Haswell.

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

Intel CPU

La Kép ci ricorda che il processore è l'ambiente di esecuzione principale nell'architettura Intel 64. Perché è considerato la radice della fiducia? Pare che lo sia grazie alla presenza dei seguenti elementi:

• Microcode ROM — memoria non volatile e non riscrivibile per l'archiviazione del microcodice. Si ritiene che il microcodice sia un'implementazione del set di istruzioni del processore in istruzioni di base. Anche il microcodice può avere bug. Pertanto, nel BIOS possono essere trovati binari con aggiornamenti del microcodice (che vengono applicati durante l'avvio, poiché la ROM non può essere riscritta). Il contenuto di questi binari è crittografato, il che rende l'analisi significativamente più complessa (per questo motivo, il contenuto specifico del microcodice è noto solo a chi lo sviluppa) ed è firmato per garantire integrità e autenticità;
• chiave AES per la decrittazione del contenuto degli aggiornamenti del microcodice;
• hash della chiave pubblica RSA, utilizzato per verificare la firma degli aggiornamenti del microcodice;
• hash della chiave pubblica RSA, utilizzato per verificare la firma dei moduli di codice autenticati ACM (Authenticated Code Module) prodotti da Intel, che la CPU può eseguire prima dell'attivazione del BIOS (saluto al microcodice) o durante il suo funzionamento, in caso di alcuni eventi.

Intel ME

Questa sottosistema è stata trattata nel nostro blog per due articolo. Ricordiamo che questo ambiente esecutivo è basato su un microcontrollore integrato nel chipset ed è il più nascosto e privilegiato del sistema.

Nonostante la sua riservatezza, Intel ME è anche la radice di fiducia poiché possiede:

• ME ROM — memoria non volatile e non riscrivibile (non è prevista alcuna modalità di aggiornamento), contenente codice di avvio e l'hash SHA256 della chiave pubblica RSA utilizzata per verificare la firma del firmware Intel ME;
• chiave AES per la memorizzazione delle informazioni segrete;
• accesso a un insieme di fusibili programmabili in campo (FPFs, Field Programmable Fuses) integrati nel chipset per la memorizzazione permanente di alcune informazioni, inclusa quella fornita dal venditore del sistema computerizzato.

Intel Boot Guard 1.x

Un piccolo disclaimer. I numeri delle versioni della tecnologia Intel Boot Guard di cui discutiamo in questo articolo sono convenzionali e potrebbero non corrispondere alla numerazione utilizzata nella documentazione interna di Intel. Inoltre, le informazioni qui fornite sull'implementazione di questa tecnologia sono state ottenute tramite reverse engineering e possono contenere imprecisioni rispetto alle specifiche di Intel Boot Guard, che probabilmente non saranno mai pubblicate.

Quindi, Intel Boot Guard (BG) è una tecnologia di autenticazione UEFI BIOS supportata a livello 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 fidata. E il primo anello in essa è il codice di avvio (microcodice) all'interno della CPU, che viene attivato dall'evento RESET (non confondere con il vettore RESET nel BIOS!). La CPU trova nel flash SPI un modulo di codice sviluppato e firmato da Intel (Intel BG startup ACM), lo carica nella sua cache, lo verifica (è già stato notato che la CPU dispone di un hash della chiave pubblica con cui viene controllata la firma ACM) e lo attiva.

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

La tecnologia Intel BG prevede due modalità operative (e uno non interferisce con l'altro, cioè entrambe le modalità possono essere attivate nel sistema, oppure entrambe possono essere disattivate).

Measured Boot

In 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 familiarizzati, spieghiamo.

Il TPM ha dei PCR (Platform Configuration Registers), nei quali viene registrato il risultato dell'operazione di hashing secondo la formula:

Cioè, il valore attuale del PCR dipende da quello precedente, mentre i registri vengono azzerati solo quando il sistema viene effettuato un RESET.

In modalità MB, i PCR riflettono in un dato momento un identificatore unico (nelle possibilità dell'operazione di hashing) di codice o dati che sono stati "misurati". I valori dei PCR possono essere utilizzati durante l'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 al termine del caricamento (cioè, nessun componente "misurato" è stato modificato).

Boot verificato

Il modo più temuto dai modder dell'UEFI BIOS è il modo Boot verificato (VB), in cui ogni componente di avvio controlla crittograficamente l'integrità e l'autenticità del successivo. In caso di errore di verifica, si verifica una delle seguenti azioni:

• spegnimento dopo un timeout da 1 a 30 minuti (in modo che l'utente possa capire perché il computer non si avvia e, se possibile, tentare di recuperare il BIOS);
• spegnimento immediato (affinché l'utente non possa capire nulla e, tanto meno, fare qualcosa);
• continuazione delle operazioni con un'aria imperturbabile (quel caso in cui la sicurezza non è una priorità, poiché ci sono affari più importanti da affrontare).

La scelta dell'azione dipende dalla configurazione Intel BG (ovvero, dalla cosiddetta enforcement policy), che viene permanentemente registrata dal fornitore della piattaforma informatica in uno storage appositamente dedicato – fuse del chipset (FPF). Approfondiremo questo punto più avanti.

Oltre alla configurazione, il fornitore genera due chiavi RSA 2048 e crea due strutture dati (visibili nella figura):

1. Il manifesto della chiave radice del fornitore (KEYM, OEM Root Key Manifest), che contiene 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), che contiene l'SVN di questo manifesto, l'hash SHA256 dell'IBB, la chiave pubblica per la verifica della firma di questo manifesto e la firma stessa.

L'hash SHA256 della chiave pubblica OEM Root Key è permanentemente registrato nei fusibili del chipset (FPF), così come la configurazione Intel BG. Se la configurazione Intel BG prevede l'attivazione di questa tecnologia, da questo momento in poi su questo sistema l'aggiornamento del BIOS (ovvero la possibilità di ricalcolare questi manifesti) può essere effettuato solo dal possessore della parte privata dell'OEM Root Key, cioè dal venditore.

Guardando l'immagine, sorgono subito dubbi sulla necessità di una catena di verifica così lunga – si poteva utilizzare un solo manifesto. Perché complicare le cose?

In realtà, Intel offre al venditore la possibilità di utilizzare diverse chiavi IBB per diverse linee dei suoi 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 venditore non genera una nuova coppia e non include i manifesti ricalcolati nel successivo aggiornamento del BIOS.

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

Configurazione di Intel Boot Guard

Ora approfondiamo la configurazione di Intel BG e il processo di creazione. Se si guarda alla scheda corrispondente nell'interfaccia GUI dell'utensile Flash Image Tool fornito con il 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.

La 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. Consideriamo, ad esempio, il flag Force_Boot_Guard_ACM. Quando è disattivato, se il modulo BG startup ACM non è trovato nella memoria flash SPI, non ci sarà alcun avvio fidato. Ci sarà un avvio non fidato.

In precedenza abbiamo scritto che la policy di enforcement per la modalità VB può essere configurata in modo che, in caso di errore di verifica, si verifichi, ancora una volta, un caricamento non attendibile.

Lasciare tali decisioni a discrezione dei fornitori...

L'utilità GUI prevede i seguenti profili "pronti all'uso":

Numero
Modalità
Descrizione

0
No_FVME
la tecnologia Intel BG è disattivata

1
VE
la modalità VB è attivata, spegnimento per timeout

2
VME
sono attivate entrambe le modalità (VB e MB), spegnimento per timeout

3
VM
sono attivate entrambe le modalità, senza spegnimento del sistema

4
FVE
la modalità VB è attivata, spegnimento immediato

5
FVME
sono attivate entrambe le modalità, spegnimento immediato

Come già detto, la configurazione Intel BG deve essere una volta per tutte registrata dal fornitore del sistema nei fusibili del chipset (FPF) – una piccola memoria hardware (secondo fonti non verificate, solo 256 byte) all'interno del chipset, che può essere programmata al di fuori degli impianti produttivi di Intel (per questo motivo, proprio Field Programmable Fuses).

È perfetto per memorizzare la configurazione, poiché:

• ha un'area one-time-programmable per la memorizzazione dei dati (esattamente quella dove viene registrata la configurazione Intel BG);
• può essere letta e programmata solo da Intel ME.

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

1. Utilizzando l'utility Flash Image Tool (di Intel STK), crea un'immagine del firmware con la configurazione Intel BG specificata come variabili all'interno della regione Intel ME (il cosiddetto mirror temporaneo per gli FPF);
2. Utilizzando l'utility Flash Programming Tool (di Intel STK), scrive questa immagine nella memoria flash SPI del sistema e chiude la cosiddetta modalità di produzione (in questo momento viene inviata una corrispondente istruzione a Intel ME).

Come risultato di queste operazioni, Intel ME comitenterà nei FPF i valori specificati dal mirror per gli FPF nella regione ME, imposterà le autorizzazioni nei descrittori flash SPI ai valori raccomandati da Intel (discussi all'inizio dell'articolo) ed eseguirà un RESET del sistema.

Analisi dell'implementazione di Intel Boot Guard

Per analizzare come questa tecnologia viene implementata in un caso specifico, abbiamo verificato i seguenti sistemi per la presenza di tracce della tecnologia Intel BG:

Sistema
Nota

Gigabyte GA-H170-D3H
Skylake, supporto presente

Gigabyte GA-Q170-D3H
Skylake, supporto presente

Gigabyte GA-B150-HD3
Skylake, supporto presente

MSI H170A Gaming Pro
Skylake, supporto non presente

Lenovo ThinkPad 460
Skylake, supporto presente, tecnologia attivata

Lenovo Yoga 2 Pro
Haswell, supporto non presente

Lenovo U330p
Haswell, supporto non presente

Con "supporto" si intende la presenza del modulo Intel BG startup ACM, dei manifesti menzionati sopra e del corrispondente codice nel BIOS, ovvero l'implementazione per l'analisi.

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

Intel CPU boot ROM

Iniziamo parlando delle azioni del processore nel caso in cui la tecnologia Intel BG sia abilitata.

Non sono stati trovati campioni di microcodice decifrato, quindi la modalità con cui le azioni descritte di seguito sono implementate (nel microcodice o a livello hardware) rimane una questione aperta. Tuttavia, il fatto che i moderni processori Intel siano capaci di eseguire queste azioni è assodato.

Dopo essere uscita dallo stato RESET, la CPU (il cui contenuto della memoria flash è già mappato nello spazio degli indirizzi) trova la tabella FIT (Firmware Interface Table). Trovarla è semplice, il puntatore ad essa è registrato all'indirizzo FFFF FFC0h.

Nel caso in esame, a questo indirizzo si trova il valore FFD6 9500h. Accedendo a questo indirizzo, la CPU 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; // including FIT header entry
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

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

Le altre voci fanno riferimento a vari binari che devono essere analizzati/eseguiti prima dell'esecuzione del BIOS, ossia prima di passare al vettore RESET legacy (FFFF FFF0h). La struttura di ognuna di queste voci è 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 voce fa riferimento. Sono noti 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 voci fa riferimento alla posizione del binario Intel BG startup ACM. La struttura dell'intestazione di questo binario è tipica dei moduli di codice sviluppati da 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 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];
};

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

Intel BG startup ACM

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

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

Per trovare questi manifesti, l'ACM utilizza anche la tabella FIT, che prevede due tipi di registrazioni per indicare i dati della struttura (vedi FIT_ENTRY_TYPES sopra).

Focalizziamoci sui manifesti. Nella struttura del primo manifesto vediamo diverse costanti poco chiare, l'hash della chiave pubblica del secondo manifesto e la chiave pubblica OEM Root Key con una 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 == hash size?
	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, si utilizza l'hash SHA256 ottenuto dai fuse, già 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 vi sono 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è ciò da cui si calcola 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 == hash size ?
	unsigned char  IbbHash[32];       // SHA256 di un IBB
	unsigned char  NumIbbDescriptors;
};

I descriptores 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 (in ordine della loro posizione) è l'IBB. E, di norma, l'IBB è l'insieme di tutti i moduli delle fasi SEC e PEI.

Il secondo manifesto completa la struttura contenente la chiave pubblica IBB (verificata tramite l'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, prima dell'avvio del BIOS UEFI, il processore lancerà l'ACM, che verificherà l'autenticità dei contenuti delle sezioni contenenti il codice delle fasi SEC e PEI. Successivamente, il processore esce dall'ACM, segue il vettore RESET e inizia a eseguire il BIOS.

La sezione PEI verificata deve contenere un modulo che controllerà il resto del BIOS (codice DXE). Questo modulo è sviluppato dall'IBV (Independent BIOS Vendor) o dal fornitore del sistema stesso. Poiché le uniche piattaforme disponibili che supportano Intel BG sono risultate essere sistemi Lenovo e Gigabyte, esamineremo il codice estratto specificamente da questi sistemi.

Modulo UEFI BIOS LenovoVerifiedBootPei

Nel caso di Lenovo, si tratta del modulo LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, sviluppato da Lenovo.

La sua funzione consiste nel cercare (tramite GUID) una tabella hash per il DXE e verificare il 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, si è trattato del modulo BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, sviluppato da AMI, presente in qualsiasi BIOS AMI che supporti Intel BG.

Il suo algoritmo di funzionamento è leggermente diverso, ma si riduce comunque allo stesso concetto:

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 sta cercando 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 nei SoC (i nuovi sistemi con microarchitettura del processore Kaby Lake continuano a utilizzare Intel Boot Guard 1.x), è di grande interesse per lo studio di una nuova architettura per le piattaforme Intel SoC, in cui ci sono stati cambiamenti significativi, come ad esempio:

• le regioni BIOS e Intel ME (piuttosto Intel TXE, secondo la terminologia per Intel SoC) ora costituiscono un'unica regione IFWI;
• Anche se sulla piattaforma era abilitato Intel BG, strutture come FIT, KEYM, IBBM non sono state trovate nella memoria flash;
• Oltre ai core TXE e ISH (x86), il chipset ha aggiunto un terzo core (di nuovo ARC, per inciso) – PMC (Power Management Controller), collegato alla gestione della sottosistema di alimentazione e al monitoraggio delle prestazioni.

Il contenuto del nuovo spazio IFWI è composto dai seguenti moduli:

Offset
Nome
Descrizione

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

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

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

0002 0000h
FTPR
sezione 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 del firmware Intel ISH, x86, firmata dal fornitore

0025 8000h
NFTP
sezione 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 indirizzi per la CPU (FIT, ACM, vettore di RESET …). TXE colloca questi dati nella sua SRAM, fornisce temporaneamente accesso al processore e lo «libera» dal RESET.

In guardia contro i rootkit

Ora passiamo al ‘caldo’. Una volta abbiamo scoperto che su molti sistemi i descrittori flash SPI contengono permessi per l'accesso alle regioni della memoria flash SPI in modo che tutti gli utenti di questa memoria possano leggere e scrivere in qualsiasi regione. Cioè, in nessun modo.

Dopo aver effettuato un controllo utilizzando l'utilità MEinfo (dall'Intel STK), abbiamo visto che la modalità di fabbricazione su questi sistemi non è chiusa, quindi i fusi del chipset (FPF) sono stati lasciati in uno stato indefinito. Sì, l'Intel BG in questi casi non è né attivato né disattivato.

Si tratta dei seguenti sistemi (riguardo all'Intel BG e a ciò che sarà descritto successivamente nell'articolo, parleremo di sistemi con microarchitettura della CPU Haswell e superiori):

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

Certo, abbiamo informato questi fornitori e anche la compagnia Intel della scoperta.

Una risposta adeguata è arrivata solo da Lenovo, che ha riconosciuto il problema e ha rilasciato una patch.

Gigabyte hanno apparentemente accettato le informazioni sulla vulnerabilità, ma non hanno fornito commenti.

La comunicazione con MSI è completamente stagnata sulla nostra richiesta di inviare la loro chiave PGP per ricevere advisory di sicurezza in forma crittografata. Hanno dichiarato di essere "produttori di hardware, e non producono chiavi PGP".

Ma torniamo al punto. Poiché i fusibili sono stati lasciati nel loro stato non programmato, l'utente (o un potenziale attaccante) può programmarli da solo (la parte più difficile è trovare l'Intel STK). Per questo, è necessario eseguire i seguenti passaggi.

1. Avviare il sistema operativo Windows (in realtà, le azioni descritte di seguito possono essere fatte anche sotto Linux, se si sviluppa un'analoga Intel STK per il sistema operativo richiesto). Usando lo strumento MEinfo, verificare che i fusibili in 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 di editing del BIOS UEFI, apportare le modifiche necessarie (ad esempio, inserire un rootkit), creare/modificare le strutture KEYM e IBBM esistenti nella regione ME.

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

4. Utilizzare il Flash Image Tool per assemblare una nuova immagine del firmware (impostando la configurazione Intel BG).

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

6. Utilizzare il Flash Programming Tool per disattivare la modalità di produzione.

7. Il sistema si riavvierà, al termine del quale sarà possibile verificare con MEinfo che i FPF siano ora programmati.

Queste azioni attiveranno permanentemente Intel BG su questo sistema. Annullare l'azione non sarà possibile, il che significa:

• solo il possessore della parte privata della chiave principale (cioè colui che ha attivato Intel BG) potrà aggiornare il BIOS UEFI su questo sistema;
• se si ripristina il firmware originale su questo sistema, ad esempio utilizzando un programmatore, esso non si avvierà nemmeno (conseguenza della enforcement policy in caso di errore di verifica);
• Per rimuovere un BIOS UEFI di questo tipo, è 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 che costa quanto un'auto, oppure semplicemente sostituire la scheda madre).

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

• essere eseguito in parallelo con il sistema operativo (è possibile configurare l'esecuzione tramite la generazione di un'interruzione SMI, che sarà attivata da un timer);
• avere tutti i vantaggi di trovarsi nella modalità SMM (accesso completo al contenuto della memoria RAM e alle risorse hardware, invisibilità rispetto al sistema operativo);
• Il codice software di un rootkit può trovarsi in forma crittografata e decrittografarsi all'avvio in modalità SMM. Qualsiasi dato accessibile solo in modalità SMM può essere utilizzato come chiave per la crittografia. Ad esempio, l'hash di un insieme di indirizzi in SMRAM. Per ottenere questa chiave, è necessario accedere a SMM. Questo può essere fatto in due modi: trovare RCE nel codice SMM e sfruttarlo, oppure aggiungere un proprio modulo SMM nel BIOS, il che è impossibile poiché abbiamo attivato il Boot Guard.

Pertanto, questa vulnerabilità consente a un attaccante di:

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

Sebbene le capacità del sottosistema Intel ISH non siano ancora state esplorate, esso rappresenta un interessante vettore di attacco per Intel ME.

Conclusioni

1. La ricerca ha permesso di ottenere una descrizione tecnica del funzionamento della tecnologia Intel Boot Guard. Meno segreti nella modalità di sicurezza di Intel nota come security through obscurity.
2. È stato presentato uno scenario di attacco che consente di creare nel sistema un rootkit non rimovibile.
3. Abbiamo riscontrato che i moderni processori Intel possono eseguire molto codice proprietario già prima dell'avvio del BIOS.
4. Le piattaforme basate sull'architettura Intel 64 stanno diventando sempre meno adatte all'esecuzione di software libero: verifica hardware, aumento del numero di tecnologie proprietarie e sistemi (tre core nel chipset SoC: x86 ME, x86 ISH e ARC PMC).

Mitigazioni

I fornitori che scelgono di mantenere aperto il manufacturing mode devono assolutamente chiuderlo. Finora si chiudono solo gli occhi e i nuovi sistemi Kaby Lake dimostrano questo.

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

Fonte: habr.com