Schrödinger megbízható indítása. Intel Boot Guard

Ajánljuk, hogy mélyebbre merüljünk és beszéljünk az x86-kompatibilis számítógép platformok firmware biztonságáról. Ezúttal a kutatás fő összetevője az Intel Boot Guard (ne keverjük össze az Intel BIOS Guard-dal!) – egy hardveresen támogatott, megbízható BIOS betöltési technológia, amelyet a számítógép gyártója folyamatosan aktiválhat vagy deaktiválhat a gyártási folyamat során. A kutatás receptje számunkra már ismerős: alaposan elemezzük a technológia megvalósítását visszafejtéssel, leírjuk annak architektúráját, kiegészítjük nem dokumentált részletekkel, fűszerezzük a támadási vektorokkal és összekeverjük. Fokozzuk az izgalmakat azzal, hogy bemutatjuk, hogyan lehet a több gyártó által éveken át klónozott gyártási hibát potenciális támadók számára felhasználni a technológia segítségével egy olyan rejtett rootkit létrehozásához a rendszerben, amelyet még a programozó sem tud eltávolítani.

Egyébként a cikk alapja a "Rootkitek védelme: Intel BootGuard" című prezentációk a konferenciáról ZeroNights 2016 és a 29. találkozó DefCon Russia (mindkét prezentáció itt).

Intel 64 architektúrájú számítógép firmware

Kezdjük azzal, hogy válaszolunk a kérdésre: mi is az a modern Intel 64 architektúrájú számítógép firmware? Természetesen az UEFI BIOS. De ez a válasz nem teljesen pontos. Nézzük meg a képet, amelyen ennek az architektúrának a desktop (laptop) változata látható.

Az alap egy összefonódás:

• Processzor (CPU, Central Processing Unit), amelyben a fő magokon kívül beépített grafikus mag is található (nem minden modellben) és integrált memória vezérlő (IMC, Integrated Memory Controller) van beépítve;
• Chipkészlet (PCH, Platform Controller Hub), amely különféle vezérlőket tartalmaz a perifériás eszközökkel való interakcióhoz és az alrendszerek irányításához. Köztük ott van a jól ismert Intel Management Engine (ME), amelynek szintén van firmware-e (Intel ME firmware).

A laptopok, a fentebb említetteken túl, beépített vezérlőt (ACPI EC, Advanced Control and Power Interface Embedded Controller) is magukban foglalnak, amely a tápegység, a touchpad, a billentyűzet, a Fn-gombok (képernyő fényereje, hangereje, billentyűzet háttérvilágítása stb.) és más funkciók működéséért felelős. És ennek is van saját firmware-e.

Tehát a fent említett firmware-ek összessége képezi a számítógépes platform firmware-jét (system firmware), amely a közönséges SPI flash memóriában tárolódik. Annak érdekében, hogy a felhasználók ne összezavarodjanak, hogy kinek mi van, a memória tartalmát a következő régiókra osztották (ahogyan az a képen látható):

• UEFI BIOS;
• ACPI EC firmware (külön régió a Skylake (2015) mikroarchitektúra óta jelent meg, de a gyakorlatban még nem láttunk példákat a használatára, így az integrált vezérlő firmware-e továbbra is az UEFI BIOS része);
• Intel ME firmware;
• a beépített GbE (Gigabit Ethernet) hálózati adapter konfigurációja (MAC-cím stb.);
• Flash Descriptors - a flash memória fő régiója, amely a többi régióra mutató mutatókat és a hozzáférési jogosultságokat tartalmazza.

A régiókhoz való hozzáférés szabályozása (a megadott jogosultságok szerint) a SPI busz mestere – az SPI-vezérlő, amely be van építve a chipkészletbe, és amelyen keresztül a memória elérése történik. Ha a jogosultságok a vállalat által, a biztonságos megfontolások miatt, javasolt értékekre vannak beállítva, akkor minden SPI flash memória felhasználónak teljes hozzáférése (olvasás/írás) van csak a saját régiójához. A többi – vagy csak olvasható, vagy egyáltalán nem elérhető. Közismert tény: sok rendszernél a CPU teljes hozzáféréssel rendelkezik az UEFI BIOS-hoz és a GbE-hez, az olvasási hozzáférés csak a flash-deszkripekhez van, míg az Intel ME régióhoz egyáltalán nincs hozzáférése. Miért sok, és nem minden rendszerben? Ami ajánlott, az nem kötelező. Részletesebben a cikk következő részében beszélünk róla.

A számítógépes platform firmware védelmi mechanizmusai a módosítás ellen

Nyilvánvaló, hogy a számítógépes platform firmware-jét meg kell védeni az esetleges kompromittálódástól, amely lehetővé tenné egy lehetséges támadó számára, hogy befészkelje magát (túlélje a frissítéseket/operációs rendszerek újratelepítéseit), és a legmagasabb privilegizált üzemmódokban futtassa a kódját stb. A SPI flash memória régiókhoz való hozzáférés korlátozása természetesen nem elegendő. Ezért a firmware védelme érdekében különböző mechanizmusokat alkalmaznak, amelyek specifikusak a végrehajtási környezethez.

Így az Intel ME firmware-t aláírják a sértetlenség és eredetiség ellenőrzésére, és a ME-vezérlő minden alkalommal ellenőrzi, amikor a memória ME UMA-ba töltődik. Ezt a verifikációs folyamatot már tárgyaltuk korábban. cikkünkben, amely az Intel ME alrendszerének szentelt.

Az ACPI EC firmware, általában csak az integritását ellenőrzik. Azonban, mivel ez a bináris be van építve az UEFI BIOS-ba, szinte mindig azok a védelmi mechanizmusok vonatkoznak rá, amelyeket az UEFI BIOS is használ. Erről fogunk beszélni.

Ezeket a mechanizmusokat két kategóriába lehet sorolni.

Írásvédett védelem az UEFI BIOS régióban

1. A SPI flash memória tartalmának fizikai védelme write-protect jumperrel;
2. Az UEFI BIOS régió projektjének védelme a CPU címzési térben a chipkészlet PRx regisztereivel;
3. Az UEFI BIOS régióba való írási kísérletek blokkolása a megfelelő SMI megszakítás generálásával és kezelésével a BIOS_WE/BLE és SMM_BWP bitek chipkészlet regiszterekbe történő beállításával;
4. Egy fejlettebb védelmi változat az Intel BIOS Guard (PFAT).

Ezekhez a mechanizmusokhoz az eladók saját biztonsági intézkedéseket is kifejleszthetnek és alkalmazhatnak (például az UEFI BIOS frissítések kapszuláinak aláírása).

Fontos megjegyezni, hogy egy adott rendszeren (az eladótól függően) nem minden fenti védelmi mechanizmus alkalmazható, lehet, hogy egyáltalán nem alkalmazzák őket, vagy sebezhetően valósítják meg őket. Részletesebben ezekről a mechanizmusokról és azok megvalósítási helyzetéről olvashat a cikkben. Az érdeklődőknek javasoljuk, hogy ismerkedjenek meg az UEFI BIOS biztonsági ciklussal a CodeRush.

Az UEFI BIOS hitelesítésének ellenőrzése

Amikor a megbízható indítás technológiáiról beszélünk, az első dolog, ami eszünkbe jut, a Secure Boot. Azonban architektúrájában ez az UEFI BIOS-hoz képest külső komponensek (meghajtók, indítók stb.) hitelesítésére szolgál, nem pedig magának a firmware-nek a hitelesítésére.

Ezért az Intel a Bay Trail mikroarchitektúrával rendelkező SoC-okban (2012) megvalósította a hardveresen kikapcsolhatatlan Secure Boot-ot (Verified Boot), amelynek semmi köze a fent említett Secure Boot technológiához. Később (2013) ezt a mechanizmust továbbfejlesztették, és Intel Boot Guard néven adták ki asztali számítógépekhez a Haswell mikroarchitektúrával.

Az Intel Boot Guard leírása előtt tisztázzuk az Intel 64 architektúrájának végrehajtási környezeteit, amelyek egyben a megbízhatóság gyökerei e megbízható indítási technológia számára.

Intel CPU

Képzeld el, hogy a processzor az Intel 64 architektúrájának fő végrehajtási környezete. Miért is tekintjük őt megbízhatóság gyökerének? Kiderült, hogy a következő elemek birtoklása teszi őt azzá:

• A mikrokód ROM energiatakarékos, nem újraírható memória a mikrokód tárolására. Úgy tartják, hogy a mikrokód a processzor utasításkészletének megvalósítása a legegyszerűbb utasítások szintjén. A mikrokódban is előfordulhatnak hibák. Tehát a BIOS-ban találhatók a mikrokód frissítéseit tartalmazó bináris fájlok (a betöltés során telepítve, mivel a ROM nem írható felül). Ezeknek a binárisoknak a tartalma titkosítva van, ami jelentősen megnehezíti az elemzést (ezért a mikrokód konkrét tartalma csak azok számára ismert, akik azt fejlesztik), és aláírásra került az integritás és az autentikusság ellenőrzésére;
• AES kulcs a mikrokód frissítések tartalmának visszafejtésére;
• az RSA közpublic kulcs hash-e, amely a mikrokód frissítések aláírásának ellenőrzésére szolgál;
• az RSA közpublic kulcs hash-e, amely ellenőrzi az Intel által kifejlesztett ACM (Authenticated Code Module) kódmodul aláírását, amelyet a CPU végrehajthat a BIOS végrehajtásának megkezdése előtt (üdvözlet mikrokód) vagy annak működésének során, bizonyos események bekövetkeztekor.

Intel ME

Ezt a rendszert teljes egészében bemutattuk a blogunkban. két cikkből származnakEmlékeztetünk arra, hogy ez a végrehajtható környezet egy beágyazott mikrokontrollerre épül a chipkészletben, és a legelrejtettebb és legprivilegizáltabb a rendszerben.

A rejtettsége ellenére az Intel ME is a bizalom forrása, mivel rendelkezik:

• ME ROM — energiatakarékos, nem újraírható memória (nincs lehetőség frissítésre), amely az indító kódot, valamint az RSA közpublic kulcs SHA256 hash-ét tartalmazza, amely a Intel ME firmware aláírásának ellenőrzésére szolgál;
• AES kulcs a titkos információk tárolására;
• hozzáférés az integrált chipkészletben található fúziókhoz (FPFs, Field Programmable Fuses) a bizonyos információk tartós tárolására, beleértve a számítógép rendszerének gyártója által megadottakat is.

Intel Boot Guard 1.x

Egy rövid nyilatkozat. Az Intel Boot Guard technológiához kapcsolódó verziószámok, amelyeket ebben a cikkben alkalmazunk, feltételezettek, és nem feltétlenül egyeznek meg az Intel belső dokumentációjában használt számozással. Ezen kívül, az itt bemutatott információk a technológia megvalósításáról visszafejtés útján nyertek, és eltéréseket tartalmazhatnak az Intel Boot Guard specifikációjától, amely valószínűleg soha nem lesz nyilvánosságra hozva.

Tehát, az Intel Boot Guard (BG) egy hardveresen támogatott UEFI BIOS hitelesítési technológia. Egy rövid leírása alapján a [Platform Embedded Security Technology Revealed, Boot with Integrity, or Not Boot] című könyvben úgy tűnik, hogy egy megbízható indítási lánc formájában működik. Az első link benne a boot kód (mikrokód) a CPU-ban, amely a RESET esemény hatására indul el (ne keverjük össze a BIOS RESET-vezérlőjével!). A CPU megtalálja az SPI flash memóriában az Intel által kifejlesztett és aláírt kódmodult (Intel BG startup ACM), betölti a cache-be, hitelesíti (ahogy már említettem, a CPU rendelkezik az ACM aláírásának ellenőrzéséhez szükséges nyilvános kulcs hash értékével), és elindítja.

Ez a kódmodul felelős a UEFI BIOS egy kis induló részének – az Inicial Boot Block (IBB) – hitelesítéséért, amely viszont funkcióval bír a UEFI BIOS fő részének hitelesítésére. Így az Intel BG lehetővé teszi, hogy megbizonyosodjunk a BIOS hitelességéről az operációs rendszer betöltése előtt (melyet a Secure Boot technológia figyelhet).

Az Intel BG technológia két működési módot tartalmaz (és ezek nem zavarják egymást, azaz mindkét mód engedélyezhető a rendszerben, vagy mindkettő le van tiltva).

Measured Boot

A Measured Boot (MB) módban minden indító komponens (a CPU boot ROM-tól kezdve) „méri” a következőt a TPM (Trusted Platform Module) képességeit felhasználva. Azok számára, akik nem ismerik az eljárást, magyarázzuk el.

A TPM-nek vannak PCR-ek (Platform Configuration Registers), amelyekbe a hash-elési eljárás eredményét írják:

Tehát a PCR aktuális értéke a korábbiaktól függ, a regiszterek adatai csak a rendszer RESET-je során nullázódnak.

Így az MB módban egy bizonyos időpontban a PCR-ek olyan egyedi (a hash-elési eljárás képességei között) azonosítót tükröznek, amely a „mért” kódra vagy adatokra vonatkozik. A PCR értékek felhasználhatók bizonyos adatok titkosítási eljárásánál (TPM_Seal). Ezt követően a TPM_Unseal művelet csak abban az esetben lehetséges, ha a betöltés után a PCR értékek nem változtak (azaz egyetlen „mért” komponenst sem módosítottak).

Verified Boot

A módosításokra hajlamos UEFI BIOS kedvelőinek legrosszabb rémálma a Verified Boot (VB) üzemmód, amelyben minden indító komponens kriptográfiailag ellenőrzi a következő integritását és hitelességét. Ha a hitelesítési hiba történik, a következő lépések történnek (az egyik):

• Leállítás 1 és 30 perc közötti várakozási idővel (hogy a felhasználó megérthesse, miért nem indul el a gépe, és lehetőség szerint próbálja meg helyreállítani a BIOS-t);
• Azonnali leállítás (hogy a felhasználó ne érthessen meg semmit, és főleg ne tegyen semmit);
• Folytatás nyugodt arccal (azon eset, amikor nem a biztonság a legfontosabb, hiszen van ennél fontosabb dolog is).

A tevékenység kiválasztása az Intel BG konfigurációjától függ (nevezetesen, az úgynevezett enforcement policy-től), amelyet a számítógép platform szállítója folyamatosan rögzít egy erre a célra fenntartott tárolóba – a chipkészlet fúzióiba (FPF-ek). Részletesebben e pontra később térünk ki.

A konfiguráción kívül a szállító két 2048 bites RSA kulcsot generál, és két adatstruktúrát hoz létre (ábrázolva a képen):

1. A szállító gyökérkulcsának manifesztuma (KEYM, OEM Root Key Manifest), amelybe belekerül az SVN (Security Version Number) e manifesztum, a következő manifesztum nyilvános kulcsának SHA256 hash-e, az RSA nyilvános kulcs (azaz a szállító gyökérkulcsának nyilvános része) a manifesztum aláírásának ellenőrzésére és maga az aláírás;
2. Az IBB manifesztuma (IBBM, Initial Boot Block Manifest), amelybe belekerül e manifesztum SVN-je, az IBB SHA256 hash-e, a manifesztum aláírásának ellenőrzésére szolgáló nyilvános kulcs és maga az aláírás.

Az OEM Root Key nyilvános kulcsának SHA256 hash-e folyamatosan rögzítésre kerül a chipkészlet fúziójában (FPF-ek), akárcsak az Intel BG konfigurációja. Ha az Intel BG konfigurációja lehetővé teszi e technológia bekapcsolását, akkor ettől a pillanattól kezdve a BIOS frissítése (azaz e manifesztumok újraszámítása) csak az OEM Root Key privát kulcsának birtokosa, azaz a szállító számára lehetséges.

A képre nézve azonnal felmerül a kérdés, hogy valóban szükség van-e egy ilyen hosszú hitelesítési láncra – egy manifesztumot is lehetett volna használni. Miért bonyolítani?

Valójában az Intel így ad lehetőséget a szállítónak, hogy különböző IBB kulcsokat használjon különféle termékcsaládjaihoz és egyet – gyökérként. Ha az IBB kulcs privát része kiszivárog (amely a második manifesztumot írja alá), az incidens csak egy termékcsaládot érint, és csak addig, amíg a szállító új párt nem generál, és a következő BIOS frissítéskor nem illeszti be az újraszámolt manifesztumokat.

De ha a gyökérkulcs (amellyel az első manifestumot aláírják) sérül, akkor azt nem lehet kicserélni. Nincs előírva visszavonási eljárás, mivel a nyilvános rész hash-ét egyszer és mindenkorra programozzák az FPF-ekbe.

Intel Boot Guard konfiguráció

Most részletesebben megvizsgáljuk az Intel BG konfigurációt és annak létrehozásának folyamatát. Ha megnézzük a Flash Image Tool GUI megfelelő fülét az Intel System Tool Kit (STK) csomagból, észrevehetjük, hogy az Intel BG konfigurációja tartalmazza a szállítói gyökérkulcs nyilvános részének hash-ét, pár érthetetlen értéket és az úgynevezett Intel BG profilt.

Ennek a profilnak a felépítése:

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 - nem csinál semmit
						   // 01b - időtúllépéses leállítás
						   // 11b - azonnali leállítás
	unsigned long : 26;
};

Általában az Intel BG konfiguráció nagyon rugalmas. Vegyük például a Force_Boot_Guard_ACM flagot. Ha ez kikapcsolva van, ha a BG startup ACM modult nem találják a SPI flash memóriában, akkor nem lesz megbízható indítás. Megbízhatatlan lesz.

Előzőleg már írtunk arról, hogy az enforcement policy a VB módhoz úgy is beállítható, hogy ha a hitelesítés során hiba lép fel, akkor ismét megbízhatatlan indítás történik.

Ezeket a dolgokat a szállítókra bízni...

A GUI eszköz a következő 'kész' profilokat biztosít:

Szám
Mód
Leírás

0
No_FVME
az Intel BG technológia kikapcsolva

1
VE
VB mód engedélyezve, időtúllépéses leállítás

2
VME
mindkét mód (VB és MB) engedélyezve, időtúllépéses leállítás

3
VM
mindkét mód engedélyezve, a rendszer leállítása nélkül

4
FVE
VB mód engedélyezve, azonnali leállítás

5
FVME
mindkét mód engedélyezve, azonnali leállítás

Amint már említettük, az Intel BG konfigurációnak egyszer és mindenkorra a rendszer szállítójának kell rögzítenie a chipkészlet fúzióiban (FPF-ek) – egy kis (nem ellenőrzött információk szerint mindössze 256 byte) hardveres információtároló az chipkészletben, amely programozható a cég gyártási kapacitásán kívül (ezért éppen Field Programmable Fuses).

Kiválóan alkalmas a konfiguráció tárolására, mivel:

• van egy egyszeri programozású területe az adatok tárolására (ez az, ahova az Intel BG konfigurációt rögzítik);
• csak az Intel ME tudja olvasni és programozni.

Tehát, ahhoz, hogy konfigurációt állítsanak be az Intel BG technológiához egy adott rendszeren, a gyártó a termelés során a következőket végzi:

1. A Flash Image Tool (az Intel STK-ból) segítségével létrehoz egy firmware képet a kívánt Intel BG konfigurációval, amely változókként jelenik meg az Intel ME régióban (az ún. ideiglenes tükör az FPF-ekhez);
2. A Flash Programming Tool (az Intel STK-ból) segítségével rögzíti ezt a képet az SPI flash memóriába és lezárja az ún. gyártási módot (eközben a megfelelő parancsot küldik az Intel ME-nek).

Ezeknek a műveleteknek az eredményeként az Intel ME a megadott értékeket az FPF-ekből a ME régió tükörből elkötelezi, beállítja az SPI flash leírók engedélyeit az Intel által ajánlott értékekre (ahogy az a cikk elején le volt írva), és végrehajt egy RESET-et a rendszeren.

Az Intel Boot Guard implementációjának elemzése

A technológia megvalósításának elemzése céljából egy konkrét példát vettünk alapul, és az alábbi rendszereket vizsgáltuk az Intel BG technológia nyomaiban:

Rendszer
Megjegyzés

Gigabyte GA-H170-D3H
Skylake, támogatott

Gigabyte GA-Q170-D3H
Skylake, támogatott

Gigabyte GA-B150-HD3
Skylake, támogatott

MSI H170A Gaming Pro
Skylake, nem támogatott

Lenovo ThinkPad 460
Skylake, támogatott, technológia engedélyezve

Lenovo Yoga 2 Pro
Haswell, nem támogatott

Lenovo U330p
Haswell, nem támogatott

A "támogatás" alatt az Intel BG startup ACM modul, a fent említett manifesztok és a megfelelő kód BIOS-ban való meglétét értjük, azaz a vizsgálatra való implementációt.

Példaként vegyük a hivatalos gyártói weboldalról letöltött SPI flash memória képet a Gigabyte GA-H170-D3H-hoz (F4 verzió).

Intel CPU boot ROM

Először is beszéljünk arról, hogy a processzor mit csinál, ha az Intel BG technológia engedélyezve van.

Dekódolt mikrokód minták nem álltak rendelkezésre, így a később leírt műveletek hogyan valósulnak meg (mikrokódban vagy hardveresen) – kérdéses. Mindazonáltal tény, hogy a modern Intel processzorok "képesek" végrehajtani ezeket a műveleteket.

Miután a RESET állapotból kilép, a processzor (melynek címterében már le van térképezve a flash memória tartalma) megtalálja a FIT (Firmware Interface Table) táblázatot. Ennek megtalálása egyszerű, mert a mutatója az FFFF FFC0h cím alatt van.

A vizsgált példa szerint ezen a címen a FFD6 9500h érték található. Erre a címre hivatkozva a processzor látja a FIT táblázatot, amelynek tartalma feljegyzésekre van bontva. Az első bejegyzés a következő szerkezetű fejléc:

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_   ’
	unsigned long  NumEntries; // beleértve a FIT fejléc bejegyzést
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

Ismeretlen okból a checksumot nem mindig számolják ki ezeken a táblázatokon (a mező nullára van hagyva).

A többi bejegyzés különböző bináris állományokra utal, amelyeket még a BIOS végrehajtása előtt, azaz a legacy RESET-irányítóvektor (FFFF FFF0h) átlépése előtt kell parsolni/végrehajtani. Minden egyes ilyen bejegyzés struktúrája a következő:

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

Az EntryType mező jelzi a blokknak azt a típusát, amelyre ez a bejegyzés hivatkozik. Több ismert típusunk van:

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

Most már nyilvánvaló, hogy az egyik bejegyzés az Intel BG startup ACM bináris állomány elhelyezkedésére utal. Ennek a bináris állománynak a fejléc struktúrája jellemző az Intel által fejlesztett kódmodulokra (ACM-ek, mikrokódfrissítések, Intel ME kódfejezések, stb.).

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

A processzor beolvassa ezt a bináris állományt a cache-be, ellenőrzi és végrehajtja.

Intel BG startup ACM

Ennek az ACM-nek a működésének elemzéséből kiderült, hogy a következőket végzi:

• megkapja az Intel ME-től az Intel BG konfigurációt, amely a chipset fúzióiban van rögzítve (FPF-ek);
• megtalálja a KEYM és IBBM manifesztjeit, és ellenőrzi azokat.

E manifesztok megtalálásához az ACM szintén a FIT táblázatot használja, amelyben két bejegyzéstípust jelöltek ki a struktúrák adataihoz (lásd a fenti FIT_ENTRY_TYPES-t).

Részletesebben nézzük meg a manifesztokat. Az első manifeszt struktúrájában több homályos konstans, a második manifeszt nyilvános kulcsának hash-e és az OEM Root Key nyilvános kulcsa látható, amely struktúrával van aláírva:

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

A OEM Root Key nyilvános kulcsának ellenőrzéséhez emlékezzünk, hogy a fúziókból származó SHA256 hash-t használjuk, amelyet már megkaptunk az Intel ME-től.

Térjünk át a második manifestre. Három struktúrából áll:

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

Az elsőben – néhány konstanta található:

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

A másodikban található a SHA256 hash IBB és a descriptorok száma, amelyek az IBB tartalmát írják le (azaz amitől a hash számítódik):

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

Az IBB deskriptorok követik ezt a struktúrát, egymás után. Tartalmuk a következő formátumban van:

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

Minden egyszerű: minden deskriptor tartalmaz egy cím/kiterjedés darabot az IBB-ből. Így azokra a blokkokra történő konkatenálás, amelyeket ezek a deskriptorok mutatnak (a deskriptorok elhelyezkedése alapján), az az IBB. Általában az IBB a SEC és PEI fázis összes moduljából áll.

A második manifestet egy struktúra zárja, amely tartalmazza az IBB nyilvános kulcsát (amelyet az első manifestből származó SHA256 hash ellenőriz) és ennek a manifestnek az aláírását:

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

Tehát, még az UEFI BIOS végrehajtása előtt a processzor elindítja az ACM-et, amely ellenőrzi a SEC és PEI fázisú kód szakaszainak hitelességét. Ezután a processzor kilép az ACM-ből, átjut a RESET vektoron, és megkezdi a BIOS végrehajtását.

A hitelesített PEI szakasznak tartalmaznia kell egy modult, amely ellenőrzi a BIOS többi részét (DXE kód). Ezt a modult már az IBV (Independent BIOS Vendor) vagy a rendszer gyártója fejleszti. Mivel az Intel BG támogatásával rendelkező rendszerek közül csak a Lenovo és Gigabyte rendszerek voltak a rendelkezésünkre állóak, az ezekből kinyert kódot fogjuk megvizsgálni.

UEFI BIOS modul LenovoVerifiedBootPei

Lenovo esetében ez a LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D} modul volt, amelyet a Lenovo fejlesztett.

A feladata, hogy (GUID alapján) megkeresse a DXE hash táblát és ellenőrizze a DXE-t.

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

A hash tábla {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} a következő formátumban van:

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

Gigabyte esetében ez a BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066} modul volt, amelyet az AMI fejlesztett, így bármely AMI BIOS-ban megtalálható, amely támogatja az Intel BG-t.

A működési algoritmus egy kicsit más, de a lényeg ugyanaz:

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 hash tábla {389CC6F2-1EA8-467B-AB8A-78E769AE2A15}, amelyet keres, a következő formátumban van:

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

Röviden szeretnénk bemutatni még egy Intel Boot Guard implementációt, amelyet a modernebb Intel SoC alapú Apollo Lake mikroarchitektúrával rendelkező rendszerekben találtak meg — ASRock J4205-IT.

Bár ez a verzió csak SoC-ákban lesz alkalmazva (az új rendszerek a Kaby Lake mikroarchitektúrával rendelkező processzorok továbbra is az Intel Boot Guard 1.x-et használják), nagy érdeklődésre tart számot az Intel SoC platformok új architektúrájának tanulmányozásában, amelyben jelentős változtatások történtek, például:

• a BIOS és az Intel ME (pontosabban az Intel TXE, a terminológia szerint az Intel SoC esetében) most egy IFWI régióként működik;
• Bár a platformon engedélyezve volt az Intel BG, olyan struktúrákat, mint a FIT, KEYM, IBBM, nem találtak a flash memóriában;
• A TXE és ISH magok (x86) mellett a chipkészletbe egy harmadik mag is került (amúgy ARC), egy PMC (Power Management Controller), amely a tápegység alrendszerének működését és a teljesítmény figyelését biztosítja.

Az új IFWI régió tartalma a következő modulok halmaza:

Offset
Név
Leírás

0000 2000h
SMIP
egy platformkonfiguráció, a gyártó által aláírva

0000 6000h
RBEP
az Intel TXE firmware kódszakasz, x86, Intel által aláírva

0001 0000h
PMCP
az Intel PMC firmware kódszakasz, ARC, Intel által aláírva

0002 0000h
FTPR
az Intel TXE firmware kódszakasz, x86, Intel által aláírva

0007 B000h
UCOD
CPU mikrokód frissítések, Intel által aláírva

0008 0000h
IBBP
UEFI BIOS, SEC/PEI fázis, x86, a gyártó által aláírva

0021 8000h
ISHC
az Intel ISH firmware kódszakasz, x86, a gyártó által aláírva

0025 8000h
NFTP
az Intel TXE firmware kódszakasz, x86, Intel által aláírva

0036 1000h
IUNP
ismeretlen

0038 1000h
OBBP
UEFI BIOS, DXE fázis, x86, nem aláírva

A TXE firmware elemzése során világossá vált, hogy a RESET után a TXE a processzort ebben az állapotban tartja, amíg kész nem készíti az alapvető címteret a CPU számára (FIT, ACM, RESET vektor …). A TXE ezeket az adatokat az SRAM-jában helyezi el, majd ideiglenesen hozzáférést biztosít a processzornak, és "elengedi" a RESET-ből.

A rootkitek védelmében

Most pedig térjünk át a "forró" részre. Egyszer észrevettük, hogy sok rendszeren a SPI flash leírókban olyan jogosultságok szerepelnek a SPI flash memória régióihoz, hogy minden felhasználó írhat és olvashat bármely régiót. Azaz sehogy.

A MEinfo segédprogram segítségével végzett ellenőrzés során láttuk, hogy ezekben a rendszerekben a gyártási mód nincs lezárva, ami azt jelenti, hogy a chipkészlet fúziói (FPF-ek) meghatározatlan állapotban maradtak. Igen, az Intel BG ilyenkor sem engedélyezve, sem letiltva nincs.

A következő rendszerekről van szó (az Intel BG-ra és a cikk következő részére vonatkozóan a Haswell mikroarchitektúrával és annál magasabb teljesítményű rendszerekre fogunk hivatkozni):

• az összes Gigabyte termék;
• az összes MSI termék;
• 21 Lenovo laptopmodell és 4 Lenovo szervermodell.

Természetesen értesítettük a gyártókat erről a felfedezésről, valamint az Intelt is.

Megfelelő reakció csak az Lenovo, akik elismerték a problémát és kiadták a javítást..

Gigabyte többé-kevésbé a sebezhetőségről szóló információt átvette, de semmilyen módon nem kommentálta.

Kapcsolat felvétel MSI Teljesen megakadt a kérésünk a nyílt PGP-kulcs elküldésére (hogy titkosított formában küldhessünk nekik biztonsági figyelmeztetést). Azt állították, hogy "ők hardvergyártók, és nem állítanak elő PGP-kulcsokat."

De térjünk a lényegre. Mivel a fúziók nincsenek beállítva, a felhasználó (vagy rosszindulatú támadó) saját magának programozhatja őket (a legnehezebb — megtalálni az Intel STK-t). Ehhez a következő lépéseket kell végrehajtani.

1. Indítsa el a Windows operációs rendszert (tulajdonképpen a későbbiekben leírt lépéseket Linux alatt is el lehet végezni, ha kidolgozzák az Intel STK megfelelőjét a kívánt operációs rendszerhez). A MEinfo segédprogram segítségével győződjön meg arról, hogy a fúziók ezen a rendszeren nincsenek programozva.

2. Olvassa le a flash memória tartalmát a Flash Programming Tool segítségével.

3. Nyissa meg a leolvasott képet bármilyen UEFI BIOS szerkesztő eszközzel, végezze el a szükséges módosításokat (például rootkitet implementálva), hozzon létre/változtasson meglévő KEYM és IBBM struktúrákat az ME régióban.

A képen az RSA kulcs nyilvános része van kiemelve, amelynek hash értékét a chip konfigurációjával együtt programozzák a fúziókba.

4. A Flash Image Tool segítségével állítson össze egy új firmware képet (az Intel BG konfigurálásával).

5. Írja a új képet a flash memóriába a Flash Programming Tool segítségével, és a MEinfo segítségével győződjön meg arról, hogy az ME régió most az Intel BG konfigurációt tartalmazza.

6. A Flash Programming Tool segítségével zárja le a manufacturing mode-ot.

7. A rendszer újraindul, ezután a MEinfo segítségével megbizonyosodhat arról, hogy az FPF-ek most be vannak programozva.

Ezek a lépések örökre aktiválják az Intel BG-t ezen a rendszeren. A lépést nem lehet visszavonni, ami azt jelenti:

• az UEFI BIOS-t ezen a rendszeren csak az a személy frissítheti, aki a gyökérkulcs privát részének birtokosa (azaz aki aktiválta az Intel BG-t);
• ha a rendszert visszaállítja az eredeti firmware-re, például programozó segítségével, akkor nem is fog elindulni (a verifikációs hiba esetén érvényesülő enforcement policy következménye);
• ahhoz, hogy megszabaduljon egy ilyen UEFI BIOS-tól, a programozott FPF-ekkel rendelkező chipsetet "tiszta" chipsetre kell cserélni (azaz átkonfekcionálni a chipsetet, ha hozzáférése van egy infravörös forrasztó állomáshoz, amely egy autó árába kerül, vagy egyszerűen csak cserélje ki az alaplapot).

Ahhoz, hogy megértsük, mit tehet egy ilyen rootkit, fontos felmérni, mit jelent a kód végrehajtásának lehetősége az UEFI BIOS környezetében. Például, a processzor legprivilegáltabb módjában – SMM. Egy ilyen rootkit a következő tulajdonságokkal rendelkezhet:

• párhuzamosan futni az operációs rendszerrel (beállítható az SMI megszakítás generálására, amely időzítő alapján történik);
• a SMM módban való tartózkodás összes előnyével rendelkezik (teljes hozzáférés a RAM tartalmához és a hardveres erőforrásokhoz, rejtőzködés az operációs rendszer elől);
• a rootkit programkódja titkosított formában tárolható, és az SMM módban való indításkor dekripteálható. A titkosításhoz felhasználható bármilyen adat, amely csak SMM módban elérhető. Például, egy SMRAM címek halmazának hash értéke. E kulcs megszerzéséhez be kell hatolni az SMM-be. Ezt két módon lehet elérni. Meg kell találni egy RCE-t az SMM kódban és azt kihasználni, vagy SMM modult kell hozzáadni a BIOS-hoz, ami lehetetlen, mivel bekapcsoltuk a Boot Guard-ot.

Így ez a sebezhetőség lehetővé teszi a támadó számára:

• rejtett, eltávolíthatatlan rootkit létrehozását ismeretlen célokra a rendszerben;
• a kód végrehajtását az Intel SoC egyik chipset magjában, nevezetesen az Intel ISH-n (figyeljük meg jól a képet).

Bár az Intel ISH alrendszer lehetőségeit még nem tanulmányozták, érdekes támadási vektornak tűnik az Intel ME elleni támadások során.

Következtetések

1. A kutatás lehetővé tette az Intel Boot Guard technológia működésének műszaki leírásának megszerzését. Az Intel modellek titokzatos biztonsági megoldása a security through obscurity koncepcióval határos.
2. Be lett mutatva egy támadási forgatókönyv, amely lehetővé teszi, hogy eltávolíthatatlan rootkit keletkezzen a rendszerben.
3. Láttuk, hogy a modern Intel processzorok képesek sok tulajdonjoggal rendelkező kódot végrehajtani, mielőtt a BIOS elindulna.
4. Az Intel 64 architektúrájú platformok egyre kevésbé alkalmasak szabad szoftverek futtatására: hardveres ellenőrzés, növekvő számú tulajdonjoggal védett technológia és alrendszer (három mag a SoC chipsetben: x86 ME, x86 ISH és ARC PMC).

Korlátozások

Azoknak a gyártóknak, akik szándékosan nyitva hagyják a gyártási módot, azt mindenképpen be kell zárniuk. Jelenleg csak a szemet hunynak, és az új Kaby Lake rendszerek ezt mutatják.

A felhasználók maguk is letilthatják az Intel BG-t a rendszereiken (amelyek az említett sebezhetőségnek ki vannak téve), ha elindítják a Flash Programming Tool-t a -closemnf paraméterrel. Először is, győződjenek meg arról (a MEinfo segítségével), hogy az Intel BG konfiguráció a ME régióban valóban a technológia letiltását irányozza elő a FPF-ek programozása után.

Forrás: habr.com