Důvěryhodné spouštění Schrödingera. Intel Boot Guard

Navrhujeme se opět ponořit do hlubin a probrat bezpečnost firmware na platformách kompatibilních s x86. Tentokrát je hlavní ingrediencí našeho zkoumání Intel Boot Guard (neplést s Intel BIOS Guard!) – technologie hardwarové podpory důvěryhodného spuštění BIOS, kterou může výrobce počítačového systému trvale aktivovat nebo deaktivovat během výroby. A náš recept na výzkum je nám již znám: pečlivě provést reverzní inženýrství implementace této technologie, popsat její architekturu a obohatit ji nedokumentovanými detaily, dochutit ji útokovými vektory a důkladně promíchat. Přidáme špetku ohně vyprávěním o tom, jak léty replikovaná výrobní chyba u několika výrobců umožňuje potenciálnímu útočníkovi využít tuto technologii k vytvoření v systému neodstranitelného (ani programátorem) skrytého rootkitu.

Mimochodem, základem článku jsou prezentace "Na stráži rootkitů: Intel BootGuard" z konference ZeroNights 2016 a 29. setkání DefCon Russia (obě prezentace zde).

Firmware počítačové platformy s architekturou Intel 64

Nejprve si odpovězme na otázku: co představuje firmware moderní počítačové platformy s architekturou Intel 64? Samozřejmě, UEFI BIOS. Ale taková odpověď nebude úplně přesná. Podívejme se na obrázek, který zobrazuje desktopovou (notebookovou) variantu této architektury.

Základem je spojení:

• Procesoru (CPU, Central Processing Unit), který kromě základních jader obsahuje integrované grafické jádro (ne ve všech modelech) a integrovaný paměťový řadič (IMC, Integrated Memory Controller);
• Čipsetu (PCH, Platform Controller Hub), který obsahuje různé řadiče pro komunikaci s periferie a řízení subsystémů. Mezi nimi se nachází známá Intel Management Engine (ME), která má také své vlastní firmware (Intel ME firmware).

Notebooky, kromě výše uvedeného, předpokládají existenci integrovaného řadiče (ACPI EC, Advanced Control and Power Interface Embedded Controller), který zajišťuje funkčnost subsystému napájení, touchpadu, klávesnice, kláves Fn (jas obrazovky, hlasitost, podsvícení klávesnice atd.) a dalšího. A ten má také svůj vlastní firmware.

Takže soubor výše uvedených firmwarů je firmwarem počítačové platformy (system firmware), který je uložen v sdílené SPI flash paměti. Aby se uživatelé této paměti nezamorili v tom, co patří komu, je obsah této paměti rozdělen do následujících oblastí (jak je znázorněno na obrázku):

• UEFI BIOS;
• firmware ACPI EC (oddělená oblast se objevila s mikroarchitekturou procesoru Skylake (2015), ale v praxi jsme zatím neviděli žádné příklady jejího použití, takže firmware vestavěného kontroléru stále patří do UEFI BIOS);
• firmware Intel ME;
• konfigurace (MAC adresa atd.) vestavěného síťového adaptéru GbE (Gigabit Ethernet);
• Flash Descriptors – hlavní oblast flash paměti, která obsahuje ukazatele na ostatní oblasti a také povolení k jejich přístupu.

Omezením přístupu k oblastem (v souladu se stanovenými povoleními) se zabývá master sběrnice SPI – vestavěný v chipsetu SPI kontrolér, skrze který se provádí přístup k této paměti. Pokud jsou povolení nastavena na doporučené (z hlediska bezpečnosti) hodnoty společnosti Intel, má každý uživatel SPI flash paměti plný přístup (čtení/zápis) pouze ke své oblasti. Ostatní oblasti jsou buď dostupné pouze pro čtení, nebo nedostupné. Známý fakt: na mnoha systémech má CPU plný přístup k UEFI BIOS a GbE, přístup pouze ke flash popisovačům a k oblasti Intel ME není vůbec žádný přístup. Proč na mnoha, a ne na všech? Co je doporučeno, nemusí být nutně závazné. Více se o tom dočtete v dalším článku.

Mechanismy ochrany firmwaru počítačové platformy před modifikacemi

Je zřejmé, že firmware počítačové platformy by měl být chráněn před možnou kompromitací, která by umožnila potenciálnímu útočníkovi se v něm usadit (přežít aktualizace/přeinstalace OS), vykonávat svůj kód v nejprivilegovanějších režimech atd. A omezení přístupu k oblastem SPI flash paměti samozřejmě nestačí. Proto se pro ochranu firmwaru před modifikacemi používají různé mechanismy specifické pro každé prostředí provádění.

Takže firmware Intel ME je podepsán pro kontrolu integrity a autenticity a je kontrolován ME kontrolérem při každém jeho načtení do paměti ME UMA. Tento proces verifikace jsme již zmiňovali v jednom z článků, věnované subsystému Intel ME.

A firmware ACPI EC se obvykle kontroluje pouze na integritu. Nicméně, vzhledem k tomu, že tento binární kód je součástí UEFI BIOS, na něj téměř vždy platí stejné mechanismy ochrany, jaké používá UEFI BIOS. O těchto mechanismusích si povíme.

Tyto mechanismy lze rozdělit do dvou kategorií.

Ochrana před zápisem do regionu UEFI BIOS

1. Fyzická ochrana obsahu SPI flash paměti pomocí write-protect jumperu;
2. Ochrana projekce regionu UEFI BIOS v adresním prostoru CPU pomocí registrů PRx čipsetu;
3. Zablokování pokusů o zápis do regionu UEFI BIOS generováním a zpracováním příslušného přerušení SMI nastavením bitů BIOS_WE/BLE a SMM_BWP v registrech čipsetu;
4. Pokročilejší varianta takové ochrany – Intel BIOS Guard (PFAT).

Kromě těchto mechanismů mohou dodavatelé vyvíjet a aplikovat vlastní bezpečnostní opatření (například podepisování kapslí s aktualizacemi UEFI BIOS).

Je důležité poznamenat, že na konkrétním systému (závisí na dodavateli) nemusí být použity všechny výše uvedené ochranné mechanismy, mohou být všechny vůbec nepoužity, nebo mohou být implementovány zranitelně. Více o těchto mechanismech a o situaci s jejich implementací si můžete přečíst v tomto článku. Těm, kteří mají zájem, doporučujeme prostudovat celý cyklus článků o bezpečnosti UEFI BIOS od CodeRush.

Ověření pravosti UEFI BIOS

Když mluvíme o technologiích důvěryhodného spuštění, první, co nás napadne, je Secure Boot. Nicméně, architektonicky je určen pro ověřování pravosti externích komponentů, vztahujících se k UEFI BIOS, (ovladačů, bootloaderů atd.), a ne samotného firmwaru.

Proto společnost Intel ve SoC s mikroarchitekturou Bay Trail (2012) zrealizovala hardwarový nevypínatelný Secure Boot (Verified Boot), který nemá nic společného s výše zmíněnou technologií Secure Boot. Později (2013) byl tento mechanismus vylepšen a pod názvem Intel Boot Guard byl vydán pro desktopové počítače s mikroarchitekturou Haswell.

Před popisem Intel Boot Guard si ujasníme prostředí vykonávání v architektuře Intel 64, které jsou zároveň kořeny důvěry pro tuto technologii důvěryhodného spuštění.

Intel CPU

Kép naznačuje, že procesor je hlavním prostředím vykonávání v architektuře Intel 64. Proč je on tímto kořenem důvěry? Ukazuje se, že tímto ho činí vlastnictví následujících prvků:

• Microcode ROM — paměť s nízkou spotřebou energie, neprogramovatelná, určená k ukládání mikrokódu. Mikrokód se považuje za implementaci strojového kódu procesoru na jednoduchých instrukcích. I mikrokód může obsahovat chyby. V BIOSu lze nalézt binární soubory s aktualizacemi mikrokódu (načítají se při spuštění, protože ROM nelze přepsat). Obsah těchto binárních souborů je šifrovaný, což výrazně ztěžuje analýzu (proto je konkrétní obsah mikrokódu znám pouze těm, kteří ho vyvíjejí), a je podepsán pro zajištění integrity a autenticity;
• AES klíč pro dešifrování obsahu aktualizací mikrokódu;
• hash veřejného klíče RSA, kterým se kontroluje podpis aktualizací mikrokódu;
• hash veřejného klíče RSA, kterým se kontroluje podpis kódových modulů ACM (Authenticated Code Module) vyvinutých společností Intel, které procesor může spouštět před zahájením spuštění BIOSu (pozdrav mikrokódu) nebo během jeho práce, při vzniku určitých událostí.

Intel ME

Této podsystemě jsme v našem blogu věnovali dokonce dva na stránkách Maven Apache Project. Připomeňme, že toto spustitelné prostředí je založeno na mikrokontroléru vestavěném do čipové sady a je nejskrytější a nejprivilegovanější v systému.

I přes svou skrytost je Intel ME také kořenem důvěry, protože má:

• ME ROM — paměť s nízkou spotřebou energie, neprogramovatelná (neexistuje způsob aktualizace), obsahující spouštěcí kód, stejně jako SHA256 hash veřejného klíče RSA, kterým se kontroluje podpis firmwaru Intel ME;
• AES klíč pro ukládání tajných informací;
• přístup k integrované čipové sadě fúzí (FPFs, Field Programmable Fuses) pro trvalé ukládání určitých informací, včetně těch, které určil výrobce počítačového systému.

Intel Boot Guard 1.x

Malá poznámka. Čísla verzí technologie Intel Boot Guard, kterými se v tomto článku zabýváme, jsou podmíněná a nemusí mít nic společného s číslováním, které se používá ve vnitřní dokumentaci společnosti Intel. Navíc uvedené informace o implementaci této technologie byly získány během reverzního inženýrství a mohou obsahovat nepřesnosti ve srovnání se specifikací Intel Boot Guard, která pravděpodobně nikdy nebude zveřejněna.

Intel Boot Guard (BG) je hardwarově podporovaná technologie pro ověřování autentičnosti UEFI BIOS. Podle jejího stručného popisu v knize [Platform Embedded Security Technology Revealed, kapitola Boot with Integrity, or Not Boot], funguje jako řetězec důvěryhodného bootování. Prvním článkem v tomto řetězci je bootovací kód (mikrokód) uvnitř CPU, který se aktivuje při události RESET (nemíchat s RESET vektorem v BIOSu!). CPU najde na SPI flash paměti vytvořený a podepsaný kódový modul od společnosti Intel (Intel BG startup ACM), načte jej do své cache, ověří (jak bylo zmíněno výše, CPU má hash veřejného klíče, kterým se kontroluje podpis ACM) a spustí.

Tento kódový modul je zodpovědný za ověření malé startovní části UEFI BIOS — Initial Boot Block (IBB), která obsahuje funkcionalitu pro ověření hlavní části UEFI BIOS. Intel BG tak umožňuje zajistit autentičnost BIOSu před načtením operačního systému (který může běžet pod dohledem technologie Secure Boot).

Technologie Intel BG předpokládá dva režimy práce (přičemž jeden nezabraňuje druhému, takže oba režimy mohou být ve systému zapnuty, nebo mohou být oba vypnuty).

Measured Boot

V režimu Measured Boot (MB) každý bootovací komponent (počínaje CPU boot ROM) "měří" následující pomocí schopností TPM (Trusted Platform Module). Pro ty, kteří nejsou obeznámeni, vysvětlíme.

TPM má PCR (Platform Configuration Registers), do kterých se zapisují výsledky operace hashování podle vzorce:

Tedy aktuální hodnota PCR závisí na předchozí, přičemž tyto registry se vymažou pouze při RESETu systému.

V režimu MB tedy v určitém okamžiku PCR odrážejí unikátní (v rámci možností operace hashování) identifikátor kódu nebo dat, která byla "změřena". Hodnoty PCR mohou být použity při operaci šifrování některých dat (TPM_Seal). Následně bude jejich dešifrování (TPM_Unseal) možné pouze v případě, že hodnoty PCR v důsledku bootování nezměnily (tj. žádná "měřená" komponenta nebyla modifikována).

Verified Boot

Nejhorší pro ty, kteří rádi modifikují UEFI BIOS, je režim Verified Boot (VB), při kterém každý bootovací komponent kryptograficky kontroluje integritu a autentičnost následujícího. V případě chyby ověření dojde k (jednomu z):

• vypnutí po uplynutí 1 minuty až 30 minut (aby uživatel pochopil, proč se mu počítač nenačítá, a pokud je to možné, pokusil se obnovit BIOS);
• okamžité vypnutí (aby uživatel nic nepochopil a ani nic nezvládl);
• pokračování práce s klidnou tváří (situace, kdy na bezpečnost není čas, protože jsou důležitější záležitosti).

Volba akce závisí na nastavené konfiguraci Intel BG (konkrétně na tzv. enforcement policy), která je trvale zapisována dodavatelem počítačové platformy do speciálně určeného úložiště - pojistkových čipů (FPF). O tomto bodě se podrobněji zmíníme později.

Kromě konfigurace dodavatel generuje dva klíče RSA 2048 a vytváří dvě datové struktury (zobrazené na obrázku):

1. Manifest kořenového klíče dodavatele (KEYM, OEM Root Key Manifest), do kterého jsou vloženy SVN (Security Version Number) tohoto manifestu, SHA256 hash veřejného klíče následujícího manifestu, veřejný klíč RSA (tj. veřejná část kořenového klíče dodavatele) pro ověření podpisu tohoto manifestu a samotný podpis;
2. Manifest IBB (IBBM, Initial Boot Block Manifest), do kterého jsou vloženy SVN tohoto manifestu, SHA256 hash IBB, veřejný klíč pro ověření podpisu tohoto manifestu a samotný podpis.

SHA256 hash veřejného klíče OEM Root Key je trvale zapisován do pojistkových čipů (FPF), stejně jako konfigurace Intel BG. Pokud konfigurace Intel BG zahrnuje zapnutí této technologie, potom od tohoto momentu může na daném systému aktualizovat BIOS (tj. mít možnost přepočítat tyto manifesty) pouze držitel soukromé části OEM Root Key, tj. dodavatel.

Při pohledu na obrázek se ihned objevují pochybnosti o potřebě tak dlouhého řetězce ověřování - mohli bychom přece použít jeden manifest. Proč komplikovat?

Ve skutečnosti tímto způsobem společnost Intel poskytuje dodavateli možnost používat různé klíče IBB pro různé řady svých produktů a jeden - jako kořenový. Pokud unikne soukromá část klíče IBB (kterým je podepsán druhý manifest), incident se dotkne pouze jedné řady produktů a pouze do té doby, než dodavatel vygeneruje novou dvojici a nezahrne přepočítané manifesty v následující aktualizaci BIOS.

Ale pokud bude kompromitován kořenový klíč (kterým je podepsán první manifest), nebude možné jej nahradit, protože procedury pro revokaci nejsou stanoveny, protože hash veřejné části tohoto klíče je naprogramován v FPF-ách jednou provždy.

Konfigurace Intel Boot Guard

Teď se podívejme podrobněji na konfiguraci Intel BG a proces jejího vytváření. Pokud se podíváte na odpovídající kartu v GUI nástroje Flash Image Tool v sadě Intel System Tool Kit (STK), můžete si všimnout, že konfigurace Intel BG zahrnuje hash veřejné části kořenového klíče dodavatele, pár nejasných hodnot a tzv. profil Intel BG.

Struktura tohoto profilu:

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 – nedělat nic
                                              // 01b – vypnout s časovým limitem
                                              // 11b – okamžité vypnutí
	unsigned long : 26;
};

Obecně vzato, konfigurace Intel BG je velmi flexibilní entita. Zvažme například příznak Force_Boot_Guard_ACM. Když je deaktivován, pokud modul BG startup ACM na SPI flash paměti nebude nalezen, nebude žádné důvěryhodné zavedení. Bude nespolehlivé.

Jak jsme již dříve zmínili, politika vynucení pro režim VB může být nastavena tak, že při chybě ověření dojde opět k nespolehlivému zavedení.

Nechat takové věci na uvážení dodavatelů...

GUI nástroje předpokládá následující "hotové" profily:

Číslo
Režim
Popis

0
No_FVME
technologie Intel BG je vypnuta

1
VE
je povolen režim VB, vypnutí po časovém limitu

2
VME
jsou povoleny oba režimy (VB a MB), vypnutí po časovém limitu

3
VM
jsou povoleny oba režimy, bez vypnutí systému

4
FVE
je povolen režim VB, okamžité vypnutí

5
FVME
jsou povoleny oba režimy, okamžité vypnutí

Jak již bylo řečeno, konfigurace Intel BG musí být jednou provždy zapsána dodavatelem systému do fúzí čipové sady (FPF-ách) – malé (podle nepotvrzených informací, pouze 256 bajtů) hardwarové úložiště informací uvnitř čipové sady, které může být naprogramováno mimo výrobní kapacity společnosti Intel (proto, právě Field Programmable Fuses).

Je to ideální pro uchovávání konfigurace, protože:

• má oblast pro jednorázové programování pro uchovávání dat (právě sem se zapisuje konfigurace Intel BG);
• číst a programovat jej může pouze Intel ME.

Aby bylo možné nastavit konfiguraci technologie Intel BG na konkrétním systému, výrobce během výroby provádí následující kroky:

1. Pomocí nástroje Flash Image Tool (z Intel STK) vytváří obraz firmwaru s požadovanou konfigurací Intel BG ve formě proměnných uvnitř oblasti Intel ME (tzv. dočasné zrcadlo pro FPF);
2. Pomocí nástroje Flash Programming Tool (z Intel STK) zapíše tento obraz do SPI flash paměti systému a uzavře tzv. výrobní režim (přitom je odeslána příslušná příkaz do Intel ME).

V důsledku těchto operací Intel ME zkomprimuje do FPF zadané hodnoty ze zrcadla pro FPF v oblasti ME, nastaví oprávnění ve SPI flash deskriptorů na doporučené hodnoty společnosti Intel (jak bylo popsáno na začátku článku) a provede RESET systému.

Analýza implementace Intel Boot Guard

Za účelem analýzy realizace této technologie na konkrétním příkladu jsme zkontrolovali následující systémy na přítomnost stop technologie Intel BG:

Systém
Poznámka

Gigabyte GA-H170-D3H
Skylake, podpora existuje

Gigabyte GA-Q170-D3H
Skylake, podpora existuje

Gigabyte GA-B150-HD3
Skylake, podpora existuje

MSI H170A Gaming Pro
Skylake, podpora neexistuje

Lenovo ThinkPad 460
Skylake, podpora existuje, technologie je aktivována

Lenovo Yoga 2 Pro
Haswell, podpora neexistuje

Lenovo U330p
Haswell, podpora neexistuje

Pod „podporou“ se rozumí přítomnost modulu Intel BG startup ACM, výše uvedených manifestů a příslušného kódu v BIOSu, tj. implementace pro analýzu.

Jako příklad vezmeme obraz SPI flash paměti stažený z oficiálního webu výrobce pro Gigabyte GA-H170-D3H (verze F4).

Intel CPU boot ROM

Nejprve se zaměříme na akce procesoru, pokud je technologie Intel BG aktivována.

Vzorky dešifrovaného mikro-kódu nebyly k dispozici, takže způsob, jakým jsou dále popsané akce prováděny (v mikro-kódu nebo hardwarově) – je otevřenou otázkou. Nicméně fakt, že moderní procesory Intel „umí“ provádět tyto akce – je nesporný.

Po vyjití ze stavu RESET procesor (v jehož adresním prostoru je již namapováno obsah flash paměti) najde tabulku FIT (Firmware Interface Table). Je jednoduché ji najít, ukazatel na ni je zapsán na adrese FFFF FFC0h.

V daném příkladu leží na této adrese hodnota FFD6 9500h. Oslovením této adresy procesor vidí tabulku FIT, jejíž obsah je rozdělen do záznamů. První záznam je hlavička následující struktury:

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_   ’
	unsigned long  NumEntries; // včetně záznamu hlavičky FIT
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

Z neznámého důvodu není kontrolní součet v těchto tabulkách vždy spočítán (pole je ponecháno nulové).

Další záznamy odkazují na různé binární soubory, které je nutné poskytnout/analyzovat ještě před spuštěním BIOSu, tedy před přechodem na legacy RESET vektor (FFFF FFF0h). Struktura každého takového záznamu je následující:

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

Pole EntryType naznačuje typ bloku, na který tento záznam odkazuje. Známé jsou nám různé typy:

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

Nyní je jasné, že jeden ze záznamů odkazuje na umístění binárního souboru Intel BG startup ACM. Struktura hlavičky tohoto binárního souboru je typická pro kódové moduly vyvíjené společností Intel (ACM, aktualizace mikro kódu, kódové sekce Intel ME, ...).

typedef struct BG_ACM_HEADER
{
	unsigned short ModuleType;     	// 2
	unsigned short ModuleSubType;  	// 3
	unsigned long  HeaderLength;   	// v dwordech
	unsigned long  : 32;
	unsigned long  : 32;
	unsigned long  ModuleVendor;   	// 8086h
	unsigned long  Date;           	// ve formátu BCD
	unsigned long  TotalSize;      	// v dwordech
	unsigned long  unknown1[6];
	unsigned long  EntryPoint;
	unsigned long  unknown2[16];
	unsigned long  RsaKeySize;     	// v dwordech
	unsigned long  ScratchSize;    	// v dwordech
	unsigned char  RsaPubMod[256];
	unsigned long  RsaPubExp;
	unsigned char  RsaSig[256];
};

Procesor načítá tento binární soubor do své cache, ověřuje ho a spouští.

Intel BG startup ACM

Z analýzy práce tohoto ACM vyplývá, že dělá následující:

• získává od Intel ME konfiguraci Intel BG, zapsanou ve fusech čipové sady (FPF);
• nalezne manifesty KEYM a IBBM, ověří je.

Pro nalezení těchto manifestů ACM také využívá tabulku FIT, ve které jsou vyhrazeny dva typy záznamů pro udávání datové struktury (viz FIT_ENTRY_TYPES výše).

Zastavme se podrobněji u manifestů. Ve struktuře prvního manifestu vidíme několik nejasných konstant, hash veřejného klíče z druhého manifestu a veřejný klíč OEM Root Key s podpisem ve formě vložené struktury:

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

Pro ověření veřejného klíče OEM Root Key se používá SHA256 hash z fusek, který byl v tuto chvíli již získán od Intel ME.

Přejdeme k druhému manifestu. Ten se skládá ze tří struktur:

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

V první – nějaké konstanty:

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

Ve druhé se nachází SHA256 hash IBB a počet deskriptorů, které popisují obsah IBB (tj. to, z čeho se počítá 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;
};

Deskriptory IBB následují za touto strukturou, jeden po druhém. Jejich obsah má následující formát:

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

To je jednoduché: každý deskriptor obsahuje adresu/velikost kusu IBB. Takže konkatenace bloků, na které ukazují tyto deskriptory (v pořadí, v jakém se nacházejí samotné deskriptory) je IBB. A, jak obvykle, IBB je souhrn všech modulů fází SEC a PEI.

Druhý manifest končí strukturou, která obsahuje veřejný klíč IBB (ověřuje se SHA256 hashem z prvního manifestu) a podpis tohoto manifestu:

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

Až do začátku spuštění UEFI BIOS procesor spustí ACM, který ověří autenticitu obsahu sekcí s kódem fází SEC a PEI. Poté procesor vystoupí z ACM, přejde na RESET vektor a začne vykonávat BIOS.

Ověřená PEI sekce musí obsahovat modul, který zkontroluje zbytek BIOS (DXE kód). Tento modul vyvíjí buď IBV (Independent BIOS Vendor), nebo samotný dodavatel systému. Jelikož jsme měli k dispozici a s podporou Intel BG pouze systémy Lenovo a Gigabyte, zaměříme se na kód extrahovaný z těchto systémů.

UEFI BIOS modul LenovoVerifiedBootPei

V případě Lenova se jednalo o modul LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, vyvinutý společností Lenovo.

Jeho úlohou je vyhledat (podle GUID) hash tabulku pro DXE a ověřit DXE.

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

Hash tabulka {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} má následující formát:

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

UEFI BIOS modul BootGuardPei

V případě Gigabyte se jednalo o modul BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, vyvinutý společností AMI, a proto je přítomen v každém AMI BIOS s podporou Intel BG.

Jeho algoritmus fungování je poněkud odlišný, nicméně cíl je stejný:

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

Hash tabulka {389CC6F2-1EA8-467B-AB8A-78E769AE2A15}, kterou hledá, má následující formát:

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

Krátce zmíníme další implementaci Intel Boot Guard, která byla nalezena ve novějším systému založeném na Intel SoC s mikroarchitekturou Apollo Lake — ASRock J4205-IT.

I když tato verze bude aplikována pouze v SoCcích (nové systémy s procesorovou mikroarchitekturou Kaby Lake stále používají Intel Boot Guard 1.x), představuje velký zájem při zkoumání nové varianty architektury pro platformy na Intel SoC, kde došlo k výrazným změnám, například:

• regiony BIOS a Intel ME (přesněji Intel TXE, podle terminologie pro Intel SoC) nyní tvoří jeden region IFWI;
• Ačkoliv byla na platformě zapnuta Intel BG, nebyly ve flash paměti nalezeny struktury jako FIT, KEYM, IBBM;
• Kromě TXE a ISH jader (x86) byla do čipsetu přidána třetí jádro (znovu ARC, mimochodem) – PMC (Power Management Controller), odpovědné za zajištění funkčnosti napájecí podskupiny a monitorování výkonu.

Obsah nového regionu IFWI představuje sadu následujících modulů:

Offset
Jméno
Popis

0000 2000h
SMIP
nějaká konfigurace platformy, podepsáno dodavatelem

0000 6000h
RBEP
kódová část firmwaru Intel TXE, x86, podepsáno Intel

0001 0000h
PMCP
kódová část firmwaru Intel PMC, ARC, podepsáno Intel

0002 0000h
FTPR
kódová část firmwaru Intel TXE, x86, podepsáno Intel

0007 B000h
UCOD
aktualizace mikro-kódu pro CPU, podepsáno Intel

0008 0000h
IBBP
UEFI BIOS, fáze SEC/PEI, x86, podepsáno dodavatelem

0021 8000h
ISHC
kódová část firmwaru Intel ISH, x86, podepsáno dodavatelem

0025 8000h
NFTP
kódová část firmwaru Intel TXE, x86, podepsáno Intel

0036 1000h
IUNP
neznámo

0038 1000h
OBBP
UEFI BIOS, fáze DXE, x86, nepodepsáno

Během analýzy firmwaru TXE se ukázalo, že po RESETu TXE drží procesor v tomto stavu, dokud nepřipraví základní obsah adresního prostoru pro CPU (FIT, ACM, RESET vektor …). TXE umisťuje tato data do své SRAM, poté dočasně umožňuje procesoru přístup a 'uvolňuje' ho z RESETu.

Na stráži proti rootkitům

A nyní přejděme k 'žhavému'. Jednou jsme zjistili, že na mnoha systémech jsou v SPI flash-deskriptorech zapsána oprávnění pro přístup k regionům SPI flash paměti tak, že všichni uživatelé této paměti mohou číst a zapisovat do jakéhokoli regionu. Tedy žádným způsobem.

Po ověření pomocí nástroje MEinfo (z Intel STK) jsme viděli, že výrobní režim na těchto systémech není uzavřen, což znamená, že fúze čipsetu (FPF) byly ponechány v nedefinovaném stavu. Ano, Intel BG v těchto případech není ani zapnut, ani vypnut.

Jedná se o následující systémy (ohledně Intel BG a toho, co bude dále v článku, budeme mluvit o systémech s mikroarchitekturou procesorů Haswell a vyšší):

• všechny výrobky Gigabyte;
• všechny výrobky MSI;
• 21 modelů notebooků Lenovo a 4 modely serverů Lenovo.

Samozřejmě jsme o tomto zjištění informovali tyto dodavatele, stejně jako společnost Intel.

Adekvátní reakce přišla pouze od Lenovo, kteří problém uznali a vydali patch.

Gigabyte se zdá, že informace o zranitelnosti přijali, ale nijak to nekomentovali.

Komunikace s MSI Zcela jsme se zasekli na naší žádosti o zaslání veřejného PGP klíče (abychom jim mohli poslat bezpečnostní doporučení zašifrované). Uvedli, že "jsou výrobcem zařízení a PGP klíče nevyrábějí."

Ale k věci. Protože byly pojistky ponechány v neurčeném stavu, může je uživatel (nebo útočník) naprogramovat sám (nejtěžší je najít Intel STK). K tomu je třeba provést následující kroky.

1. Zavést se do systému Windows (vlastně popsané kroky lze provést i v Linuxu, pokud se vyvine analog Intel STK pro požadovaný OS). Pomocí nástroje MEinfo se ujistit, že pojistky v tomto systému nejsou naprogramovány.

2. Přečíst obsah flash paměti pomocí Flash Programming Tool.

3. Otevřít přečtený obraz pomocí libovolného nástroje pro úpravu UEFI BIOS, provést potřebné změny (např. vložit rootkit), vytvořit/upravit existující struktury KEYM a IBBM v oblasti ME.

Na obrázku je zvýrazněna veřejná část RSA klíče, jejíž hash bude naprogramován do pojistek čipové sady spolu s ostatními konfiguracemi Intel BG.

4. Pomocí Flash Image Tool sestavit nový obraz firmwaru (s nastavením Intel BG).

5. Zapsat nový obraz do flash paměti pomocí Flash Programming Tool, ujistit se pomocí MEinfo, že oblast ME nyní obsahuje konfiguraci Intel BG.

6. Pomocí Flash Programming Tool uzavřít režim manufacturing mode.

7. Systém se restartuje, poté pomocí MEinfo lze zjistit, že FPF-y jsou nyní naprogramovány.

Tyto kroky trvale aktivují Intel BG v tomto systému. Akci nebude možné odvolat, což znamená:

• aktualizovat UEFI BIOS na tomto systému bude moci pouze držitel privátní části kořenového klíče (tj. ten, kdo aktivoval Intel BG);
• pokud se tomuto systému vrátí původní firmware, například pomocí programátoru, ani se nezapne (následek enforcement policy v případě chyby ověření);
• abych se zbavil takového UEFI BIOS, je nutné vyměnit čipovou sadu s naprogramovanými FPF-y za "čistou" (tj. přeletovat čipovou sadu, pokud máte přístup k infrapájecí stanici za cenu automobilu, nebo prostě vyměnit základní desku).

Aby porozuměli tomu, co může takový rootkit způsobit, je třeba ocenit, jak umožňuje spouštění vlastního kódu v prostředí UEFI BIOS. Řekněme, v nejprivilegovanějším režimu procesoru – SMM. Takový rootkit může mít následující vlastnosti:

• může běžet paralelně s OS (je možné nastavit zpracování generováním SMI přerušení, které bude spouštěno podle časovače);
• má všechny výhody, které přináší režim SMM (úplný přístup k obsahu operační paměti a hardwarovým prostředkům, skrytost před OS);
• programový kód rootkitu může být uložen v zašifrované podobě a dešifrován při spuštění v režimu SMM. Jako klíč pro šifrování lze použít jakákoliv data dostupná pouze v režimu SMM. Například hash z množiny adres v SMRAM. K získání tohoto klíče je třeba proniknout do SMM. A to je možné provést dvěma způsoby. Najít RCE v kódu SMM a exploatovat jej, nebo přidat do BIOSu svůj SMM modul, což je nemožné, protože jsme aktivovali Boot Guard.

Tím pádem tato zranitelnost umožňuje útočníkovi:

• vytvořit v systému skrytý, neodstranitelný rootkit neznámého účelu;
• spouštět svůj kód na jednom z jader čipové sady uvnitř Intel SoC, konkrétně na Intel ISH (podívejme se pozorně na obrázek).

Ačkoli možnosti subsystému Intel ISH dosud nejsou prozkoumány, představují zajímavý vektor útoku na Intel ME.

Závěry

1. Výzkum umožnil získat technický popis fungování technologie Intel Boot Guard. Minus pár tajemství v intelovské modelu security through obscurity.
2. Byl předložen scénář útoku, který umožňuje vytvořit v systému neodstranitelný rootkit.
3. Viděli jsme, že moderní procesory Intel jsou schopny spustit spoustu proprietárního kódu ještě před zahájením práce BIOSu.
4. Platformy s architekturou Intel 64 se stávají stále méně vhodnými pro spouštění svobodného softwaru: hardwarová verifikace, rostoucí počet proprietárních technologií a subsystémů (tři jádra v čipsetu SoC: x86 ME, x86 ISH a ARC PMC).

Mitigace

Dodavatelům, kteří úmyslně nechávají manufacturing mode otevřený, by ho měli určitě zavřít. Zatím se pouze zavírají oči a nové systémy Kaby Lake to ukazují.

Uživatelé mohou sami vypnout Intel BG na svých systémech (které jsou citlivé na uvedenou zranitelnost) spuštěním nástroje Flash Programming Tool s parametrem -closemnf. Předtím by měli zajistit (pomocí MEinfo), že konfigurace Intel BG v oblasti ME skutečně umožňuje vypnutí této technologie po naprogramování do FPF.

Zdroj: habr.com