🥇 Scaricà fiduciale di Schrödinger. Intel Boot Guard

Avemu prupostu di falà à u livellu bassu di novu è parlemu di a sicurità di e plataforme di l'informatica compatibili cù firmware x86. Questa volta, l'ingredientu principale di a ricerca hè Intel Boot Guard (ùn deve esse cunfunditu cù Intel BIOS Guard!) - una tecnulugia di boot di fiducia BIOS supportata da hardware chì un venditore di sistema di computer pò attivà o disattivà permanentemente in a fase di produzzione. Ebbè, avemu digià cunnisciutu a ricetta di ricerca: sottili taglià l'implementazione di sta tecnulugia da ingegneria inversa, discrìviri a so architettura, riempia cù dettagli senza documentu, staghjunate cù vettori d'attaccu à tastà è mischjà. Aghjunghjemu u focu cù una storia nantu à cumu un bug clonatu in a produzzione di parechji venditori per anni permette à un putenziale attaccante di utilizà sta tecnulugia per creà un rootkit oculatu chì ùn pò micca esse eliminatu (ancu da un programatore) in u sistema.

Per via, l'articulu hè basatu annantu à i rapporti "On Guard for Rootkits: Intel BootGuard" da a cunferenza. ZeroNights 2016 è 29a riunione DefCon Russia (i dui presentazioni ccà).

Firmware per una piattaforma di computer cù architettura Intel 64

Per principià, rispondemu à a quistione: chì hè u firmware di una piattaforma di computer muderna cù l'architettura Intel 64? Di sicuru, UEFI BIOS. Ma sta risposta ùn serà micca precisa. Fighjemu a figura, chì mostra a versione desktop (laptop) di sta architettura.

A basa hè u ligame:

Processor (CPU, Central Processing Unit), chì, in più di i core principali, hà un core gràficu integratu (micca in tutti i mudelli) è un controller di memoria (IMC, Integrated Memory Controller);
Chipset (PCH, Platform Controller Hub), chì cuntene diversi controller per interagisce cù i dispositi periferici è gestisce i sottosistemi. Frà elli hè u famusu Intel Management Engine (ME), chì hà ancu un firmware (firmware Intel ME).

Laptops, in più di u sopra, necessitanu un controller integratu (ACPI EC, Advanced Control and Power Interface Embedded Controller), chì hè rispunsevuli di u funziunamentu di u sottosistema di putenza, touchpad, keyboard, Fn keys (luminosità di u screnu, volume di sonu, teclatu). retroilluminazione, etc.) è più. È hà ancu u so propiu firmware.

Dunque, a cumminazzioni di u firmware sopra hè u firmware di a piattaforma di l'informatica (firmware di u sistema), chì hè guardatu in una memoria flash SPI cumuna. Per chì l'utilizatori di sta memoria ùn si cunfondenu induve qualchissia si trova, u cuntenutu di sta memoria hè divisu in e seguenti regioni (cum'è mostra in a figura):

UEFI BIOS;
Firmware ACPI EC (una regione separata apparsu cù a microarchitettura di u processore Skylake (2015), ma in u salvaticu ùn avemu micca vistu ancu esempi di u so usu, perchè u firmware di u controller integratu hè sempre parte di u BIOS UEFI);
firmware Intel ME;
cunfigurazione (indirizzu MAC, etc.) di l'adattatore di rete GbE (Gigabit Ethernet) integratu;
descriptori flash - a regione principale di a memoria flash, chì cuntene punters à altre regioni, è ancu permessi per accede à elli.

A differenziazione di l'accessu à e regioni (in cunfurmità cù i permessi specificati) hè trattatu da u maestru di l'autobus SPI - u controller SPI integratu in u chipset, attraversu quale si accede à sta memoria. Se i permessi sò stabiliti à i valori cunsigliati (per ragioni di sicurezza) da Intel, allora ogni utilizatore di u flash SPI hà accessu sanu (lettura / scrittura) solu à a so regione. U restu hè o solu lettura o inaccessibile. Fattu cunnisciutu: in parechji sistemi, u CPU hà un accessu sanu à u UEFI BIOS è GbE, l'accessu di leghje solu à descriptori flash, è micca accessu à a regione Intel ME in tuttu. Perchè parechji è micca tutti ? Ciò chì hè cunsigliatu hè facultativu. Vi diciaremu più tardi in l'articulu.

Meccanismi per a prutezzione di u firmware di una piattaforma di computer da a mudificazione

Ovviamente, u firmware di una piattaforma di l'informatica deve esse prutetta da un eventuale cumprumissu, chì permetterà à un putenziale attaccante di guadagnà un postu in questu (sopravvive à l'aghjurnamenti / reinstallazione di u SO), eseguisce u so codice in i modi più privilegiati, etc. E delimità l'accessu à e regioni di memoria flash SPI, sicuru, ùn hè micca abbastanza. Per quessa, diversi miccanismi specifichi per ogni ambiente di esecutivu sò usati per prutege u firmware da mudificazioni.

Allora, u firmware Intel ME hè firmatu per u cuntrollu di l'integrità è l'autenticità, è hè verificatu da u controller ME ogni volta chì hè caricatu in a memoria ME UMA. Stu prucessu di verificazione hè digià statu discutitu da noi in unu di i articulidedicatu à u sottosistema Intel ME.

È ACPI EC firmware, in regula, hè verificatu solu per l'integrità. Tuttavia, a causa di u fattu chì stu binariu hè inclusu in u BIOS UEFI, hè quasi sempre sottumessu à i stessi miccanismi di prutezzione chì u BIOS UEFI usa. Parlemu di elli.

Sti miccanismi ponu esse divisu in dui categurie.

Prutezzione di scrittura à a regione UEFI BIOS

Prutezzione fisica di u cuntenutu di a memoria flash SPI cù un jumper di prutezzione di scrittura;
Prutezzione di a prughjezzione di a regione UEFI BIOS in u spaziu di l'indirizzu CPU utilizendu i registri PRx di u chipset;
Bloccu i tentativi di scrive à a regione UEFI BIOS generendu è processendu l'interruzzione SMI currispundente mettendu i bit BIOS_WE / BLE è SMM_BWP in i registri di chipset;
Una versione più avanzata di sta prutezzione hè Intel BIOS Guard (PFAT).

In più di sti miccanismi, i venditori ponu sviluppà è implementà e so propiu misure di sicurezza (per esempiu, firmà capsule cù l'aghjurnamenti UEFI BIOS).

Hè impurtante di nutà chì in un sistema specificu (sicondu u venditore), micca tutti i miccanismi di prutezzione di sopra ponu esse applicati, ùn ponu micca esse appiicati in tuttu, o ponu esse implementati in modu vulnerabile. Pudete leghje più nantu à sti miccanismi è a situazione cù a so implementazione in stu articulu. Per quelli chì sò interessati, ricumandemu di leghje tutta a serie di articuli nantu à a sicurità UEFI BIOS da CodeRush.

Verificazione di l'autenticazione UEFI BIOS

Quandu parlemu di tecnulugia di boot di fiducia, u primu chì vene in mente hè Secure Boot. Tuttavia, architetturale, hè pensatu per autentificà cumpunenti esterni à u BIOS UEFI (drivers, loaders, etc.), è micca u firmware stessu.

Dunque, Intel in SoCs cù a microarchitettura di Bay Trail (2012) hà implementatu un hardware Secure Boot non-switchable (Verified Boot), chì ùn hà nunda di fà cù a tecnulugia Secure Boot citata. In seguitu (2013), stu mecanismu hè statu migliuratu è, sottu u nome Intel Boot Guard, hè stata liberata per desktop cù a microarchitettura Haswell.

Prima di descriverà Intel Boot Guard, fighjemu i tempi di runtime in l'architettura Intel 64, chì, in cumbinazione, sò i radichi di a fiducia per questa tecnulugia di boot di fiducia.

Intel CPU

Cap suggerisce chì u processatore hè u principale ambiente di esecutivu in l'architettura Intel 64. Perchè hè ancu a radica di a fiducia? Risulta chì hè u pussessu di i seguenti elementi chì facenu cusì:

Microcode ROM hè una memoria non volatile, non rewritable per almacenà microcode. Hè cresce chì u microcode hè l'implementazione di u sistema di struzzioni di u processatore nantu à l'istruzzioni più simplici. Succede ancu in u microcode bugs. Allora in u BIOS pudete truvà binari cù l'aghjurnamenti di u microcode (sò superposti à u tempu di boot, perchè a ROM ùn pò micca esse soprascritta). U cuntenutu di sti binari hè criptatu, chì complica assai l'analisi (per quessa, u cuntenutu specificu di u microcode hè cunnisciutu solu per quelli chì u sviluppanu), è firmatu per cuntrullà l'integrità è l'autenticità;
Chjave AES per decrypt u cuntenutu di l'aghjurnamenti di microcode;
un hash di a chjave publica RSA chì verifica a firma di l'aghjurnamenti di u microcode;
L'hash di chjave publica RSA, chì verifica a firma di i moduli di codice ACM (Authenticated Code Module) sviluppati da Intel, chì u CPU pò eseguisce prima chì u BIOS principia (ciao microcode) o durante u so funziunamentu, quandu certi avvenimenti si verificanu.

Intel ME

Stu subsistema in u nostru blog hè statu dedicatu две articuli. Ricurdativi chì questu ambiente eseguibile hè basatu annantu à u microcontroller integratu in u chipset è hè u più oculatu è privilegiatu in u sistema.

Malgradu a furtività, Intel ME hè ancu a radica di a fiducia, perchè hà:

ME ROM - memoria non-volatile, non-rewritable (senza un metudu di aghjurnamentu furnitu), chì cuntene u codice di partenza, è ancu l'hash SHA256 di a chjave publica RSA, chì verifica a firma di u firmware Intel ME;
Chjave AES per almacenà infurmazione secreta;
accessu à un inseme di fusibles (FPFs, Field Programmable Fuses) integrati in u chipset per l'almacenamiento permanente di qualchì infurmazione, cumprese l'infurmazioni specificate da u venditore di u sistema di computer.

Intel Boot Guard 1.x

Picculu disclaimer. I numeri di versione di a tecnulugia Intel Boot Guard chì usemu in questu articulu sò arbitrarie è ùn anu micca avè nunda di fà cù a numerazione utilizata in a documentazione Intel interna. Inoltre, l'infurmazioni nantu à l'implementazione di sta tecnulugia datu quì hè stata ottenuta durante l'ingegneria inversa, è ponu cuntene imprecisioni cumparatu cù l'specificazioni per Intel Boot Guard, chì hè improbabile di esse publicata.

Dunque, Intel Boot Guard (BG) hè una tecnulugia di autentificazione UEFI BIOS supportata da hardware. A ghjudicà da a so piccula descrizzione in u libru [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], funziona cum'è una catena di boot di fiducia. È u primu ligame in questu hè u codice di boot (microcode) in u CPU, chì hè attivatu da l'avvenimentu RESET (per ùn esse cunfunditu cù u vettore RESET in u BIOS!). U CPU trova un modulu di codice (Intel BG startup ACM) sviluppatu è firmatu da Intel nantu à a memoria flash SPI, u carica in a so cache, verifica (hè digià nutatu sopra chì u CPU hà un hash di chjave publica chì verifica a firma ACM). ) è principia.

Stu modulu di codice hè rispunsevule per verificà una piccula parte iniziale di u UEFI BIOS - Initial Boot Block (IBB), chì, à u turnu, cuntene a funziunalità per verificà a parte principale di u UEFI BIOS. Cusì, Intel BG permette di verificà l'autenticità di u BIOS prima di inizià u SO (chì pò esse realizatu sottu a tutela di a tecnulugia Secure Boot).

A tecnulugia Intel BG furnisce dui modi di funziunamentu (è unu ùn interferiscenu micca cù l'altru, vale à dì chì i dui modi ponu esse attivati in u sistema, è i dui ponu esse disattivati).

Boot misurata

In u modu Measured Boot (MB), ogni cumpunente di boot (comincendu cù a CPU boot ROM) "misura" u prossimu utilizendu e capacità di u Modulu di Piattaforma Trusted (TPM). Per quelli chì ùn sanu micca, lasciami spiegà.

TPM hà PCR (Registri di cunfigurazione di piattaforma), chì registranu u risultatu di l'operazione di hashing secondu a formula:

Quelli. u valore di PCR attuale dipende da u precedente, è questi registri sò resettati solu quandu u sistema hè RESET.

Cusì, in u modu MB, in un certu puntu in u tempu, i PCR riflettenu un identificatore unicu (dentru à e capacità di l'operazione hash) di u codice o di dati chì sò stati "misurati". I valori PCR ponu esse aduprati in l'operazione di criptografia di qualchi dati (TPM_Seal). Dopu questu, a so decryption (TPM_Unseal) serà pussibule solu se i valori di PCR ùn anu micca cambiatu in u risultatu di a carica (vale à dì, micca un solu cumpunente "misuratu" hè statu mudificatu).

Boot verificatu

A cosa più spaventosa per quelli chì piace à mudificà u BIOS UEFI hè u modu Verified Boot (VB), in quale ogni cumpunente di boot verifica criptograficamente l'integrità è l'autenticità di u prossimu. È in casu di un errore di verificazione, (unu di i seguenti) si trova:

shutdown by timeout da 1 minute à 30 minuti (per chì l'utilizatore hà u tempu di capisce perchè u so urdinatore ùn hè micca avviatu, è, s'ellu hè pussibule, pruvate à restaurà u BIOS);
chjusu immediata (per chì l'utilizatore ùn hà micca tempu di capisce è, in più, di fà);
cuntinuazione di u travagliu cù una faccia dritta (u casu quandu ùn ci hè micca tempu per a sicurità, perchè ci sò cose più impurtanti per fà).

L'scelta di l'azzione dipende da a cunfigurazione Intel BG specificata (vale à dì, nantu à a chjamata pulitica di applicazione), chì hè permanentemente registrata da u venditore di a piattaforma di l'informatica in un almacenamentu apposta - chipset fuses (FPF). Ci deteremu nantu à questu puntu in più detail dopu.

In più di a cunfigurazione, u venditore genera duie chjave RSA 2048 è crea duie strutture di dati (mostra in a figura):

U manifestu di a chjave di a radica di u venditore (KEYM, OEM Root Key Manifest), chì mette u SVN (Security Version Number) di stu manifestu, l'hash SHA256 di a chjave publica di u prossimu manifestu, a chjave publica RSA (vale à dì a parte publica di u manifestu). chjave radica di u venditore) per verificà a firma di stu manifestu è a firma stessa;
U Manifestu IBB (IBBM, Initial Boot Block Manifest), chì mette u SVN di stu manifestu, l'hash SHA256 di l'IBB, a chjave publica per verificà a firma di stu manifestu, è a firma stessa.

L'hash SHA256 di a Chjave Root OEM hè scritta in permanenza à i fusi di chipset (FPF), cum'è a cunfigurazione Intel BG. Se a cunfigurazione Intel BG prevede l'inclusione di sta tecnulugia, da quì à questu sistema solu u pruprietariu di a parte privata di a chjave OEM Root pò aghjurnà u BIOS (vale à dì pudè ricalculate questi manifesti), i.e. venditore.

Quandu fighjate à a stampa, i dubbiti sò subitu nantu à a necessità di una catena di verificazione cusì longa - pudete avè usatu un manifestu. Perchè cumplicà?

In fattu, Intel furnisce cusì à u venditore l'uppurtunità di utilizà diverse chjavi IBB per e diverse linee di prudutti è una cum'è a radica. Se a parte privata di a chjave IBB (chì firma u secondu manifestu) hè filtrata, l'incidentu affettarà solu una linea di produttu è solu finu à chì u venditore genera un novu paru è permette i manifesti ricalculati in a prossima aghjurnamentu di u BIOS.

Ma se a chjave radicali hè cumprumessa (cù u primu manifestu hè firmatu), ùn serà micca pussibule di rimpiazzà, a prucedura di revocazione ùn hè micca furnita. l'hash di a parte publica di sta chjave hè programata in FPF una volta per sempre.

Configurazione Intel Boot Guard

Avà fighjemu un ochju più vicinu à a cunfigurazione Intel BG è u prucessu di a so creazione. Se guardate a tabulazione currispundente in a GUI di u Flash Image Tool da l'Intel System Tool Kit (STK), vi vede chì a cunfigurazione Intel BG include un hash di a parte publica di a chjave radicale di u venditore, un paru di oscure. valori, è cusì. Prufessu Intel BG.

A struttura di stu prufilu:

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, a cunfigurazione Intel BG hè una entità assai flexible. Cunsiderate, per esempiu, a bandiera Force_Boot_Guard_ACM. Quandu hè sguassatu, se u modulu ACM di startup BG nantu à u flash SPI ùn hè micca truvatu, ùn succede micca un boot di fiducia. Serà inaffidabile.

Avemu digià scrittu sopra chì a pulitica di infurzazione per u modu VB pò esse cunfigurata in modu chì, se a verificazione falla, di novu, una scaricamentu micca fiduciale si farà.

Lasciate cose cusì à i venditori...

A GUI di l'utilità furnisce i seguenti profili "pronti":

Numru
Modu
discrizzione

0
No_FVME
A tecnulugia Intel BG disattivata

1
VE
Modu VB attivatu, chjusu per timeout

2
VME
i dui modi sò attivati (VB è MB), chjusu per timeout

3
VM
i dui modi sò attivati, senza spegne u sistema

4
FVE
Modu VB attivatu, arrestu immediata

5
FVME
i dui modi attivati, arrestu immediata

Cum'è digià dettu, a cunfigurazione Intel BG deve esse scritta una volta per tutte da u venditore di u sistema in fusi di chipset (FPF) - un picculu (sicondu l'infurmazioni micca verificate, solu 256 bytes) almacenamiento di informazioni hardware in u chipset, chì pò esse programatu fora. di e facilità di produzzione di Intel (per quessa Campu Programmable fusibili).

Hè grande per almacenà a cunfigurazione perchè:

hà una zona d'almacenamiento di dati programmabile una volta (solu induve a cunfigurazione Intel BG hè scritta);
solu Intel ME pò leghje è prugramma.

Dunque, per stabilisce a cunfigurazione per a tecnulugia Intel BG nantu à un sistema specificu, u venditore fa e seguenti durante a produzzione:

Utilizendu u Flash Image Tool (da Intel STK), crea una maghjina di firmware cù una cunfigurazione Intel BG data cum'è variàbili in a regione Intel ME (u specchiu chjamatu tempurale per FPF);
Utilizendu u Flash Programming Tool (da Intel STK), scrivite sta maghjina à a memoria flash SPI di u sistema è chjude u cusì chjamatu. modu di fabricazione (in questu casu, u cumandamentu currispundente hè mandatu à Intel ME).

In u risultatu di queste operazioni, Intel ME s'impegna à FPF i valori dati da u specchiu per FPF in a regione ME, stabilisce i permessi in i descrittori flash SPI à i valori cunsigliati da Intel (descritti à l'iniziu di u articulu) è fà un RESET di u sistema.

Analisi di Implementazione Intel Boot Guard

Per analizà l'implementazione di sta tecnulugia nantu à un esempiu specificu, avemu verificatu i seguenti sistemi per tracce di a tecnulugia Intel BG:

sistemu
Vita

Gigabyte GA-H170-D3H
Skylake, ci hè sustegnu

Gigabyte GA-Q170-D3H
Skylake, ci hè sustegnu

Gigabyte GA-B150-HD3
Skylake, ci hè sustegnu

MSI H170A Gaming Pro
Skylake, senza supportu

Lenovo Thinkpad 460
Skylake, supportu dispunibule, tecnulugia attivata

Lenovo Yoga 2 Pro
Haswell, senza sustegnu

Lenovo U330p
Haswell, senza sustegnu

"Supportu" significa a presenza di u modulu Intel BG startup ACM, i manifesti citati sopra è u codice currispundente in u BIOS, i.e. implementazioni per l'analisi.

Per esempiu, pigliemu quellu scaricatu da l'uffiziu. L'immagine di u situ di u venditore di a memoria flash SPI per Gigabyte GA-H170-D3H (versione F4).

Intel CPU boot ROM

Prima di tuttu, parlemu di l'azzioni di u processatore se a tecnulugia Intel BG hè attivata.

Ùn era micca pussibule di truvà mostre di u microcode decriptatu, per quessa, cumu l'azzioni descritte quì sottu sò implementate (in microcode o in hardware) hè una quistione aperta. Tuttavia, u fattu chì i prucessori Intel muderni "pònu" fà queste azzioni hè un fattu.

Dopu à esce da u statu RESET, u processatore (in u so spaziu di indirizzu u cuntenutu di a memoria flash hè digià mappatu) trova u FIT (Firmware Interface Table). Truvà hè faciule, u punteru à questu hè scrittu à l'indirizzu FFFF FFC0h.

In questu esempiu, questu indirizzu cuntene u valore FFD6 9500h. Turnendu à questu indirizzu, u processatore vede a tavola FIT, chì u cuntenutu hè divisu in registri. A prima entrata hè l'intestazione di a struttura seguente:

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 qualchì mutivu scunnisciutu, u checksum ùn hè micca sempre calculatu in questi tavulini (u campu hè lasciatu nulu).

L'entrate rimanenti puntanu à diversi binari chì anu da esse analizati / eseguiti prima chì u BIOS sia eseguitu, i.e. prima di passà à u vettore RESET legatu (FFFF FFF0h). A struttura di ogni tali entrata hè a siguenti:

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

U campu EntryType indica u tipu di bloccu chì sta entrata punta. Sapemu di parechji 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
};

Avà hè evidenti chì una di e entrate punta à u locu di u binariu Intel BG startup ACM. A struttura di l'intestazione di stu binariu hè tipica per i moduli di codice sviluppati da Intel (ACM, aghjurnamenti di microcode, 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];
};

U processatore carica stu binariu in u so cache, verifica è lancia.

Intel BG startup ACM

In u risultatu di l'analisi di u travagliu di questu ACM, hè diventatu chjaru chì faci i seguenti:

riceve da Intel ME a cunfigurazione Intel BG scritta à i fusi di chipset (FPF);
trova i manifesti KEYM è IBBM, li verifica.

Per truvà questi manifesti, ACM usa ancu a tavola FIT, chì hà dui tipi di entrate per indicà queste strutture (vede FIT_ENTRY_TYPES sopra).

Fighjemu un ochju più vicinu à i manifesti. In a struttura di u primu manifestu, vedemu parechje custanti oscure, un hash di a chjave publica da u sicondu manifestu, è una chjave OEM Root publica firmata cum'è una 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 verificà a chjave publica di l'OEM Root Key, ricurdemu chì l'hash SHA256 da i fusibles hè utilizatu, chì in questu momentu hè digià ricevutu da Intel ME.

Passemu à u sicondu manifestu. Hè custituitu di trè strutture:

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

U primu cuntene qualchi constanti:

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

U sicondu cuntene l'hash SHA256 di l'IBB è u numeru di descrittori chì descrizanu u cuntenutu di l'IBB (vale à dì da ciò chì l'hash hè calculatu):

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 seguitanu sta struttura, unu dopu l'altru. U so cuntenutu hà u seguente formatu:

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

Hè simplice: ogni descrittore cuntene l'indirizzu / dimensione di un chunk IBB. Cusì, a concatenazione di i blocchi indicati da questi descrittori (in l'ordine di i descrittori stessi) hè IBB. È, in regula, IBB hè una cumminazione di tutti i moduli di e fasi SEC è PEI.

U sicondu manifestu finisci cù una struttura chì cuntene a chjave publica IBB (verificata da l'hash SHA256 da u primu manifestu) è a firma di stu manifestu:

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

Allora, ancu prima di l'iniziu di l'esekzione UEFI BIOS, u processatore lanciarà ACM, chì verificarà l'autenticità di u cuntenutu di e sezioni cù u codice di fase SEC è PEI. In seguitu, u processatore esce da l'ACM, si move nantu à u vettore RESET, è cumencia à eseguisce u BIOS.

A partizione verificata PEI deve cuntene un modulu chì verificarà u restu di u BIOS (codice DXE). Stu modulu hè digià sviluppatu da IBV (Independent BIOS Vendor) o da u vinditore di u sistema stessu. Perchè Solu i sistemi Lenovo è Gigabyte sò stati à a nostra dispusizione è avè u supportu Intel BG, cunsideremu u codice estratto da questi sistemi.

Modulu UEFI BIOS LenovoVerifiedBootPei

In u casu di Lenovo, turnò à esse u modulu LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, sviluppatu da Lenovo.

U so travagliu hè di circà (per GUID) una tavola hash per u DXE è verificate u 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;
};

Modulu UEFI BIOS BootGuardPei

In u casu di Gigabyte, hè statu u modulu BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, sviluppatu da AMI, è dunque presente in ogni BIOS AMI cù supportu Intel BG.

U so algoritmu di funziunamentu hè un pocu sfarente, però, si riduce à u listessu:

int bootMode = EFI_PEI_SERVICES->GetBootMode();

if (bootMode != BOOT_ON_S3_RESUME &&
    bootMode != BOOT_ON_FLASH_UPDATE &&
    bootMode != BOOT_IN_RECOVERY_MODE)
{
	HOB* h = CreateHob();
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	WriteHob(&h, VerifyDxe());
	return h;
}

A tavola hash {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} chì cerca hà u formatu seguente:

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

Parlemu brevemente di un'altra implementazione di Intel Boot Guard, chì hè stata truvata in un sistema più recente basatu annantu à Intel SoC cù microarchitettura Apollo Lake - ASRock J4205-IT.

Ancu s'è sta versione serà aduprata solu in SoCs (i novi sistemi cù a microarchitettura di u processore Kaby Lake cuntinueghjanu à aduprà Intel Boot Guard 1.x), hè di grande interessu à esplorà una nova opzione di architettura per e plataforme basate in Intel SoCs, chì hà vistu tangibile. cambiamenti, per esempiu:

E regioni BIOS è Intel ME (o piuttostu Intel TXE, secondu a terminologia Intel SoC) sò avà una regione IFWI;
ancu se Intel BG hè stata attivata nantu à a piattaforma, strutture cum'è FIT, KEYM, IBBM ùn sò micca stati truvati in memoria flash;
in più di i nuclei TXE è ISH (x86), un terzu core (di novu ARC, per via) hè statu aghjuntu à u chipset - PMC (Power Management Controller), assuciatu à assicurà l'operabilità di u sottosistema di putere è u monitoraghju di u rendiment.

U cuntenutu di a nova regione IFWI hè un inseme di i seguenti moduli:

Bias
nomu
discrizzione

0000 2000 ore
SMIP
qualchì cunfigurazione di a piattaforma, firmata da u venditore

0000 6000 ore
RBEP
Sezione di codice di firmware Intel TXE, x86, firmata da Intel

0001 0000 ore
PMCP
sezione codice firmware Intel PMC, ARC, firmata da Intel

0002 0000 ore
FTPR
Sezione di codice di firmware Intel TXE, x86, firmata da Intel

0007B000h
UCOD
L'aghjurnamenti di u microcode CPU firmatu da Intel

0008 0000 ore
IBBP
UEFI BIOS, fasi SEC/PEI, x86, firmatu da u venditore

0021 8000 ore
ISHC
sezione di codice di u firmware Intel ISH, x86, firmatu da u venditore

0025 8000 ore
NFTP
Sezione di codice di firmware Intel TXE, x86, firmata da Intel

0036 1000 ore
L'IUNP
hè scunnisciutu

0038 1000 ore
OBBP
UEFI BIOS, fase DXE, x86, senza firma

Durante l'analisi di u firmware TXE, hè diventatu evidenti chì dopu à RESET, TXE mantene u processatore in questu statu finu à chì prepara u cuntenutu basu di u spaziu di indirizzu per u CPU (FIT, ACM, RESET vector ...). Inoltre, TXE mette sta dati in a so SRAM, dopu chì furnisce temporaneamente u processatore cù accessu quì è "libera" da RESET.

In guardia di i rootkits

Ebbè, avà andemu à u "caldo". Avemu scupertu una volta chì in parechji sistemi, i descrittori flash SPI anu permessi per accede à e regioni di memoria flash SPI per chì tutti l'utilizatori di sta memoria ponu scrive è leghje ogni regione. Quelli. certamente nò.

Dopu avè verificatu cù l'utilità MEinfo (da Intel STK), avemu vistu chì u modu di fabricazione in questi sistemi ùn era micca chjusu, per quessa, i fusi di chipset (FPF) sò stati lasciati in un statu indeterminatu. Iè, Intel BG ùn hè nè attivatu nè disattivatu in tali casi.

Parlemu di i seguenti sistemi (in quantu à Intel BG è ciò chì serà descrittu dopu in l'articulu, parlemu di sistemi cù microarchitettura di processore Haswell è più altu):

tutti i prudutti Gigabyte;
tutti i prudutti MSI;
21 mudelli di laptop Lenovo è 4 mudelli di servitori Lenovo.

Di sicuru, avemu infurmatu a scuperta à questi venditori, è ancu à Intel.

Risposta adeguata seguita solu da Lenovochì ricunnosce u prublema è hà liberatu un patch.

Gigabyte Sembra chì anu accettatu l'infurmazioni nantu à a vulnerabilità, ma ùn anu micca cummentatu in ogni modu.

A cumunicazione cun MSI cumplettamente stallati à a nostra dumanda di mandà a nostra chjave PGP publica (per mandà un avvisu di sicurezza criptata). Anu dichjaratu chì "sò un fabricatore di hardware è ùn fabricanu micca e chjave PGP".

Ma più à u puntu. Siccomu i fusi sò lasciati in un statu indefinitu, l'utilizatori (o l'attaccante) ponu programà elli stessu (u più difficiule hè truvà Intel STK). Questu hè bisognu di i seguenti passi.

1. Boot in Windows OS (in generale, i passi descritti quì sottu ponu ancu esse fatti da sottu Linux, se sviluppate un analogu di Intel STK per u SO desideratu). Utilizendu l'utilità MEinfo, assicuratevi chì i fusibili di stu sistema ùn sò micca programati.

2. Leghjite u cuntenutu di a memoria flash utilizendu u Strumentu di Programmazione Flash.

3. Apertura l'imaghjina di lettura utilizendu qualsiasi strumentu di edizione di u BIOS UEFI, fate i cambiamenti necessarii (implementà un rootkit, per esempiu), create / edite e strutture KEYM è IBBM esistenti in a regione ME.

A parte publica di a chjave RSA hè evidenziata in a stampa, l'hash di quale serà programatu in i fusi di chipset cù u restu di a cunfigurazione Intel BG.

4. Utilizendu u Flash Image Tool, custruite una nova maghjina di firmware (impostendu a cunfigurazione Intel BG).

5. Scrivite una nova maghjina per lampassi cù u Flash Programming Tool, verificate cù MEinfo chì a regione ME cuntene avà a cunfigurazione Intel BG.

6. Aduprate u Flash Programming Tool per chjude u modu di fabricazione.

7. U sistema riavviarà, dopu chì, utilizendu MEinfo, pudete verificà chì i FPF sò avà programati.

Queste azzioni навсегда attivate Intel BG nantu à stu sistema. Serà impussibile annullà l'azzione, chì significa:

solu u pruprietariu di a parte privata di a chjave radicali (vale à dì quellu chì hà attivatu Intel BG) puderà aghjurnà u UEFI BIOS in questu sistema;
se rinviate u firmware originale à stu sistema, per esempiu, utilizendu un programatore, ùn sarà ancu accende (una cunsequenza di a pulitica di infurzazioni in casu d'errore di verificazione);
per sbarazzarsi di un tali UEFI BIOS, avete bisognu di rimpiazzà u chipset cù FPFs programati cù un "pulitu" (vale à dì risolve u chipset se avete accessu à una stazione di saldatura infrared à u prezzu di una vittura, o solu rimpiazzà a scheda madre). ).

Per capisce ciò chì un tali rootkit pò fà, avete bisognu di valutà ciò chì permette di eseguisce u vostru codice in un ambiente UEFI BIOS. Dì, in u modu più privilegiatu di u processatore - SMM. Un tali rootkit pò avè e seguenti proprietà:

esse eseguitu in parallelu cù u SO (pudete cunfigurà u processu generendu una interruzzione SMI, chì serà attivata da un timer);
avè tutti i vantaghji di esse in modu SMM (accessu cumpletu à u cuntenutu di RAM è risorse hardware, sicretu da u SO);
U codice rootkit pò esse criptatu è decifratu quandu hè lanciatu in modu SMM. Ogni dati dispunibuli solu in u modu SMM pò esse usatu cum'è chjave di criptografia. Per esempiu, un hash da un settore di indirizzi in SMRAM. Per uttene sta chjave, avete bisognu di cullà in u SMM. È questu pò esse fattu in dui maneri. Truvate u RCE in u codice SMM è sfruttate, o aghjunghje u vostru propiu modulu SMM à u BIOS, chì hè impussibile, postu chì avemu attivatu Boot Guard.

Cusì, sta vulnerabilità permette à un attaccu di:

creà un rootkit nascostu, unremovable di scopu scunnisciutu in u sistema;
eseguite u vostru codice nantu à unu di i core di chipset in l'Intel SoC, à dì, nantu à l'Intel ISH (fighjate più attente à a stampa).

Ancu s'è e capacità di u subsistema Intel ISH ùn sò micca stati ancu esplorati, pare chì hè un vettore d'attaccu interessante contru Intel ME.

scuperti

U studiu hà datu una descrizzione tecnica di cumu funziona a tecnulugia Intel Boot Guard. Minus un paru di sicreti in a sicurità di Intel attraversu u mudellu di oscurità.
Un scenariu d'attaccu hè presentatu chì permette di creà un rootkit unremovable in u sistema.
Avemu vistu chì i prucessori Intel muderni sò capaci di eseguisce assai codice pruprietariu ancu prima chì u BIOS principia.
E piattaforme cù l'architettura Intel 64 sò diventate sempre menu adattate per l'esecuzione di software liberu: verificazione di hardware, un numeru crescente di tecnulugii proprietarii è sottosistemi (trè nuclei in u chipset SoC: x86 ME, x86 ISH è ARC PMC).

Mitigazioni

I venditori chì lascianu intenzionalmente u modalità di fabricazione aperta duveranu definitivamente chjude. Finu à avà, sò solu chjude l'ochji è i novi sistemi Kaby Lake mostranu questu.

L'utilizatori ponu disattivà Intel BG in i so sistemi (chì sò affettati da a vulnerabilità descritta) eseguendu u Flash Programming Tool cù l'opzione -closemnf. Prima, duvete assicuratevi (usendu MEinfo) chì a cunfigurazione di Intel BG in a regione ME furnisce esattamente disattivà sta tecnulugia dopu a prugrammazione in FPF.

Source: www.habr.com

Stivali di fiducia di Schrödinger. Intel Boot Guard