Lo stivale fidato di Schrödinger. Protezione avvio Intel

Proponiamo di scendere di nuovo al livello basso e parlare della sicurezza delle piattaforme di computer compatibili con firmware x86. Questa volta, l'ingrediente principale della ricerca è Intel Boot Guard (da non confondere con Intel BIOS Guard!), una tecnologia di avvio attendibile del BIOS supportata da hardware che un fornitore di sistemi informatici può abilitare o disabilitare permanentemente in fase di produzione. Ebbene, conosciamo già la ricetta della ricerca: tagliare sottilmente l'implementazione di questa tecnologia mediante il reverse engineering, descriverne l'architettura, riempirla di dettagli non documentati, condirla con vettori di attacco a piacere e mescolarla. Aggiungiamo fuoco con una storia su come un bug clonato nella produzione di diversi fornitori da anni consente a un potenziale aggressore di utilizzare questa tecnologia per creare un rootkit nascosto che non può essere rimosso (nemmeno da un programmatore) nel sistema.

A proposito, l'articolo si basa sui rapporti "On Guard for Rootkits: Intel BootGuard" della conferenza Zero Notti 2016 e 29° incontro Defcon Russia (entrambe le presentazioni qui).

Firmware per una piattaforma di computer con architettura Intel 64

Per cominciare, rispondiamo alla domanda: qual è il firmware di una moderna piattaforma informatica con l'architettura Intel 64? Ovviamente BIOS UEFI. Ma questa risposta non sarà accurata. Diamo un'occhiata alla figura, che mostra la versione desktop (laptop) di questa architettura.

La base è il collegamento:

• Processore (CPU, Central Processing Unit), che, oltre ai core principali, ha un core grafico integrato (non in tutti i modelli) e un controller di memoria (IMC, Integrated Memory Controller);
• Chipset (PCH, Platform Controller Hub), contenente vari controller per l'interazione con i dispositivi periferici e la gestione dei sottosistemi. Tra questi c'è il famigerato Intel Management Engine (ME), che ha anche un firmware (firmware Intel ME).

I laptop, oltre a quanto sopra, richiedono un controller integrato (ACPI EC, Advanced Control and Power Interface Embedded Controller), che è responsabile del funzionamento del sottosistema di alimentazione, touchpad, tastiera, tasti Fn (luminosità dello schermo, volume del suono, tastiera retroilluminazione, ecc.) e altro ancora. E ha anche il suo firmware.

Pertanto, la combinazione del firmware di cui sopra è il firmware della piattaforma del computer (firmware di sistema), che è memorizzato su una comune memoria flash SPI. Affinché gli utenti di questa memoria non si confondano su dove giace qualcuno, il contenuto di questa memoria è suddiviso nelle seguenti regioni (come mostrato nella figura):

• UEFI-BIOS;
• Firmware ACPI EC (è apparsa una regione separata con la microarchitettura del processore Skylake (2015), ma in natura non abbiamo ancora visto esempi del suo utilizzo, quindi il firmware del controller integrato fa ancora parte del BIOS UEFI);
• Firmware Intel ME;
• configurazione (indirizzo MAC, ecc.) dell'adattatore di rete GbE (Gigabit Ethernet) integrato;
• descrittori flash: la regione principale della memoria flash, che contiene puntatori ad altre regioni, nonché le autorizzazioni per accedervi.

La differenziazione dell'accesso alle regioni (in conformità con le autorizzazioni specificate) è gestita dal master del bus SPI, il controller SPI integrato nel chipset, attraverso il quale si accede a questa memoria. Se le autorizzazioni sono impostate sui valori consigliati (per motivi di sicurezza) da Intel, ogni utente della SPI flash ha accesso completo (lettura/scrittura) solo alla propria regione. Il resto è di sola lettura o inaccessibile. Fatto noto: su molti sistemi, la CPU ha pieno accesso a UEFI BIOS e GbE, accesso in lettura solo ai descrittori flash e nessun accesso alla regione Intel ME. Perché molti e non tutti? Ciò che è consigliato è facoltativo. Vi diremo di più più avanti nell'articolo.

Meccanismi per proteggere il firmware di una piattaforma informatica dalla modifica

Ovviamente, il firmware di una piattaforma informatica dovrebbe essere protetto da possibili compromissioni, il che consentirebbe a un potenziale utente malintenzionato di prendere piede in esso (sopravvivere agli aggiornamenti / reinstallazioni del sistema operativo), eseguire il proprio codice nelle modalità più privilegiate, ecc. E delimitare l'accesso alle regioni di memoria flash SPI, ovviamente, non è sufficiente. Pertanto, vengono utilizzati vari meccanismi specifici per ogni ambiente di esecuzione per proteggere il firmware dalle modifiche.

Pertanto, il firmware Intel ME è firmato per il controllo dell'integrità e dell'autenticità e viene controllato dal controller ME ogni volta che viene caricato nella memoria ME UMA. Questo processo di verifica è già stato discusso da noi in uno dei articolidedicato al sottosistema Intel ME.

E il firmware ACPI EC, di norma, viene controllato solo per l'integrità. Tuttavia, poiché questo file binario è incluso nell'UEFI BIOS, è quasi sempre soggetto agli stessi meccanismi di protezione utilizzati dall'UEFI BIOS. Parliamo di loro.

Questi meccanismi possono essere suddivisi in due categorie.

Protezione da scrittura nella regione UEFI BIOS

1. Protezione fisica del contenuto della memoria flash SPI con jumper di protezione da scrittura;
2. Protezione della proiezione della regione UEFI BIOS nello spazio degli indirizzi della CPU utilizzando i registri PRx del chipset;
3. Bloccare i tentativi di scrittura nella regione UEFI BIOS generando ed elaborando l'interrupt SMI corrispondente impostando i bit BIOS_WE / BLE e SMM_BWP nei registri del chipset;
4. Una versione più avanzata di questa protezione è Intel BIOS Guard (PFAT).

Oltre a questi meccanismi, i fornitori possono sviluppare e implementare le proprie misure di sicurezza (ad esempio firmando capsule con aggiornamenti UEFI BIOS).

È importante notare che su un sistema specifico (a seconda del fornitore), non tutti i meccanismi di protezione di cui sopra potrebbero essere applicati, potrebbero non essere applicati affatto o potrebbero essere implementati in modo vulnerabile. Puoi leggere di più su questi meccanismi e sulla situazione con la loro implementazione in questo articolo. Per chi fosse interessato, consigliamo di leggere l'intera serie di articoli sulla sicurezza UEFI BIOS da CodeRush.

Verifica dell'autenticazione UEFI BIOS

Quando parliamo di tecnologie di avvio attendibili, la prima cosa che viene in mente è Secure Boot. Tuttavia, dal punto di vista dell'architettura, è progettato per autenticare componenti esterni al BIOS UEFI (driver, caricatori, ecc.) e non il firmware stesso.

Pertanto, Intel nei SoC con la microarchitettura Bay Trail (2012) ha implementato un Secure Boot hardware non commutabile (Verified Boot), che non ha nulla a che fare con la suddetta tecnologia Secure Boot. Successivamente (2013), questo meccanismo è stato migliorato e, con il nome Intel Boot Guard, è stato rilasciato per desktop con microarchitettura Haswell.

Prima di descrivere Intel Boot Guard, esaminiamo gli ambienti di esecuzione nell'architettura Intel 64, che, insieme, sono le radici dell'affidabilità per questa tecnologia di avvio affidabile.

CPU Intel

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

• La ROM del microcodice è una memoria non volatile e non riscrivibile per la memorizzazione del microcodice. Si ritiene che il microcodice sia l'implementazione del sistema di istruzioni del processore sulle istruzioni più semplici. Succede anche nel microcodice bug. Quindi nel BIOS puoi trovare i binari con gli aggiornamenti del microcodice (vengono sovrapposti all'avvio, perché la ROM non può essere sovrascritta). Il contenuto di questi binari è crittografato, il che complica notevolmente l'analisi (quindi, il contenuto specifico del microcodice è noto solo a chi lo sviluppa), e firmato per controllarne l'integrità e l'autenticità;
• Chiave AES per decifrare il contenuto degli aggiornamenti del microcodice;
• un hash della chiave pubblica RSA che verifica la firma degli aggiornamenti del microcodice;
• Hash della chiave pubblica RSA, che controlla la firma dei moduli di codice ACM (Authenticated Code Module) sviluppati da Intel, che la CPU può eseguire prima dell'avvio del BIOS (hello microcode) o durante il suo funzionamento, quando si verificano alcuni eventi.

Intel ME

Questo sottosistema nel nostro blog era dedicato a две articoli. Ricordiamo che questo ambiente eseguibile si basa sul microcontrollore integrato nel chipset ed è il più nascosto e privilegiato del sistema.

Nonostante la furtività, Intel ME è anche la radice della fiducia, perché ha:

• ME ROM - memoria non volatile, non riscrivibile (nessun metodo di aggiornamento fornito), contenente il codice iniziale, nonché l'hash SHA256 della chiave pubblica RSA, che controlla la firma del firmware Intel ME;
• Chiave AES per la memorizzazione di informazioni segrete;
• accesso a una serie di fusibili (FPF, Field Programmable Fuses) integrati nel chipset per la memorizzazione permanente di alcune informazioni, comprese le informazioni specificate dal fornitore del sistema informatico.

Protezione avvio Intel 1.x

Piccolo disclaimer. I numeri di versione della tecnologia Intel Boot Guard utilizzati in questo articolo sono arbitrari e potrebbero non avere nulla a che fare con la numerazione utilizzata nella documentazione Intel interna. Inoltre, le informazioni sull'implementazione di questa tecnologia fornite qui sono state ottenute durante il reverse engineering e potrebbero contenere imprecisioni rispetto alle specifiche per Intel Boot Guard, che è improbabile che vengano mai pubblicate.

Pertanto, Intel Boot Guard (BG) è una tecnologia di autenticazione UEFI BIOS supportata dall'hardware. A giudicare dalla sua piccola descrizione nel libro [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], funziona come una catena di avvio affidabile. E il primo collegamento in esso è il codice di avvio (microcodice) all'interno della CPU, che viene attivato dall'evento RESET (da non confondere con il vettore RESET nel BIOS!). La CPU trova un modulo di codice (Intel BG startup ACM) sviluppato e firmato da Intel sulla memoria flash SPI, lo carica nella sua cache, lo verifica (è stato già notato sopra che la CPU ha un hash di chiave pubblica che verifica la firma ACM ) e inizia.

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

La tecnologia Intel BG fornisce due modalità di funzionamento (e una non interferisce con l'altra, ovvero entrambe le modalità possono essere abilitate sul sistema ed entrambe possono essere disabilitate).

Stivale misurato

Nella modalità di avvio con misurazione (MB), ogni componente di avvio (a partire dalla ROM di avvio della CPU) "misura" il successivo utilizzando le funzionalità del TPM (Trusted Platform Module). Per chi non lo sapesse, mi spiego.

TPM dispone di PCR (Platform Configuration Registers), che registrano il risultato dell'operazione di hashing secondo la formula:

Quelli. il valore attuale della PCR dipende dal precedente, e questi registri vengono azzerati solo quando il sistema viene RESET.

Pertanto, in modalità MB, a un certo punto nel tempo, le PCR riflettono un identificatore univoco (entro le capacità dell'operazione hash) del codice o dei dati che sono stati "misurati". I valori 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 PCR non sono cambiati a seguito del caricamento (ovvero, non è stato modificato un singolo componente "misurato").

Avvio verificato

La cosa più spaventosa per chi ama modificare il BIOS UEFI è la modalità Verified Boot (VB), in cui ogni componente di avvio verifica crittograficamente l'integrità e l'autenticità di quello successivo. E in caso di errore di verifica, si verifica (uno dei seguenti):

• spegnimento per timeout da 1 minuto a 30 minuti (in modo che l'utente abbia il tempo di capire perché il suo computer non si avvia e, se possibile, proverebbe a ripristinare il BIOS);
• spegnimento immediato (in modo che l'utente non abbia il tempo di capire e, inoltre, di fare);
• continuazione del lavoro con la faccia seria (il caso in cui non c'è tempo per la sicurezza, perché ci sono cose più importanti da fare).

La scelta dell'azione dipende dalla configurazione Intel BG specificata (vale a dire, dalla cosiddetta policy di applicazione), che viene registrata in modo permanente dal fornitore della piattaforma del computer in uno storage appositamente progettato - chipset fuses (FPF). Ci soffermeremo su questo punto in modo più dettagliato in seguito.

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

1. Il vendor root key manifest (KEYM, OEM Root Key Manifest), che inserisce l'SVN (Security Version Number) di questo manifest, l'hash SHA256 della chiave pubblica del manifest successivo, la chiave pubblica RSA (ovvero la parte pubblica del vendor root key) per verificare la firma di questo manifest e la firma stessa;
2. L'IBB Manifest (IBBM, Initial Boot Block Manifest), che inserisce l'SVN di questo manifest, l'hash SHA256 dell'IBB, la chiave pubblica per verificare la firma di questo manifest e la firma stessa.

L'hash SHA256 della chiave root OEM viene scritto in modo permanente sui fusibili del chipset (FPF), proprio come la configurazione Intel BG. Se la configurazione Intel BG prevede l'inclusione di questa tecnologia, d'ora in poi questo sistema solo il proprietario della parte privata della chiave root OEM può aggiornare il BIOS (ovvero essere in grado di ricalcolare questi manifest), ad es. venditore.

Quando guardi l'immagine, sorgono immediatamente dei dubbi sulla necessità di una catena di verifica così lunga: avresti potuto usare un manifest. Perché complicare?

Infatti, Intel offre così al fornitore l'opportunità di utilizzare diverse chiavi IBB per diverse linee di prodotti e una come root. Se la parte privata della chiave IBB (che firma il secondo manifest) è trapelata, l'incidente riguarderà solo una linea di prodotti e solo fino a quando il fornitore non genererà una nuova coppia e abiliterà i manifest ricalcolati nel successivo aggiornamento del BIOS.

Ma se la root key è compromessa (con la quale viene firmato il primo manifest), non sarà possibile sostituirla, la procedura di revoca non è prevista. l'hash della parte pubblica di questa chiave è programmato negli FPF una volta per tutte.

Configurazione di Intel Boot Guard

Ora diamo un'occhiata più da vicino alla configurazione di Intel BG e al processo della sua creazione. Se guardi la scheda corrispondente nella GUI di Flash Image Tool da Intel System Tool Kit (STK), noterai che la configurazione di Intel BG include un hash della parte pubblica della chiave root del fornitore, un paio di oscuri valori, e così via. Profilo IntelBG.

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 – do nothing
                                              // 01b – shutdown with timeout
                                              // 11b – immediate shutdown
	unsigned long : 26;
};

In generale, la configurazione Intel BG è un'entità molto flessibile. Si consideri, ad esempio, il flag Force_Boot_Guard_ACM. Quando è deselezionato, se il modulo ACM di avvio BG sul flash SPI non viene trovato, non si verificherà alcun avvio attendibile. Sarà inaffidabile.

Abbiamo già scritto in precedenza che la politica di applicazione per la modalità VB può essere configurata in modo tale che se la verifica fallisce, si verificherà nuovamente un download non attendibile.

Lascia fare cose del genere ai venditori...

La GUI dell'utility fornisce i seguenti profili "già pronti":

numero
regime
Descrizione

0
No_FVME
Tecnologia Intel BG disabilitata

1
VE
Modalità VB abilitata, spegnimento per timeout

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

3
VM
entrambe le modalità sono abilitate, senza spegnere il sistema

4
FVE
Modalità VB abilitata, spegnimento immediato

5
FVME
entrambe le modalità abilitate, spegnimento immediato

Come già accennato, la configurazione di Intel BG deve essere scritta una volta per tutte dal fornitore del sistema nei fusibili del chipset (FPF), un piccolo archivio di informazioni hardware (secondo informazioni non verificate, solo 256 byte) all'interno del chipset, che può essere programmato all'esterno degli impianti di produzione di Intel (quindi ecco perché Programmabile sul campo fusibili).

È ottimo per memorizzare la configurazione perché:

• ha un'area di archiviazione dati programmabile una sola volta (proprio dove è scritta la configurazione Intel BG);
• solo Intel ME può leggerlo e programmarlo.

Pertanto, per impostare la configurazione per la tecnologia Intel BG su un sistema specifico, il fornitore esegue le seguenti operazioni durante la produzione:

1. Utilizzando Flash Image Tool (di Intel STK), crea un'immagine firmware con una data configurazione Intel BG come variabili all'interno della regione Intel ME (il cosiddetto mirror temporaneo per FPF);
2. Utilizzando lo strumento di programmazione Flash (da Intel STK), scrive questa immagine nella memoria flash SPI del sistema e chiude il cosiddetto. modalità di produzione (in questo caso, il comando corrispondente viene inviato a Intel ME).

Come risultato di queste operazioni, Intel ME affiderà agli FPF i valori forniti dal mirror per gli FPF nella regione ME, imposterà le autorizzazioni nei descrittori flash SPI sui valori consigliati da Intel (descritti all'inizio del articolo) ed eseguire un RESET del sistema.

Analisi dell'implementazione di Intel Boot Guard

Per analizzare l'implementazione di questa tecnologia su un esempio specifico, abbiamo controllato i seguenti sistemi per le tracce della tecnologia Intel BG:

Sistema
Nota

Gigabyte GA-H170-D3H
Skylake, c'è supporto

Gigabyte GA-Q170-D3H
Skylake, c'è supporto

GigabyteGA-B150-HD3
Skylake, c'è supporto

MSI H170A GamingPro
Skylake, nessun supporto

Lenovo Think Pad 460
Skylake, supporto disponibile, tecnologia abilitata

Lenovo Yoga 2 Pro
Haswell, nessun supporto

Lenovo U330p
Haswell, nessun supporto

"Supporto" indica la presenza del modulo ACM di avvio Intel BG, i manifest sopra menzionati e il codice corrispondente nel BIOS, ad es. implementazioni per l'analisi.

Ad esempio, prendiamo quello scaricato dall'ufficio. immagine del sito del fornitore della memoria flash SPI per Gigabyte GA-H170-D3H (versione F4).

ROM di avvio della CPU Intel

Prima di tutto, parliamo delle azioni del processore se la tecnologia Intel BG è abilitata.

Non è stato possibile trovare campioni del microcodice decifrato, pertanto, come vengono implementate le azioni descritte di seguito (nel microcodice o nell'hardware) è una questione aperta. Tuttavia, il fatto che i moderni processori Intel "possano" eseguire queste azioni è un dato di fatto.

Dopo essere uscito dallo stato di RESET, il processore (nel cui spazio indirizzi è già mappato il contenuto della memoria flash) trova la FIT (Firmware Interface Table). Trovarlo è facile, il puntatore ad esso è scritto all'indirizzo FFFF FFC0h.

In questo esempio, questo indirizzo contiene il valore FFD6 9500h. Passando a questo indirizzo, il processore vede la tabella FIT, il cui contenuto è suddiviso in record. La prima voce è 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 qualche motivo sconosciuto, il checksum non viene sempre calcolato in queste tabelle (il campo viene lasciato nullo).

Le voci rimanenti puntano a vari binari che devono essere analizzati/eseguiti prima che il BIOS venga eseguito, ad es. prima di passare al vettore RESET legacy (FFFF FFF0h). La struttura di ciascuna 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 punta questa voce. Ne 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 è ovvio che una delle voci punta alla posizione del binario ACM di avvio di Intel BG. 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 avvia.

ACM di avvio di Intel BG

Come risultato dell'analisi del lavoro di questo ACM, è diventato chiaro che fa quanto segue:

• riceve da Intel ME la configurazione Intel BG scritta sui fusibili del chipset (FPF);
• trova i manifest KEYM e IBM, li verifica.

Per trovare questi manifest, ACM utilizza anche la tabella FIT, che ha due tipi di voci per puntare a queste strutture (vedi FIT_ENTRY_TYPES sopra).

Diamo un'occhiata più da vicino ai manifesti. Nella struttura del primo manifest, vediamo diverse costanti oscure, un hash della chiave pubblica del secondo manifest e una chiave radice OEM pubblica firmata come struttura nidificata:

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 verificare la chiave pubblica della Root Key OEM, ricordiamo che viene utilizzato l'hash SHA256 dei fusibili, che in questo momento è già stato ricevuto da Intel ME.

Passiamo al secondo manifesto. Si compone di tre strutture:

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

Il primo contiene 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
};

Il secondo contiene l'hash SHA256 dell'IBB e il numero di descrittori che descrivono il contenuto dell'IBB (ovvero da cosa viene calcolato 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 of an 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 l'indirizzo/dimensione di un blocco IBB. Pertanto, la concatenazione dei blocchi a cui puntano questi descrittori (nell'ordine dei descrittori stessi) è IBB. E, di norma, IBB è una combinazione di tutti i moduli delle fasi SEC e PEI.

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

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

Pertanto, anche prima dell'inizio dell'esecuzione del BIOS UEFI, il processore avvierà ACM, che verificherà l'autenticità del contenuto delle sezioni con il codice di fase SEC e PEI. Successivamente, il processore esce dall'ACM, si sposta lungo il vettore RESET e avvia l'esecuzione del BIOS.

La partizione verificata PEI deve contenere un modulo che controllerà il resto del BIOS (codice DXE). Questo modulo è già in fase di sviluppo da parte di IBV (Independent BIOS Vendor) o del fornitore del sistema stesso. Perché Solo i sistemi Lenovo e Gigabyte si sono rivelati a nostra disposizione e con supporto Intel BG, consideriamo il codice estratto da questi sistemi.

Modulo UEFI BIOS LenovoVerifiedBootPei

Nel caso di Lenovo, si è rivelato essere il modulo LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, sviluppato da Lenovo.

Il suo compito è 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;
}

Хеш таблица {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;
};

Modulo UEFI BIOS BootGuardPei

Nel caso di Gigabyte, si è rivelato essere il modulo BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, sviluppato da AMI, e quindi presente in qualsiasi AMI BIOS con supporto Intel BG.

Il suo algoritmo di funzionamento è leggermente diverso, tuttavia, si riduce allo stesso:

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

Protezione avvio Intel 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 verrà utilizzata solo nei SoC (i nuovi sistemi con microarchitettura del processore Kaby Lake continuano a utilizzare Intel Boot Guard 1.x), è di grande interesse esplorare una nuova opzione di architettura per piattaforme basate su Intel SoC, che ha visto tangibili modifiche, ad esempio:

• Le regioni BIOS e Intel ME (o meglio Intel TXE, secondo la terminologia Intel SoC) sono ora una regione IFWI;
• sebbene Intel BG fosse abilitato sulla piattaforma, strutture come FIT, KEYM, IBMM non sono state trovate nella memoria flash;
• oltre ai core TXE e ISH (x86), al chipset è stato aggiunto un terzo core (di nuovo ARC, tra l'altro) - PMC (Power Management Controller), associato a garantire l'operabilità del sottosistema di alimentazione e il monitoraggio delle prestazioni.

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

spostamento
Nome
Descrizione

0000 2000 h
SMIP
alcune configurazioni della piattaforma, firmate dal fornitore

0000 6000 h
RBEP
Sezione del codice del firmware Intel TXE, x86, firmata da Intel

0001 0000 h
PMCP
sezione codice firmware Intel PMC, ARC, firmato da Intel

0002 0000 h
FTPR
Sezione del codice del firmware Intel TXE, x86, firmata da Intel

0007B000h
UCOD
Aggiornamenti del microcodice della CPU firmati da Intel

0008 0000 h
IBBP
UEFI BIOS, fasi SEC/PEI, x86, firma del fornitore

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

0025 8000 h
FTP
Sezione del codice del firmware Intel TXE, x86, firmata da Intel

0036 1000 h
IUNP
sconosciuto

0038 1000 h
OBBP
BIOS UEFI, fase DXE, x86, senza segno

Durante l'analisi del firmware TXE, è apparso evidente che dopo RESET, TXE mantiene il processore in questo stato fino a quando non prepara i contenuti di base dello spazio degli indirizzi per la CPU (FIT, ACM, RESET vector ...). Inoltre, TXE inserisce questi dati nella sua SRAM, dopodiché fornisce temporaneamente al processore l'accesso lì e lo "rilascia" dal RESET.

A guardia dei rootkit

Bene, ora passiamo al "caldo". Una volta abbiamo scoperto che su molti sistemi, i descrittori flash SPI hanno le autorizzazioni per accedere alle regioni della memoria flash SPI in modo che tutti gli utenti di questa memoria possano scrivere e leggere qualsiasi regione. Quelli. non c'è modo.

Dopo aver verificato con l'utilità MEinfo (di Intel STK), abbiamo visto che la modalità di produzione su questi sistemi non era chiusa, quindi i fusibili del chipset (FPF) erano rimasti in uno stato indeterminato. Sì, Intel BG non è né abilitato né disabilitato in questi casi.

Stiamo parlando dei seguenti sistemi (per quanto riguarda Intel BG e quanto verrà descritto più avanti nell'articolo, parleremo di sistemi con microarchitettura del processore Haswell e superiori):

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

Naturalmente, abbiamo segnalato la scoperta a questi fornitori, oltre che a Intel.

Una risposta adeguata è seguita solo da Lenovoche ha riconosciuto il problema e rilasciato una patch.

Gigabyte Sembra che abbiano accettato informazioni sulla vulnerabilità, ma non hanno commentato in alcun modo.

Comunicazione con MSI completamente bloccato alla nostra richiesta di inviare la nostra chiave PGP pubblica (per inviare loro un avviso di sicurezza crittografato). Hanno affermato di "essere un produttore di hardware e non producono chiavi PGP".

Ma più al punto. Poiché i fusibili sono lasciati in uno stato indefinito, l'utente (o l'aggressore) può programmarli da solo (il più difficile è trova Intel STK). Ciò richiede i seguenti passaggi.

1. Avviare nel sistema operativo Windows (in generale, i passaggi descritti di seguito possono essere eseguiti anche da Linux, se si sviluppa un analogo di 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 lo strumento di programmazione Flash.

3. Aprire l'immagine letta utilizzando qualsiasi strumento di modifica UEFI BIOS, apportare le modifiche necessarie (implementare un rootkit, ad esempio), creare/modificare le strutture KEYM e IBM esistenti nella regione ME.

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

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

5. Scrivere una nuova immagine su Flash utilizzando lo strumento di programmazione Flash, verificare utilizzando MEinfo che la regione ME ora contenga la configurazione Intel BG.

6. Utilizzare lo strumento di programmazione Flash per chiudere la modalità di produzione.

7. Il sistema si riavvierà, dopodiché, tramite MEinfo, potrai verificare che gli FPF siano ora programmati.

Queste azioni sempre abilitare Intel BG su questo sistema. Sarà impossibile annullare l'azione, il che significa:

• solo il proprietario della parte privata della root key (ovvero colui che ha abilitato Intel BG) potrà aggiornare UEFI BIOS su questo sistema;
• se restituisci il firmware originale a questo sistema, ad esempio, utilizzando un programmatore, non si accenderà nemmeno (una conseguenza della politica di applicazione in caso di errore di verifica);
• per sbarazzarsi di un tale BIOS UEFI, è necessario sostituire il chipset con FPF programmati con uno "pulito" (ovvero risaldare il chipset se si ha accesso a una stazione di saldatura a infrarossi al prezzo di un'auto, o semplicemente sostituire la scheda madre ).

Per capire cosa può fare un tale rootkit, è necessario valutare cosa rende possibile eseguire il codice in un ambiente UEFI BIOS. Dì, nella modalità più privilegiata del processore: SMM. Tale rootkit può avere le seguenti proprietà:

• essere eseguito in parallelo con il sistema operativo (è possibile configurare l'elaborazione generando un interrupt SMI, che verrà attivato da un timer);
• avere tutti i vantaggi di essere in modalità SMM (pieno accesso al contenuto della RAM e delle risorse hardware, segretezza dal sistema operativo);
• Il codice rootkit può essere crittografato e decrittografato quando viene avviato in modalità SMM. Qualsiasi dato disponibile solo in modalità SMM può essere utilizzato come chiave di crittografia. Ad esempio, un hash da un insieme di indirizzi in SMRAM. Per ottenere questa chiave, dovrai entrare nell'SMM. E questo può essere fatto in due modi. Trova l'RCE nel codice SMM e sfruttalo, oppure aggiungi il tuo modulo SMM al BIOS, il che è impossibile, poiché abbiamo abilitato Boot Guard.

Pertanto, questa vulnerabilità consente a un utente malintenzionato di:

• creare un rootkit nascosto e inamovibile di scopo sconosciuto nel sistema;
• esegui il tuo codice su uno dei core del chipset all'interno del SoC Intel, ovvero su Intel ISH (dai un'occhiata più da vicino all'immagine).

Sebbene le capacità del sottosistema Intel ISH non siano state ancora esplorate, sembra essere un interessante vettore di attacco contro Intel ME.

risultati

1. Lo studio ha fornito una descrizione tecnica del funzionamento della tecnologia Intel Boot Guard. Meno un paio di segreti nel modello di sicurezza attraverso l'oscurità di Intel.
2. Viene presentato uno scenario di attacco che consente di creare un rootkit inamovibile nel sistema.
3. Abbiamo visto che i moderni processori Intel sono in grado di eseguire molto codice proprietario anche prima dell'avvio del BIOS.
4. Le piattaforme con architettura Intel 64 stanno diventando sempre meno adatte all'esecuzione di software libero: verifica hardware, un numero crescente di tecnologie e sottosistemi proprietari (tre core nel chipset SoC: x86 ME, x86 ISH e ARC PMC).

Fattori attenuanti

I fornitori che lasciano intenzionalmente aperta la modalità di produzione dovrebbero assolutamente chiuderla. Finora stanno solo chiudendo gli occhi e i nuovi sistemi Kaby Lake lo dimostrano.

Gli utenti possono disabilitare Intel BG sui propri sistemi (che sono interessati dalla vulnerabilità descritta) eseguendo lo strumento di programmazione Flash con l'opzione -closemnf. Innanzitutto, dovresti assicurarti (usando MEinfo) che la configurazione di Intel BG nella regione ME preveda esattamente la disattivazione di questa tecnologia dopo la programmazione in FPF.

Fonte: habr.com