🥇Zaupanja vreden prenos Schrödingerja. Intel Boot Guard

Predlagamo, da se spet spustimo na nižjo raven in govorimo o varnosti vdelane programske opreme za računalniške platforme, združljive z x86. Tokrat je glavna sestavina študije Intel Boot Guard (ne zamenjujte z Intel BIOS Guard!) – strojno podprta zaupanja vredna zagonska tehnologija BIOS-a, ki jo lahko prodajalec računalniškega sistema trajno omogoči ali onemogoči v proizvodni fazi. No, raziskovalni recept nam je že znan: implementacijo te tehnologije na tanko narežemo z obratnim inženiringom, opišemo njeno arhitekturo, jo napolnimo z nedokumentiranimi podrobnostmi, začinimo z vektorji napadov po okusu in premešamo. Prilijmo olje k zgodbi o tem, kako hrošč, ki je bil leta kloniran v proizvodnji več prodajalcev, potencialnemu napadalcu omogoča, da s to tehnologijo ustvari skriti rootkit v sistemu, ki ga ni mogoče odstraniti (tudi s programatorjem).

Mimogrede, članek temelji na poročilih "Na straži korenskih kitov: Intel BootGuard" s konference ZeroNights 2016 in 29. srečanje DefCon Rusija (obe predstavitvi tukaj).

Vdelana programska oprema za računalniško platformo z arhitekturo Intel 64

Najprej odgovorimo na vprašanje: kakšna je vdelana programska oprema sodobne računalniške platforme z arhitekturo Intel 64? Seveda UEFI BIOS. Toda tak odgovor ne bo točen. Poglejmo si sliko, ki prikazuje namizno (prenosno) različico te arhitekture.

Osnova je povezava:

Procesor (CPU, Central Processing Unit), ki ima poleg glavnih jeder vgrajeno grafično jedro (ne pri vseh modelih) in pomnilniški krmilnik (IMC, Integrated Memory Controller);
Nabor čipov (PCH, Platform Controller Hub), ki vsebuje različne krmilnike za interakcijo s perifernimi napravami in upravljanje podsistemov. Med njimi je dobro znani Intel Management Engine (ME), ki ima tudi firmware (Intel ME firmware).

Prenosni računalniki poleg naštetega zahtevajo vgrajen krmilnik (ACPI EC, Advanced Control and Power Interface Embedded Controller), ki skrbi za delovanje napajalnega podsistema, sledilne ploščice, tipkovnice, tipk Fn (svetlost zaslona, glasnost zvoka). , osvetlitev tipkovnice itd.) in druge stvari. In ima tudi svoj firmware.

Torej je celota zgornje vdelane programske opreme vdelana programska oprema računalniške platforme (sistemska vdelana programska oprema), ki je shranjena na skupnem bliskovnem pomnilniku SPI. Da uporabniki tega pomnilnika ne bodo zmedeni glede tega, kje je, je vsebina tega pomnilnika razdeljena na naslednja območja (kot je prikazano na sliki):

UEFI BIOS;
Vdelana programska oprema ACPI EC (ločena regija se je pojavila z mikroarhitekturo procesorja Skylake (2015), vendar v naravi še nismo videli primerov njene uporabe, zato je vdelana programska oprema vgrajenega krmilnika še vedno vključena v UEFI BIOS) ;
vdelana programska oprema Intel ME;
konfiguracija (naslov MAC itd.) vgrajenega omrežnega adapterja GbE (Gigabit Ethernet);
Deskriptorji Flash so glavna regija bliskovnega pomnilnika, ki vsebuje kazalce na druge regije, pa tudi dovoljenja za dostop do njih.

Za razmejitev dostopa do regij (v skladu z navedenimi dovoljenji) je odgovoren SPI bus master, v nabor čipov vgrajen SPI krmilnik, prek katerega se dostopa do tega pomnilnika. Če so dovoljenja nastavljena na priporočene vrednosti Intel (iz varnostnih razlogov), ima vsak uporabnik SPI flash poln dostop (branje/pisanje) samo do svoje regije. Ostali pa so samo za branje ali nedostopni. Dobro znano dejstvo: v mnogih sistemih ima CPE popoln dostop do UEFI BIOS in GbE, dostop za branje samo do deskriptorjev flash in sploh nima dostopa do regije Intel ME. Zakaj na mnogih in ne na vseh? Kar je priporočeno, ni potrebno. Podrobneje vam bomo povedali kasneje v članku.

Mehanizmi za zaščito programske opreme računalniške platforme pred spreminjanjem

Očitno je treba vdelano programsko opremo računalniške platforme zaščititi pred morebitnim vdorom, kar bi potencialnemu napadalcu omogočilo, da se uveljavi v njej (preživi posodobitve/ponovne namestitve OS), izvede svojo kodo v najbolj privilegiranih načinih itd. In omejevanje dostopa do regij bliskovnega pomnilnika SPI seveda ni dovolj. Zato se za zaščito vdelane programske opreme pred spremembami uporabljajo različni mehanizmi, značilni za vsako operacijsko okolje.

Tako je vdelana programska oprema Intel ME podpisana za nadzor celovitosti in pristnosti, krmilnik ME pa jo preveri vsakič, ko je naložena v pomnilnik ME UMA. O tem postopku preverjanja smo že razpravljali v enem od članki, posvečen podsistemu Intel ME.

In vdelana programska oprema ACPI EC se praviloma preverja samo za celovitost. Vendar pa zaradi dejstva, da je ta dvojiška datoteka vključena v UEFI BIOS, zanjo skoraj vedno veljajo isti zaščitni mehanizmi, kot jih uporablja UEFI BIOS. Pogovorimo se o njih.

Te mehanizme lahko razdelimo v dve kategoriji.

Zaščita pred pisanjem v območju UEFI BIOS

Fizična zaščita vsebine SPI flash pomnilnika z mostičkom za zaščito pred pisanjem;
Zaščita projekcije regije UEFI BIOS v naslovnem prostoru CPE z uporabo registrov čipov PRx;
Blokiranje poskusov pisanja v regijo UEFI BIOS z generiranjem in obdelavo ustrezne prekinitve SMI z nastavitvijo bitov BIOS_WE/BLE in SMM_BWP v registrih nabora vezij;
Naprednejša različica te zaščite je Intel BIOS Guard (PFAT).

Poleg teh mehanizmov lahko prodajalci razvijejo in izvajajo lastne varnostne ukrepe (na primer podpisovanje kapsul s posodobitvami UEFI BIOS).

Pomembno je omeniti, da na določenem sistemu (odvisno od prodajalca) morda ne bodo uporabljeni vsi zgornji zaščitni mehanizmi, morda sploh ne bodo uporabljeni ali pa bodo implementirani na ranljiv način. Več o teh mehanizmih in stanju z njihovo implementacijo si lahko preberete v ta članek. Vsem, ki jih zanima, priporočamo, da preberete celotno serijo člankov o varnosti UEFI BIOS CodeRush.

Preverjanje pristnosti UEFI BIOS

Ko govorimo o zaupanja vrednih zagonskih tehnologijah, najprej pomislimo na varen zagon. Vendar pa je arhitekturno zasnovan za preverjanje pristnosti komponent, ki so zunaj UEFI BIOS (gonilniki, zagonski nalagalniki itd.), in ne same vdelane programske opreme.

Zato je Intel v SoC z mikroarhitekturo Bay Trail (2012) implementiral strojno neonemogočen varen zagon (Verified Boot), ki nima nič skupnega z zgoraj omenjeno tehnologijo varnega zagona. Kasneje (2013) je bil ta mehanizem izboljšan in izdan pod imenom Intel Boot Guard za namizne računalnike z mikroarhitekturo Haswell.

Preden opišemo Intel Boot Guard, si poglejmo izvajalska okolja v arhitekturi Intel 64, ki so skupaj temelj zaupanja za to zaupanja vredno zagonsko tehnologijo.

Intel CPU

Cap predlaga, da je procesor glavno izvajalno okolje v arhitekturi Intel 64. Zakaj je koren zaupanja? Izkazalo se je, da je tisto, zaradi česar je takšen, posedovanje naslednjih elementov:

Microcode ROM je obstojen, neprepisljiv pomnilnik za shranjevanje mikrokode. Menijo, da je mikrokoda izvedba ukaznega sistema procesorja z uporabo najpreprostejših navodil. Zgodi se tudi v mikrokodi hrošči. Tako lahko v BIOS-u najdete binarne datoteke s posodobitvami mikrokode (prekrite med zagonom, ker ROM-a ni mogoče prepisati). Vsebina teh binarnih datotek je šifrirana, kar zelo otežuje analizo (zato specifično vsebino mikrokode poznajo le tisti, ki jo razvijajo), in podpisana za nadzor integritete in pristnosti;
AES ključ za dešifriranje vsebine posodobitev mikrokode;
zgoščena vrednost javnega ključa RSA, ki se uporablja za preverjanje podpisa posodobitev mikrokode;
Razpršitev javnega ključa RSA, ki preverja podpis kodnih modulov ACM (Authenticated Code Module), ki jih je razvil Intel, ki jih CPE lahko zažene pred izvajanjem BIOS-a (hello microcode) ali med njegovim delovanjem, ko pride do določenih dogodkov.

Intel ME

Naš blog je bil posvečen temu podsistemu dva Člen. Naj spomnimo, da to izvršljivo okolje temelji na mikrokontrolerju, vgrajenem v nabor čipov in je najbolj skrito in privilegirano v sistemu.

Intel ME je kljub svoji tajnosti tudi korenina zaupanja, saj ima:

ME ROM - obstojen pomnilnik, ki ga ni mogoče ponovno zapisovati (metoda posodabljanja ni na voljo), ki vsebuje začetno kodo in zgoščeno vrednost SHA256 javnega ključa RSA, ki preverja podpis vdelane programske opreme Intel ME;
AES ključ za shranjevanje tajnih podatkov;
dostop do nabora varovalk (FPF, Field Programmable Fuses), integriranih v nabor čipov za trajno shranjevanje nekaterih informacij, vključno s tistimi, ki jih določi prodajalec računalniškega sistema.

Intel Boot Guard 1.x

Majhna izjava o omejitvi odgovornosti. Številke različic tehnologije Intel Boot Guard, ki jih uporabljamo v tem članku, so poljubne in morda nimajo nobene zveze s številčenjem, uporabljenim v Intelovi interni dokumentaciji. Poleg tega so bile tukaj navedene informacije o izvajanju te tehnologije pridobljene med povratnim inženiringom in lahko vsebujejo netočnosti v primerjavi s specifikacijo za Intel Boot Guard, ki verjetno ne bo nikoli objavljena.

Intel Boot Guard (BG) je torej strojno podprta tehnologija preverjanja pristnosti UEFI BIOS. Sodeč po njegovem kratkem opisu v knjigi [Platform Embedded Security Technology Revealed, poglavje Boot with Integrity, or Not Boot], deluje kot zaupanja vredna zagonska veriga. In prva povezava v njem je zagonska koda (mikrokoda) znotraj procesorja, ki jo sproži dogodek RESET (ne zamenjujte ga z vektorjem RESET v BIOS-u!). CPE najde kodni modul, ki ga je razvil in podpisal Intel (Intel BG startup ACM) v bliskovnem pomnilniku SPI, ga naloži v svoj predpomnilnik, preveri (zgoraj je bilo že omenjeno, da ima CPE zgoščeno vrednost javnega ključa, ki preveri ACM podpis) in zažene.

Ta kodni modul je odgovoren za preverjanje majhnega začetnega dela UEFI BIOS - Initial Boot Block (IBB), ki pa vsebuje funkcionalnost za preverjanje glavnega dela UEFI BIOS. Tako vam Intel BG omogoča preverjanje pristnosti BIOS-a pred nalaganjem OS (kar je mogoče izvesti pod nadzorom tehnologije Secure Boot).

Tehnologija Intel BG omogoča dva načina delovanja (in eden ne moti drugega, tj. oba načina sta lahko omogočena v sistemu ali oba onemogočena).

Izmerjeni zagon

V načinu izmerjenega zagona (MB) vsaka zagonska komponenta (začenši z zagonskim ROM-om CPE) »izmeri« naslednjo z uporabo zmogljivosti TPM (Trusted Platform Module). Za tiste, ki se ne spoznate, naj pojasnim.

TPM ima PCR (registre konfiguracije platforme), v katere se zapiše rezultat operacije zgoščevanja po formuli:

Tisti. trenutna vrednost PCR je odvisna od prejšnje in ti registri se ponastavijo šele, ko je sistem RESET.

Tako v načinu MB v določenem trenutku PCR-ji odražajo edinstven (znotraj zmožnosti operacije zgoščevanja) identifikator kode ali podatkov, ki so bili »izmerjeni«. Vrednosti PCR se lahko uporabljajo v nekaterih operacijah šifriranja podatkov (TPM_Seal). Po tem bo njihovo dešifriranje (TPM_Unseal) možno le, če se vrednosti PCR niso spremenile zaradi nalaganja (tj. Niti ena "izmerjena" komponenta ni bila spremenjena).

Preverjen zagon

Najslabša stvar za tiste, ki radi spreminjajo UEFI BIOS, je način Verified Boot (VB), v katerem vsaka zagonska komponenta kriptografsko preveri celovitost in pristnost naslednje. In v primeru napake pri preverjanju se (eden od) zgodi:

zaustavitev s časovno omejitvijo od 1 minute do 30 minut (tako da ima uporabnik čas razumeti, zakaj se njegov računalnik ne zažene, in, če je mogoče, poskuša obnoviti BIOS);
takojšen izklop (tako da uporabnik nima časa razumeti, še manj narediti karkoli);
nadaljevanje dela z mirnim izrazom (tisti primer, ko ni časa za varnost, ker so pomembnejše stvari).

Izbira ukrepa je odvisna od podane konfiguracije Intel BG (in sicer od tako imenovane politike uveljavljanja), ki jo prodajalec računalniške platforme trajno zabeleži v posebej zasnovanem pomnilniku - varovalke čipov (FPF). Kasneje se bomo podrobneje posvetili tej točki.

Poleg konfiguracije prodajalec ustvari dva ključa RSA 2048 in ustvari dve podatkovni strukturi (prikazani na sliki):

Manifest korenskega ključa prodajalca (KEYM, OEM Root Key Manifest), ki vsebuje SVN (številko varnostne različice) tega manifesta, zgoščeno vrednost SHA256 javnega ključa naslednjega manifesta, javni ključ RSA (tj. javni del prodajalčev korenski ključ) za preverjanje podpisa tega manifesta in samega podpisa;
Manifest IBB (IBBM, Initial Boot Block Manifest), ki vsebuje SVN tega manifesta, zgoščeno vrednost SHA256 IBB, javni ključ za preverjanje podpisa tega manifesta in sam podpis.

Zgoščena vrednost SHA256 javnega ključa OEM Root Key je trajno zabeležena v varovalkah nabora čipov (FPF), tako kot konfiguracija Intel BG. Če konfiguracija Intel BG omogoča vključitev te tehnologije, lahko odslej samo lastnik zasebnega dela korenskega ključa OEM posodobi BIOS v tem sistemu (tj. lahko znova izračuna te manifeste), tj. prodajalec.

Ob pogledu na sliko se takoj pojavijo dvomi o potrebi po tako dolgi verigi preverjanja - lahko bi uporabili en manifest. Zakaj komplicirati?

Pravzaprav Intel tako ponuja prodajalcu možnost uporabe različnih ključev IBB za različne linije svojih izdelkov in enega kot korenski ključ. Če zasebni del ključa IBB (s katerim je podpisan drugi manifest) pušča, bo incident vplival samo na eno linijo izdelkov in le dokler prodajalec ne ustvari novega para in vključi preračunane manifeste v naslednjo posodobitev BIOS-a.

Če pa je korenski ključ (s katerim je podpisan prvi manifest) ogrožen, ga ne bo mogoče zamenjati, postopek preklica ni predviden. hash javnega dela tega ključa je programiran v FPF enkrat za vselej.

Konfiguracija Intel Boot Guard

Zdaj pa si podrobneje oglejmo konfiguracijo Intel BG in postopek njenega ustvarjanja. Če pogledate ustrezen zavihek v GUI pripomočka Flash Image Tool iz Intel System Tool Kit (STK), boste opazili, da konfiguracija Intel BG vključuje zgoščeno vrednost javnega dela korenskega ključa prodajalca, nekaj nejasne vrednosti itd. Profil Intel BG.

Struktura tega profila:

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

Na splošno je konfiguracija Intel BG zelo prilagodljiva entiteta. Razmislite na primer o zastavici Force_Boot_Guard_ACM. Ko je odstranjen, če zagonskega modula ACM BG na bliskovnem ključu SPI ni mogoče najti, ne bo prišlo do zaupanja vrednega zagona. Ne bo ji zaupala.

Zgoraj smo že zapisali, da je politiko uveljavljanja za način VB mogoče konfigurirati tako, da v primeru napake pri preverjanju pride do nezaupljivega prenosa.

Takšne stvari prepustite prodajalcem...

Pripomoček GUI ponuja naslednje »pripravljene« profile:

Ne
Način
Opis

0
št_FVME
Tehnologija Intel BG onemogočena

1
VE
Način VB je omogočen, zaustavitev po časovni omejitvi

2
VME
oba načina sta omogočena (VB in MB), zaustavitev po časovni omejitvi

3
VM
oba načina sta omogočena, brez izklopa sistema

4
Fve
Način VB omogočen, takojšnja zaustavitev

5
FVME
oba načina omogočena, takojšen izklop

Kot že omenjeno, mora prodajalec sistema enkrat za vselej zapisati konfiguracijo Intel BG v varovalke nabora čipov (FPF) - majhno (po nepreverjenih informacijah le 256 bajtov) strojno shranjevanje informacij znotraj nabora čipov, ki ga je mogoče programirati. zunaj Intelovih proizvodnih obratov (prav zato Programabilno na terenu varovalke).

Odličen je za shranjevanje konfiguracije, ker:

ima enkratno programabilno področje za shranjevanje podatkov (točno tam, kjer je zapisana konfiguracija Intel BG);
Samo Intel ME ga lahko bere in programira.

Torej, da bi nastavil konfiguracijo za tehnologijo Intel BG na določenem sistemu, prodajalec med proizvodnjo naredi naslednje:

S pomočjo pripomočka Flash Image Tool (od Intel STK) ustvari sliko vdelane programske opreme z dano konfiguracijo Intel BG v obliki spremenljivk v območju Intel ME (tako imenovano začasno zrcalo za FPF);
S pomočjo pripomočka Flash Programming Tool (od Intel STK) zapiše to sliko v bliskovni pomnilnik SPI sistema in zapre ti. način izdelave (v tem primeru je ustrezen ukaz poslan Intel ME).

Kot rezultat teh operacij bo Intel ME dodelil podane vrednosti iz zrcaljenja za FPF v regiji ME v FPF, nastavil ločljivosti v deskriptorjih SPI flash na vrednosti, ki jih priporoča Intel (opisano na začetku člen) in izvedite RESET sistema.

Analiza implementacije Intel Boot Guard

Da bi analizirali implementacijo te tehnologije na posebnem primeru, smo preverili naslednje sisteme za sledi tehnologije Intel BG:

Sistem
Obvestilo

Gigabyte GA-H170-D3H
Skylake, obstaja podpora

Gigabyte GA-Q170-D3H
Skylake, obstaja podpora

Gigabyte GA-B150-HD3
Skylake, obstaja podpora

MSI H170A Gaming Pro
Skylake, brez podpore

Lenovo ThinkPad 460
Skylake, podprto, tehnologija omogočena

Lenovo Yoga 2 Pro
Haswell, brez podpore

Lenovo U330p
Haswell, brez podpore

S »podporo« mislimo na prisotnost zagonskega modula ACM Intel BG, zgoraj omenjenih manifestov in ustrezne kode v BIOS-u, tj. izvajanje za analizo.

Kot primer vzemimo tisto, ki je bila prenesena iz pisarne. slika spletnega mesta prodajalca bliskovnega pomnilnika SPI za Gigabyte GA-H170-D3H (različica F4).

Zagonski ROM procesorja Intel

Najprej se pogovorimo o dejanjih procesorja, če je omogočena tehnologija Intel BG.

Vzorcev dešifrirane mikrokode ni bilo mogoče najti, zato je odprto vprašanje, kako so spodaj opisana dejanja izvedena (v mikrokodi ali strojni opremi). Vendar pa je dejstvo, da sodobni procesorji Intel "zmorejo" izvajati ta dejanja.

Po izstopu iz stanja RESET procesor (vsebina flash pomnilnika je že preslikana v naslovni prostor) najde tabelo FIT (Firmware Interface Table). Najti ga je enostavno, kazalec nanj je zapisan na naslovu FFFF FFC0h.

V obravnavanem primeru se na tem naslovu nahaja vrednost FFD6 9500h. Z dostopom do tega naslova procesor vidi tabelo FIT, katere vsebina je razdeljena na zapise. Prvi vnos je glava naslednje strukture:

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

Iz neznanega razloga kontrolna vsota v teh tabelah ni vedno izračunana (polje je levo nič).

Preostali vnosi kažejo na različne binarne datoteke, ki jih je treba razčleniti/izvesti, preden se izvede BIOS, tj. preden preklopite na stari vektor RESET (FFFF FFF0h). Struktura vsakega takega vnosa je naslednja:

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

Polje EntryType vam pove, na katero vrsto bloka kaže ta vnos. Poznamo več vrst:

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

Zdaj je očitno, da eden od vnosov kaže na lokacijo binarne datoteke ACM zagona Intel BG. Struktura glave te binarne datoteke je značilna za kodne module, ki jih je razvil Intel (ACM-ji, posodobitve mikrokode, odseki kode 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 naloži to dvojiško datoteko v svoj predpomnilnik, jo preveri in zažene.

Intel BG startup ACM

Kot rezultat analize dela tega ACM je postalo jasno, da počne naslednje:

prejme konfiguracijo Intel BG od Intel ME, zapisano v varovalke nabora čipov (FPF);
najde manifeste KEYM in IBBM ter ju preveri.

Za iskanje teh manifestov ACM uporablja tudi tabelo FIT, ki ima dve vrsti vnosov za označevanje strukturnih podatkov (glejte FIT_ENTRY_TYPES zgoraj).

Oglejmo si podrobneje manifeste. V strukturi prvega manifesta vidimo več nejasnih konstant, zgoščeno vrednost javnega ključa iz drugega manifesta in javni korenski ključ OEM, podpisan kot ugnezdena 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];
};

Za preverjanje javnega ključa OEM Root Key se spomnimo, da uporabljamo zgoščeno vrednost varovalk SHA256, ki smo jo na tej točki že prejeli od Intel ME.

Pojdimo k drugemu manifestu. Sestavljen je iz treh struktur:

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

Prvi vsebuje nekaj 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
};

Drugi vsebuje zgoščeno vrednost SHA256 IBB in število deskriptorjev, ki opisujejo vsebino IBB (tj. iz česa je izračunana zgoščena vrednost):

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

Deskriptorji IBB sledijo tej strukturi drug za drugim. Njihova vsebina ima naslednjo obliko:

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

Preprosto je: vsak deskriptor vsebuje naslov/velikost IBB chunka. Tako je veriženje blokov, na katere kažejo ti deskriptorji (v vrstnem redu samih deskriptorjev), IBB. In praviloma je IBB zbirka vseh modulov faz SEC in PEI.

Drugi manifest dopolnjuje struktura, ki vsebuje javni ključ IBB (preverjen z zgoščeno vrednostjo SHA256 iz prvega manifesta) in podpis tega manifesta:

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

Torej, še preden se začne izvajati UEFI BIOS, bo procesor zagnal ACM, ki bo preveril pristnost vsebine razdelkov s fazno kodo SEC in PEI. Nato procesor zapusti ACM, sledi vektorju RESET in začne izvajati BIOS.

Preverjena PEI particija mora vsebovati modul, ki bo preveril preostali BIOS (koda DXE). Ta modul že razvija IBV (Independent BIOS Vendor) ali sam prodajalec sistema. Ker Na voljo sta nam bila samo sistema Lenovo in Gigabyte, ki sta imela podporo za Intel BG; poglejmo kodo, pridobljeno iz teh sistemov.

UEFI BIOS modul LenovoVerifiedBootPei

V primeru Lenovo se je izkazalo, da gre za modul LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, ki ga je razvil Lenovo.

Njegova naloga je poiskati (po GUID) razpršitveno tabelo za DXE in preveriti 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;
};

UEFI BIOS modul BootGuardPei

V primeru Gigabyte se je izkazalo, da gre za modul BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, ki ga je razvil AMI, zato je prisoten v katerem koli BIOS-u AMI s podporo Intel BG.

Njegov algoritem delovanja je nekoliko drugačen, vendar se spušča na isto stvar:

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

Zgoščevalna tabela {389CC6F2-1EA8-467B-AB8A-78E769AE2A15}, ki jo išče, ima naslednjo obliko:

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

Na kratko spregovorimo o drugi izvedbi Intel Boot Guard, ki je bila najdena v novejšem sistemu, ki temelji na Intel SoC z mikroarhitekturo Apollo Lake - ASRock J4205-IT.

Čeprav se bo ta različica uporabljala le v sistemih na čipu (novi sistemi z mikroarhitekturo procesorja Kaby Lake še naprej uporabljajo Intel Boot Guard 1.x), je zelo zanimivo preučiti novo arhitekturno možnost za platforme Intel SoC, ki so doživele pomembne spremembe, na primer:

regiji BIOS in Intel ME (ali bolje rečeno Intel TXE, glede na terminologijo za Intel SoC) sta zdaj ena regija IFWI;
čeprav je bil Intel BG omogočen na platformi, strukture, kot so FIT, KEYM, IBBM, niso bile najdene v bliskovnem pomnilniku;
poleg jeder TXE in ISH (x86) je bilo naboru čipov dodano tretje jedro (mimogrede spet ARC) - PMC (krmilnik za upravljanje porabe), povezano z zagotavljanjem delovanja napajalnega podsistema in spremljanjem zmogljivosti.

Vsebina nove regije IFWI je sklop naslednjih modulov:

Pristranskost
ime
Opis

0000 2000h
SMIP
določeno konfiguracijo platforme, podpisano s strani prodajalca

0000 6000h
RBEP
Koda vdelane programske opreme Intel TXE, x86, podpisana Intel

0001 0000h
PMCP
Razdelek s kodo vdelane programske opreme Intel PMC, ARC, podpisan Intel

0002 0000h
FTPR
Koda vdelane programske opreme Intel TXE, x86, podpisana Intel

0007 B000h
UCOD
posodobitve mikrokode za CPE, ki jih je podpisal Intel

0008 0000h
IBBP
UEFI BIOS, faze SEC/PEI, x86, podpisan s strani prodajalca

0021 8000h
ISHC
Razdelek kode vdelane programske opreme Intel ISH, x86, podpisan s strani prodajalca

0025 8000h
NFTP
Koda vdelane programske opreme Intel TXE, x86, podpisana Intel

0036 1000h
IUNP
ni znano

0038 1000h
OBBP
UEFI BIOS, faza DXE, x86, nepodpisan

Med analizo strojne programske opreme TXE je postalo očitno, da po RESET-u TXE zadrži procesor v tem stanju, dokler ne pripravi osnovne vsebine naslovnega prostora za CPE (FIT, ACM, RESET vektor ...). Poleg tega TXE te podatke postavi v svoj SRAM, nato pa procesorju začasno omogoči dostop do tam in ga "sprosti" iz RESET-a.

Na straži pred rootkiti

No, zdaj pa preidimo na "vroče" stvari. Nekoč smo odkrili, da v mnogih sistemih SPI flash deskriptorji vsebujejo dovoljenja za dostop do regij SPI flash pomnilnika, tako da lahko vsi uporabniki tega pomnilnika pišejo in berejo katero koli regijo. Tisti. ni šans.

Po preverjanju s pripomočkom MEinfo (od Intel STK) smo videli, da način izdelave na teh sistemih ni zaprt, zato so varovalke nabora čipov (FPF) ostale v nedefiniranem stanju. Da, Intel BG v takšnih primerih ni ne vklopljen ne izklopljen.

Govorimo o naslednjih sistemih (glede na Intel BG in tisto, kar bo opisano kasneje v članku, bomo govorili o sistemih z mikroarhitekturo procesorja Haswell in višje):

vsi izdelki Gigabyte;
vsi izdelki MSI;
21 modelov Lenovo prenosnikov in 4 modeli Lenovo strežnikov.

Seveda smo o odkritju poročali tem prodajalcem, pa tudi Intelu.

Ustrezna reakcija je prišla šele iz Lenovoki je prepoznal problem in izdal popravek.

Gigabyte Zdelo se je, da so informacijo o ranljivosti sprejeli, vendar je niso komentirali.

Komunikacija z MSI popolnoma zastal pri naši zahtevi za pošiljanje vašega javnega ključa PGP (da jim pošljemo varnostno opozorilo v šifrirani obliki). Navedli so, da "so proizvajalec strojne opreme in ne proizvajajo ključev PGP."

Ampak pojdimo k bistvu. Ker so varovalke v nedoločenem stanju, jih lahko uporabnik (ali napadalec) samostojno programira (najtežje je poiščite Intel STK). Če želite to narediti, morate dokončati naslednje korake.

1. Zaženite operacijski sistem Windows (na splošno lahko spodaj opisana dejanja izvedete tudi pod Linuxom, če razvijete analog Intel STK za želeni OS). S pomočjo pripomočka MEinfo se prepričajte, da v tem sistemu niso programirane varovalke.

2. Preberite vsebino bliskovnega pomnilnika z orodjem za programiranje Flash.

3. Odprite prebrano sliko s katerim koli orodjem za urejanje UEFI BIOS, naredite potrebne spremembe (na primer uvedite rootkit), ustvarite/uredite obstoječe strukture KEYM in IBBM v regiji ME.

Slika poudarja javni del ključa RSA, katerega zgoščena vrednost bo programirana v varovalke nabora čipov skupaj s preostalo konfiguracijo Intel BG.

4. Z orodjem Flash Image Tool sestavite novo sliko vdelane programske opreme (z nastavitvijo konfiguracije Intel BG).

5. Zapišite novo sliko v bliskovni pomnilnik z orodjem za programiranje Flash in s pomočjo MEinfo preverite, ali območje ME zdaj vsebuje konfiguracijo Intel BG.

6. Uporabite orodje za programiranje Flash, da zaprete proizvodni način.

7. Sistem se bo znova zagnal, nato pa lahko uporabite MEinfo, da preverite, ali so FPF programirani.

Ta dejanja za vedno omogoči Intel BG v tem sistemu. Dejanja ni mogoče razveljaviti, kar pomeni:

Samo lastnik zasebnega dela korenskega ključa (tj. tisti, ki je omogočil Intel BG) bo lahko posodobil UEFI BIOS v tem sistemu;
če temu sistemu vrnete originalno vdelano programsko opremo, na primer s programatorjem, se ta sploh ne bo vklopil (posledica politike uveljavljanja v primeru napake pri preverjanju);
da se znebite takšnega UEFI BIOS-a, morate nabor čipov s programiranimi FPF-ji zamenjati s "čistim" (tj. ponovno spajkati nabor čipov, če imate dostop do infrardeče spajkalne postaje po ceni avtomobila, ali preprosto zamenjati matično ploščo ).

Če želite razumeti, kaj lahko naredi tak rootkit, morate oceniti, kaj omogoča izvajanje vaše kode v okolju UEFI BIOS. Recimo v najbolj privilegiranem načinu procesorja - SMM. Tak rootkit ima lahko naslednje lastnosti:

izvaja se vzporedno z OS (lahko konfigurirate obdelavo za generiranje prekinitve SMI, ki jo bo sprožil časovnik);
imajo vse prednosti delovanja v načinu SMM (poln dostop do vsebine RAM-a in strojnih virov, tajnost pred OS);
Programsko kodo rootkita je mogoče šifrirati in dešifrirati, ko ga zaženete v načinu SMM. Vse podatke, ki so na voljo samo v načinu SMM, je mogoče uporabiti kot šifrirni ključ. Na primer zgoščena vrednost iz niza naslovov v SMRAM. Če želite pridobiti ta ključ, boste morali vstopiti v SMM. In to je mogoče storiti na dva načina. Poiščite RCE v kodi SMM in ga izkoristite ali dodajte svoj modul SMM v BIOS, kar je nemogoče, saj smo omogočili Boot Guard.

Tako ta ranljivost omogoča napadalcu, da:

v sistemu ustvarite skrit rootkit, ki ga ni mogoče izbrisati, neznanega namena;
izvedite svojo kodo na enem od jeder nabora čipov znotraj Intel SoC, in sicer na Intel ISH (pozorno si oglejte sliko).

Čeprav zmožnosti podsistema Intel ISH še niso bile raziskane, se zdi, da je zanimiv vektor napada za Intel ME.

Ugotovitve

Študija je omogočila pridobitev tehničnega opisa delovanja tehnologije Intel Boot Guard. Minus nekaj skrivnosti Intelovega modela varnosti skozi obskurnost.
Predstavljen je scenarij napada, ki vam omogoča, da v sistemu ustvarite rootkit, ki ga ni mogoče namestiti.
Videli smo, da so sodobni procesorji Intel sposobni izvajati veliko lastniške kode, še preden se BIOS začne izvajati.
Platforme z arhitekturo Intel 64 postajajo vse manj primerne za poganjanje brezplačne programske opreme: preverjanje strojne opreme, vse več lastniških tehnologij in podsistemov (tri jedra v naboru čipov SoC: x86 ME, x86 ISH in ARC PMC).

Blažitve

Prodajalci, ki namenoma pustijo način izdelave odprt, ga morajo obvezno zapreti. Zaenkrat imajo zaprte le oči, kar kažejo novi sistemi Kaby Lake.

Uporabniki lahko onemogočijo Intel BG v svojih sistemih (ki so dovzetni za opisano ranljivost) tako, da zaženejo Flash Programming Tool s parametrom -closemnf. Najprej se morate prepričati (z uporabo MEinfo), da konfiguracija Intel BG v regiji ME omogoča izklop te tehnologije po programiranju v FPF.

Vir: www.habr.com

Schrödingerjev zaupanja vreden prenos. Intel Boot Guard