🥇Ověřené stahování Schrödinger. Intel Boot Guard

Navrhujeme sejít opět na nízkou úroveň a mluvit o zabezpečení počítačových platforem kompatibilních s firmwarem x86. Tentokrát je hlavní složkou studie Intel Boot Guard (neplést s Intel BIOS Guard!) – hardwarově podporovaná spouštěcí technologie BIOS, kterou může dodavatel počítačového systému trvale zapnout nebo vypnout ve fázi výroby. Recept na výzkum už známe: implementaci této technologie nakrájejte na tenko pomocí reverzního inženýrství, popište její architekturu, naplňte ji nezdokumentovanými detaily, dochuťte útočnými vektory podle chuti a promíchejte. Přidejme oheň historkou o tom, jak léta klonovaná chyba ve výrobě několika výrobců umožňuje potenciálnímu útočníkovi pomocí této technologie vytvořit skrytý rootkit, který nelze (ani programátorem) ze systému odstranit.

Mimochodem, článek je založen na zprávách „On Guard for Rootkits: Intel BootGuard“ z konference ZeroNights 2016 a 29. setkání DefCon Rusko (obě prezentace zde).

Firmware pro počítačovou platformu s architekturou Intel 64

Pro začátek si odpovězme na otázku: jaký je firmware moderní počítačové platformy s architekturou Intel 64? Samozřejmostí je UEFI BIOS. Ale tato odpověď nebude přesná. Podívejme se na obrázek, který ukazuje desktopovou (notebookovou) verzi této architektury.

Základem je odkaz:

Procesor (CPU, Central Processing Unit), který má kromě hlavních jader vestavěné grafické jádro (ne ve všech modelech) a paměťový řadič (IMC, Integrated Memory Controller);
Čipová sada (PCH, Platform Controller Hub), obsahující různé řadiče pro interakci s periferními zařízeními a správu subsystémů. Mezi nimi je notoricky známý Intel Management Engine (ME), který má také firmware (Intel ME firmware).

Notebooky kromě výše uvedeného vyžadují integrovaný řadič (ACPI EC, Advanced Control and Power Interface Embedded Controller), který zodpovídá za provoz napájecího subsystému, touchpadu, klávesnice, kláves Fn (jas obrazovky, hlasitost zvuku, klávesnice podsvícení atd.) a další. A má i svůj firmware.

Kombinací výše uvedeného firmwaru je tedy firmware počítačové platformy (systémový firmware), který je uložen na společné flash paměti SPI. Aby uživatelé této paměti nebyli zmateni, kde kdo leží, 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 (samostatná oblast se objevila s mikroarchitekturou procesoru Skylake (2015), ale ve volné přírodě jsme zatím neviděli příklady jeho použití, takže firmware vestavěného řadiče je stále součástí UEFI BIOS);
firmware Intel ME;
konfigurace (MAC adresa atd.) vestavěného síťového adaptéru GbE (Gigabit Ethernet);
flash deskriptory - hlavní oblast flash paměti, která obsahuje ukazatele na jiné oblasti a také oprávnění k přístupu k nim.

Rozlišení přístupu do regionů (v souladu se zadanými oprávněními) má na starosti master sběrnice SPI - SPI řadič zabudovaný v čipsetu, přes který se k této paměti přistupuje. Pokud jsou oprávnění nastavena na hodnoty doporučené (z bezpečnostních důvodů) společností Intel, pak má každý uživatel SPI flash plný přístup (čtení/zápis) pouze ke své oblasti. Zbytek je buď pouze pro čtení, nebo nepřístupný. Známý fakt: na mnoha systémech má CPU plný přístup k UEFI BIOS a GbE, přístup pouze pro čtení k deskriptorům flash a vůbec žádný přístup k regionu Intel ME. Proč mnoho a ne všichni? Co je doporučeno, je volitelné. Více vám prozradíme dále v článku.

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

Firmware počítačové platformy by samozřejmě měl být chráněn před možným kompromitováním, které by umožnilo případnému útočníkovi se v něm uchytit (přežít aktualizace/reinstalace OS), spustit svůj kód v nejprivilegovanějších režimech atd. A vymezení přístupu k oblastem flash paměti SPI samozřejmě nestačí. Proto se k ochraně firmwaru před úpravami používají různé mechanismy specifické pro každé prostředí provádění.

Firmware Intel ME je tedy podepsán pro kontrolu integrity a pravosti a je kontrolován řadičem ME pokaždé, když je nahrán do paměti ME UMA. Tento proces ověření jsme již probrali v jednom z článkyvěnované subsystému Intel ME.

A firmware ACPI EC je zpravidla kontrolován pouze z hlediska integrity. Vzhledem k tomu, že tento binární soubor je součástí UEFI BIOS, podléhá téměř vždy stejným ochranným mechanismům, jaké používá UEFI BIOS. Pojďme si o nich povídat.

Tyto mechanismy lze rozdělit do dvou kategorií.

Ochrana proti zápisu do regionu UEFI BIOS

Fyzická ochrana obsahu SPI flash paměti pomocí propojky na ochranu proti zápisu;
Ochrana projekce oblasti UEFI BIOS v adresovém prostoru CPU pomocí registrů PRx čipsetu;
Blokování pokusů o zápis do oblasti UEFI BIOS generováním a zpracováním odpovídajícího přerušení SMI nastavením bitů BIOS_WE / BLE a SMM_BWP v registrech čipové sady;
Pokročilejší verzí této ochrany je Intel BIOS Guard (PFAT).

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

Je důležité si uvědomit, že na konkrétním systému (v závislosti na výrobci) nemusí být všechny výše uvedené ochranné mechanismy aplikovány, nemusí být aplikovány vůbec nebo mohou být implementovány zranitelným způsobem. Více o těchto mechanismech a situaci s jejich implementací si můžete přečíst v tento článek. Zájemcům doporučujeme přečíst si celou sérii článků o zabezpečení UEFI BIOS od CodeRush.

Ověření ověření UEFI BIOS

Když mluvíme o důvěryhodných spouštěcích technologiích, první věc, která vás napadne, je Secure Boot. Architektonicky je však navržen tak, aby ověřoval komponenty mimo systém UEFI BIOS (ovladače, zavaděče atd.), a nikoli samotný firmware.

Intel proto v SoC s mikroarchitekturou Bay Trail (2012) implementoval hardwarově nepřepínatelný Secure Boot (Verified Boot), který nemá nic společného se zmíněnou technologií Secure Boot. Později (2013) byl tento mechanismus vylepšen a pod názvem Intel Boot Guard vydán pro desktopy s mikroarchitekturou Haswell.

Než popíšeme Intel Boot Guard, podívejme se na spouštěcí prostředí v architektuře Intel 64, která v kombinaci tvoří kořeny důvěry pro tuto důvěryhodnou technologii spouštění.

Intel CPU

Cap naznačuje, že procesor je hlavním prováděcím prostředím v architektuře Intel 64. Proč je také kořenem důvěry? Ukazuje se, že je to vlastně držení následujících prvků:

Microcode ROM je energeticky nezávislá, nepřepisovatelná paměť pro ukládání mikrokódu. Předpokládá se, že mikrokód je implementací systému instrukcí procesoru na nejjednodušších instrukcích. Děje se to i v mikrokódu chyby. V BIOSu tedy můžete najít binární soubory s aktualizacemi mikrokódu (při bootování se překrývají, protože ROM nelze přepsat). Obsah těchto binárních souborů je zašifrován, což značně komplikuje analýzu (proto konkrétní obsah mikrokódu zná pouze ten, kdo jej vyvíjí), a podepsaný pro kontrolu integrity a pravosti;
AES klíč pro dešifrování obsahu aktualizací mikrokódu;
hash veřejného klíče RSA, který ověřuje podpis aktualizací mikrokódu;
Hash veřejného klíče RSA, který kontroluje signaturu modulů kódu ACM (Authenticated Code Module) vyvinutých Intelem, které může CPU spustit před spuštěním BIOSu (hello microcode) nebo během jeho provozu, když dojde k nějaké události.

Intel ME

Tomuto podsystému na našem blogu jsme se věnovali dva články. Připomeňme, že toto spustitelné prostředí je založeno na mikrokontroléru zabudovaném do čipové sady a je nejskrytější a nejprivilegovanější v systému.

Navzdory utajení je Intel ME také kořenem důvěry, protože má:

ME ROM - energeticky nezávislá, nepřepisovatelná paměť (neposkytuje se žádná metoda aktualizace), obsahující startovací kód a také hash SHA256 veřejného klíče RSA, který kontroluje podpis firmwaru Intel ME;
AES klíč pro ukládání tajných informací;
přístup k sadě pojistek (FPF, Field Programmable Fuses) integrovaných do čipové sady pro trvalé uložení některých informací, včetně informací specifikovaných dodavatelem počítačového systému.

Intel Boot Guard 1.x

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

Intel Boot Guard (BG) je tedy hardwarově podporovaná technologie ověřování UEFI BIOS. Soudě podle jeho malého popisu v knize [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], funguje jako důvěryhodný zaváděcí řetězec. A první odkaz v něm je spouštěcí kód (mikrokód) uvnitř CPU, který se spouští událostí RESET (neplést s vektorem RESET v BIOSu!). CPU najde kódový modul (Intel BG startup ACM) vyvinutý a podepsaný Intel na SPI flash paměti, načte jej do své mezipaměti, ověří (již bylo uvedeno výše, že CPU má hash veřejného klíče, který ověřuje podpis ACM ) a spustí se.

Tento kódový modul je zodpovědný za ověření malé počáteční části systému UEFI BIOS – Initial Boot Block (IBB), která zase obsahuje funkce pro ověření hlavní části systému UEFI BIOS. Intel BG tedy umožňuje ověřit pravost BIOSu před spuštěním operačního systému (což lze provést pod dohledem technologie Secure Boot).

Technologie Intel BG poskytuje dva režimy provozu (a jeden se neruší s druhým, tj. oba režimy lze v systému povolit a oba deaktivovat).

Měřená bota

V režimu Measured Boot (MB) každá spouštěcí součást (počínaje zaváděcí ROM CPU) „měří“ další s využitím schopností modulu Trusted Platform Module (TPM). Pro ty, kteří nevědí, nech mě to vysvětlit.

TPM má PCR (Platform Configuration Registers), které zaznamenávají výsledek operace hash podle vzorce:

Tito. aktuální hodnota PCR závisí na předchozí, přičemž tyto registry se vynulují pouze při RESETU systému.

V režimu MB tedy v určitém okamžiku PCR odrážejí jedinečný (v rámci možností hašovací operace) identifikátor kódu nebo dat, která byla „naměřena“. Hodnoty PCR lze použít při šifrování některých dat (TPM_Seal) operace. Poté bude jejich dešifrování (TPM_Unseal) možné pouze v případě, že se hodnoty PCR v důsledku načtení nezměnily (tj. nebyla upravena ani jedna „měřená“ složka).

VerifiedBoot

Nejděsivější věcí pro ty, kteří rádi upravují UEFI BIOS, je režim Verified Boot (VB), ve kterém každá spouštěcí komponenta kryptograficky ověřuje integritu a pravost té další. A v případě chyby ověření dojde (jedna z následujících):

vypnutí časovým limitem od 1 minuty do 30 minut (aby měl uživatel čas pochopit, proč se jeho počítač nespustí, a pokud je to možné, pokusil by se obnovit BIOS);
okamžité vypnutí (aby uživatel neměl čas chápat a navíc dělat);
pokračování v práci s rovným obličejem (případ, kdy není čas na bezpečnost, protože jsou důležitější věci na práci).

Volba akce závisí na zadané konfiguraci Intel BG (jmenovitě na tzv. vynucovací politice), která je trvale zaznamenávána dodavatelem počítačové platformy do speciálně navrženého úložiště - pojistek čipové sady (FPF). Tomuto bodu se budeme podrobněji věnovat později.

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

Manifest kořenového klíče dodavatele (KEYM, OEM Manifest Root Key), který vkládá SVN (číslo verze zabezpečení) tohoto manifestu, hash SHA256 veřejného klíče dalšího manifestu, veřejného klíče RSA (tj. veřejné části kořenový klíč dodavatele) k ověření podpisu tohoto manifestu a podpisu samotného;
Manifest IBB (IBBM, Initial Boot Block Manifest), který vkládá SVN tohoto manifestu, hash SHA256 IBB, veřejný klíč pro ověření podpisu tohoto manifestu a samotný podpis.

Hash SHA256 kořenového klíče OEM je trvale zapsán do pojistek čipové sady (FPF), stejně jako konfigurace Intel BG. Pokud konfigurace Intel BG počítá se zahrnutím této technologie, tak od nynějška na tomto systému může aktualizovat BIOS pouze vlastník privátní části OEM Root Key (tedy umět tyto manifesty přepočítat), tzn. prodejce.

Když se podíváte na obrázek, okamžitě vyvstanou pochybnosti o potřebě tak dlouhého ověřovacího řetězce - mohli jste použít jeden manifest. Proč komplikovat?

Ve skutečnosti tak Intel poskytuje prodejci možnost používat různé IBB klíče pro různé produktové řady a jeden jako root. Pokud unikne privátní část klíče IBB (která podepisuje druhý manifest), incident se dotkne pouze jedné produktové řady a pouze do doby, než dodavatel vygeneruje nový pár a povolí přepočítané manifesty v příští aktualizaci BIOSu.

Pokud však dojde ke kompromitaci kořenového klíče (kterým je podepsán první manifest), nebude možné jej nahradit, postup odvolání není poskytován. hash veřejné části tohoto klíče je jednou provždy naprogramován do FPF.

Konfigurace Intel Boot Guard

Nyní se podíváme blíže na konfiguraci Intel BG a proces její tvorby. Pokud se podíváte na odpovídající kartu v GUI nástroje Flash Image Tool ze sady Intel System Tool Kit (STK), všimnete si, že konfigurace Intel BG obsahuje hash veřejné části kořenového klíče dodavatele, pár nejasných hodnoty, a tak dále. 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 – do nothing
                                              // 01b – shutdown with timeout
                                              // 11b – immediate shutdown
	unsigned long : 26;
};

Obecně je konfigurace Intel BG velmi flexibilní. Zvažte například příznak Force_Boot_Guard_ACM. Když je vymazána a není-li nalezen spouštěcí modul ACM BG na SPI flash, neproběhne žádné důvěryhodné spouštění. Bude to nedůvěryhodné.

Již jsme psali výše, že politiku vynucení pro režim VB lze nakonfigurovat tak, že pokud se ověření nezdaří, opět dojde k nedůvěryhodnému stahování.

Nechte takové věci na prodejcích...

GUI nástroje poskytuje následující „hotové“ profily:

číslo
režim
popis

0
Ne_FVME
Technologie Intel BG je zakázána

1
VE
Režim VB povolen, vypnutí po vypršení časového limitu

2
VME
oba režimy jsou povoleny (VB a MB), vypnutí časovým limitem

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

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

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

Jak již bylo zmíněno, konfiguraci Intel BG musí výrobce systému jednou provždy zapsat do pojistek čipové sady (FPF) - malého (podle neověřených informací pouze 256 bajtů) úložiště hardwarových informací uvnitř čipsetu, které lze naprogramovat mimo čipset. výrobních zařízení Intelu (takže proto Programovatelné v terénu pojistky).

Je to skvělé pro ukládání konfigurace, protože:

má jednorázově programovatelnou oblast pro ukládání dat (právě tam, kde je zapsána konfigurace Intel BG);
pouze Intel ME jej umí číst a programovat.

Aby tedy bylo možné nastavit konfiguraci pro technologii Intel BG na konkrétním systému, provede prodejce během výroby následující:

Pomocí utility Flash Image Tool (od Intel STK) se vytvoří obraz firmwaru s danou konfigurací Intel BG jako proměnné uvnitř oblasti Intel ME (tzv. dočasné zrcadlo pro FPF);
Pomocí Flash Programming Tool (od Intel STK) zapíše tento obrázek do SPI flash paměti systému a uzavře tzv. výrobní režim (v tomto případě je odpovídající příkaz odeslán do Intel ME).

V důsledku těchto operací Intel ME zaváže FPF specifikované hodnoty ze zrcadla pro FPF v oblasti ME, nastaví oprávnění v SPI flash deskriptorech na hodnoty doporučené Intelem (popsané na začátku článek) a proveďte RESET systému.

Analýza implementace Intel Boot Guard

Abychom analyzovali implementaci této technologie na konkrétním příkladu, zkontrolovali jsme následující systémy, zda neobsahují stopy technologie Intel BG:

systém
Poznámka

Gigabyte GA-H170-D3H
Skylake, je tu podpora

Gigabyte GA-Q170-D3H
Skylake, je tu podpora

Gigabyte GA-B150-HD3
Skylake, je tu podpora

MSI H170A Gaming Pro
Skylake, žádná podpora

Lenovo ThinkPad 460
Skylake, podpora dostupná, technologie povolena

Lenovo jóga 2 Pro
Haswell, žádná podpora

Lenovo U330p
Haswell, žádná podpora

„Podpora“ znamená přítomnost spouštěcího modulu Intel BG ACM, výše zmíněných manifestů a odpovídajícího kódu v BIOSu, tzn. implementace pro analýzu.

Jako příklad si vezměme ten stažený z kanceláře. obrázek stránky dodavatele flash paměti SPI pro Gigabyte GA-H170-D3H (verze F4).

Zaváděcí ROM procesoru Intel

Nejprve si promluvme o akcích procesoru, pokud je povolena technologie Intel BG.

Nebylo možné najít vzorky dešifrovaného mikrokódu, proto je otevřenou otázkou, jak jsou níže popsané akce implementovány (v mikrokódu nebo v hardwaru). Nicméně skutečnost, že moderní procesory Intel tyto akce „umí“, je fakt.

Po opuštění stavu RESET procesor (v jehož adresním prostoru je již namapován obsah flash paměti) najde FIT (Firmware Interface Table). Nalezení je snadné, ukazatel na něj je zapsán na adrese FFFF FFC0h.

V tomto příkladu tato adresa obsahuje hodnotu FFD6 9500h. Při otočení na tuto adresu vidí procesor FIT tabulku, jejíž obsah je rozdělen do záznamů. První záznam je nadpis následující struktury:

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

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

Zbývající položky ukazují na různé binární soubory, které je třeba analyzovat / spustit před spuštěním systému BIOS, tj. před přepnutím na starší vektor RESET (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 označuje typ bloku, na který tato položka ukazuje. Známe několik typů:

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 zřejmé, že jeden ze záznamů ukazuje na umístění binárního souboru ACM startu Intel BG. Struktura hlavičky tohoto binárního souboru je typická pro moduly kódu vyvinuté společností Intel (ACM, aktualizace mikrokódu, sekce kódu 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];
};

Procesor načte tento binární soubor do své mezipaměti, ověří a spustí.

Spuštění Intel BG ACM

V důsledku analýzy práce tohoto ACM vyšlo najevo, že dělá následující:

přijímá od Intel ME konfiguraci Intel BG zapsanou do pojistek čipové sady (FPF);
najde manifesty KEYM a IBBM, ověří je.

K nalezení těchto manifestů používá ACM také tabulku FIT, která má dva typy záznamů, které ukazují na tyto struktury (viz FIT_ENTRY_TYPES výše).

Podívejme se blíže na manifesty. 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ý kořenový klíč OEM podepsaný jako vnořená struktura:

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

K ověření veřejného klíče kořenového klíče OEM připomínáme, že se používá hash SHA256 z pojistek, který v tuto chvíli již byl přijat od Intel ME.

Přejděme k druhému manifestu. Skládá se ze tří struktur:

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

První obsahuje několik konstant:

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

Druhý obsahuje hash SHA256 IBB a počet deskriptorů, které popisují obsah IBB (tj. z čeho se hash počítá):

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 sledují tuto strukturu 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;
};

Je to jednoduché: každý deskriptor obsahuje adresu/velikost IBB bloku. Zřetězení bloků, na které ukazují tyto deskriptory (v pořadí samotných deskriptorů), je tedy IBB. A IBB je zpravidla kombinací všech modulů fáze SEC a PEI.

Druhý manifest končí strukturou obsahující veřejný klíč IBB (ověřený hashem SHA256 z prvního manifestu) a podpis tohoto manifestu:

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

Takže ještě před zahájením spouštění UEFI BIOS procesor spustí ACM, který ověří pravost obsahu sekcí s kódy fází SEC a PEI. Dále procesor ukončí ACM, přesune se podél vektoru RESET a začne spouštět BIOS.

Oddíl ověřený PEI musí obsahovat modul, který zkontroluje zbytek BIOSu (kód DXE). Tento modul je již vyvíjen společností IBV (Independent BIOS Vendor) nebo samotným dodavatelem systému. Protože Ukázalo se, že máme k dispozici pouze systémy Lenovo a Gigabyte a mají podporu Intel BG, uvažujme kód extrahovaný z těchto systémů.

Modul UEFI BIOS LenovoVerifiedBootPei

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

Jeho úkolem je vyhledat (pomocí GUID) hašovací 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;
}

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

Modul UEFI BIOS BootGuardPei

V případě Gigabyte se ukázalo, že jde o modul BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066} vyvinutý společností AMI, a tedy přítomný v jakémkoli AMI BIOSu s podporou Intel BG.

Jeho operační algoritmus je poněkud odlišný, ale scvrkává se na 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;
}

Vyhledaná hashovací tabulka {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} 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

Pojďme si krátce povědět o další implementaci Intel Boot Guard, která byla nalezena v novějším systému založeném na Intel SoC s mikroarchitekturou Apollo Lake – ASRock J4205-IT.

Ačkoli tato verze bude používána pouze v SoC (nové systémy s mikroarchitekturou procesoru Kaby Lake nadále využívají Intel Boot Guard 1.x), je velký zájem o prozkoumání nové možnosti architektury pro platformy založené na Intel SoC, která se stala hmatatelnou změny, například:

Oblasti BIOS a Intel ME (nebo spíše Intel TXE, podle terminologie Intel SoC) jsou nyní jednou oblastí IFWI;
ačkoliv byl na platformě povolen Intel BG, struktury jako FIT, KEYM, IBBM nebyly ve flash paměti nalezeny;
kromě jader TXE a ISH (x86) přibylo do čipsetu ještě třetí jádro (mimochodem opět ARC) - PMC (Power Management Controller), spojené se zajištěním provozuschopnosti napájecího subsystému a sledováním výkonu.

Obsahem nového regionu IFWI je sada následujících modulů:

Offset
název
popis

0000 2000 h
SMIP
nějakou konfiguraci platformy, podepsanou dodavatelem

0000 6000 h
RBEP
Část firmwarového kódu Intel TXE, x86, podepsaná společností Intel

0001 0000 h
PMCP
část kódu firmwaru Intel PMC, ARC, podepsaná společností Intel

0002 0000 h
FTPR
Část firmwarového kódu Intel TXE, x86, podepsaná společností Intel

0007B000h
UCOD
Aktualizace mikrokódu CPU podepsané společností Intel

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

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

0025 8000 h
FTP
Část firmwarového kódu Intel TXE, x86, podepsaná společností Intel

0036 1000 h
IUNP
neznámý

0038 1000 h
OBBP
UEFI BIOS, fáze DXE, x86, nepodepsaný

Při analýze firmwaru TXE vyšlo najevo, že po RESETu TXE udržuje procesor v tomto stavu, dokud si nepřipraví základní obsah adresního prostoru pro CPU (FIT, ACM, RESET vector ...). Navíc TXE tato data umístí do své SRAM, načež tam dočasně poskytne přístup procesoru a „uvolní“ je z RESETu.

Na stráži rootkitů

No a teď přejděme k "horkým". Jednou jsme zjistili, že na mnoha systémech mají SPI flash deskriptory oprávnění pro přístup k oblastem SPI flash paměti, takže všichni uživatelé této paměti mohou jak zapisovat, tak číst libovolnou oblast. Tito. v žádném případě.

Po kontrole pomocí nástroje MEinfo (od Intel STK) jsme viděli, že výrobní režim na těchto systémech nebyl uzavřen, a proto byly pojistky čipové sady (FPF) ponechány v neurčitém stavu. Ano, Intel BG není v takových případech povolen ani zakázán.

Mluvíme o následujících systémech (pokud jde o Intel BG a co bude popsáno dále v článku, budeme hovořit o systémech s mikroarchitekturou procesoru Haswell a vyšší):

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

Těmto prodejcům jsme nález samozřejmě nahlásili, stejně jako Intelu.

Přiměřená odpověď následovala pouze od Lenovokdo uznal problém a vydal patch.

Gigabyte Zdá se, že informace o zranitelnosti přijali, ale nijak se nevyjádřili.

Komunikace s MSI zcela zastaveno na naši žádost o zaslání našeho veřejného klíče PGP (za účelem zaslání zašifrovaného bezpečnostního upozornění). Uvedli, že „jsou výrobcem hardwaru a nevyrábějí klíče PGP“.

Ale spíš k věci. Protože jsou pojistky ponechány v nedefinovaném stavu, může si je uživatel (nebo útočník) naprogramovat sám (nejobtížnější je najít Intel STK). To vyžaduje následující kroky.

1. Spusťte operační systém Windows (obecně lze níže popsané kroky provést také z Linuxu, pokud pro požadovaný OS vyvíjíte analog Intel STK). Pomocí nástroje MEinfo se ujistěte, že pojistky tohoto systému nejsou naprogramovány.

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

3. Otevřete načtený obraz pomocí libovolného editačního nástroje UEFI BIOS, proveďte potřebné změny (implementujte například rootkit), vytvořte / upravte stávající struktury KEYM a IBBM v oblasti ME.

Na obrázku je zvýrazněna veřejná část klíče RSA, jehož hash bude naprogramován do pojistek čipsetu spolu se zbytkem konfigurace Intel BG.

4. Pomocí nástroje Flash Image Tool vytvořte nový obraz firmwaru (nastavením konfigurace Intel BG).

5. Napište nový obrázek pro flash pomocí Flash Programming Tool a pomocí MEinfo ověřte, že oblast ME nyní obsahuje konfiguraci Intel BG.

6. K uzavření výrobního režimu použijte Flash Programming Tool.

7. Systém se restartuje a poté pomocí MEinfo můžete ověřit, že FPF jsou nyní naprogramovány.

Tyto akce navždy povolit Intel BG v tomto systému. Akci nebude možné vrátit zpět, což znamená:

pouze vlastník soukromé části kořenového klíče (tedy ten, kdo povolil Intel BG) bude moci aktualizovat UEFI BIOS na tomto systému;
pokud tomuto systému vrátíte původní firmware např. pomocí programátoru, tak se ani nezapne (důsledek vynucovací politiky v případě chyby ověření);
abyste se takového UEFI BIOSu zbavili, musíte vyměnit čipset s naprogramovanými FPF za „čistý“ (t.j. přepájet čipset, pokud máte přístup k infračervené pájecí stanici za cenu auta, nebo jen vyměnit základní desku ).

Abyste pochopili, co takový rootkit umí, musíte vyhodnotit, co umožňuje spustit váš kód v prostředí UEFI BIOS. Řekněme, že v nejprivilegovanějším režimu procesoru - SMM. Takový rootkit může mít následující vlastnosti:

být spuštěn paralelně s OS (zpracování můžete nakonfigurovat vygenerováním přerušení SMI, které bude spouštěno časovačem);
mít všechny výhody režimu SMM (plný přístup k obsahu paměti RAM a hardwarovým zdrojům, utajení před OS);
Kód rootkitu lze při spuštění v režimu SMM zašifrovat a dešifrovat. Jakákoli data dostupná pouze v režimu SMM lze použít jako šifrovací klíč. Například hash ze sady adres v SMRAM. Chcete-li získat tento klíč, budete muset vlézt do SMM. A to lze provést dvěma způsoby. Najděte RCE v kódu SMM a využijte jej, nebo přidejte svůj vlastní modul SMM do BIOSu, což je nemožné, protože jsme povolili Boot Guard.

Tato chyba zabezpečení tedy umožňuje útočníkovi:

vytvořit v systému skrytý neodstranitelný rootkit neznámého účelu;
spusťte svůj kód na jednom z jader čipové sady uvnitř Intel SoC, konkrétně na Intel ISH (podívejte se blíže na obrázek).

Přestože možnosti subsystému Intel ISH ještě nebyly prozkoumány, zdá se, že jde o zajímavý vektor útoku proti Intel ME.

Závěry

Studie poskytla technický popis fungování technologie Intel Boot Guard. Mínus pár tajemství v zabezpečení Intelu prostřednictvím modelu zatemnění.
Je prezentován scénář útoku, který umožňuje vytvořit v systému neodstranitelný rootkit.
Viděli jsme, že moderní procesory Intel jsou schopny spustit spoustu proprietárního kódu ještě před spuštěním BIOSu.
Platformy s architekturou Intel 64 jsou stále méně vhodné pro provozování svobodného softwaru: ověřování hardwaru, rostoucí počet proprietárních technologií a subsystémů (tři jádra v čipsetu SoC: x86 ME, x86 ISH a ARC PMC).

Zmírnění

Dodavatelé, kteří záměrně nechávají otevřený výrobní režim, by jej měli rozhodně zavřít. Zatím jen zavírají oči a nové systémy Kaby Lake to ukazují.

Uživatelé mohou na svých systémech (které jsou postiženy popsanou zranitelností) zakázat Intel BG spuštěním Flash Programming Tool s volbou -closemnf. Nejprve byste se měli ujistit (pomocí MEinfo), že konfigurace Intel BG v oblasti ME umožňuje přesné vypnutí této technologie po naprogramování v FPF.

Zdroj: www.habr.com

Schrödingerova důvěryhodná bota. Intel Boot Guard