Schrödingeri usaldusväärne käivitamine. Intel Boot Guard

Pakume taas madalale tasemele laskuda ja rääkida x86-ühilsete arvutiplatvormide tarkvara turvalisusest. Seekord on uuringu peamine koostisosa Intel Boot Guard (ärge segage Intel BIOS Guard'iga!) – riistvara toetav usaldusväärse BIOS-i käivitamise tehnoloogia, mille tootja võib tootmisprotsessis püsivalt sisse või välja lülitada. Uuringu retsept on meile juba tuttav: uurime selle tehnoloogia rakendust tagasivaatava inseneritööga, kirjeldame selle arhitektuuri, täiendame seda dokumenteerimata detailidega, maitse järgi lisame rünnakusuundi ja segame kokku. Lisame heat lugu sellest, kuidas mitu aastat kloonitud tootmisdefekt võimaldab potentsiaalsel ründajal kasutada seda tehnoloogiat süsteemi eemaldamatuks (isegi programmidega) varjatud rootkit'ide loomiseks.

Muide, artikli põhialuseks on ettekanded "Rootkitide kaitsjad: Intel BootGuard" konverentsilt ZeroNights 2016 ja 29. kohtumine DefCon Russia (mõlemad ettekanded siin).

Intel 64 arhitektuuriga arvutiplatvormide tarkvara

Alustuseks vastame küsimusele: mis on kaasaegse Intel 64 arhitektuuriga arvutiplatvormi tarkvara? Muidugi, UEFI BIOS. Kuid selline vastus ei ole täpne. Vaatame joonist, kus on kujutatud selle arhitektuuri lauaarvuti (notebook) versioon.

Aluseks on ühendus:

• Protsessor (CPU, Central Processing Unit), kuhu lisaks põhiydedele on sisse ehitatud graafikatuum (kõikides mudelites mitte) ja mälukontroller (IMC, Integrated Memory Controller);
• Kiibistiku (PCH, Platform Controller Hub), mis sisaldab erinevaid kontrollerid perifeersete seadmete ühendamiseks ja alamsüsteemide juhtimiseks. Nende seas on kuulus Intel Management Engine (ME), millel on samuti tarkvara (Intel ME firmware).

Lauaarvutid eeldavad lisaks eeltoodule ka sisseehitatud kontrollerit (ACPI EC, Advanced Control and Power Interface Embedded Controller), mis vastutab toite-alamsüsteemi, puuteplaadi, klaviatuuri, Fn-klahvide (ekraani heledus, helitugevus, klaviatuuri valgustus jne) ja muu töökindluse eest. Ka sellel on oma tarkvara.

Nii et, loetletud püsivara kogum moodustab arvutiplatvormi püsivara (system firmware), mis on talletatud ühises SPI välkmälus. Selle mälu kasutajate segaduse vältimiseks on selle sisu jagatud järgmistesse piirkondadesse (nagu joonisel näidatud):

• UEFI BIOS;
• ACPI EC püsivara (eraldiseisev piirkond ilmus Skylake mikroarhitektuuriga (2015. aasta), kuid looduses pole me veel näinud selle kasutamise näiteid, seega sisseehitatud kontrolleri püsivara kuulub endiselt UEFI BIOSi);
• Intel ME püsivara;
• kokkuvõte (MAC-aadress jne) sisseehitatud GbE (Gigabit Ethernet) võrkaadapteri kohta;
• välkmälu kirjeldajad (Flash Descriptors) – peamine välkmälu piirkond, mis sisaldab viiteid teistele piirkondadele ning ka juurdepääsuloa õigusi neile.

Piirkondadele juurdepääsu piiramine (vastavalt määratud õigustele) toimub SPI bussi meistri kaudu – SPI-kontroller, integreeritud kiibistesse, mille kaudu sellele mälule pääsetakse. Kui õigused on seadistatud soovitatud (turvalisuse kaalutlustel) Intel'i väärtusteks, on igal SPI välkmälu kasutajal täielik (lugemine/kirjutamine) juurdepääs ainult oma piirkonnale. Ülejäänud on kas ainult lugemiseks saadaval või ei ole üldse kätte saadavad. Tuntud fakt: paljudes süsteemides on CPU-l täielik juurdepääs UEFI BIOSile ja GbE-le, lugemisõigus ainult välkmäludele, kuid Intel ME piirkonnale juurdepääsu ei ole üldse. Miks paljudes, aga mitte kõigis? Mis on soovitatav, ei ole tingimata kohustuslik. Räägime sellest lähemalt artiklis.

Arvutiplatvormi püsivara kaitse mehhanismid modifikatsioonide eest

Ilmselgelt tuleb arvutiplatvormi püsivara kaitsta võimaliku kompromiteerimise eest, mis võimaldaks potentsiaalsetel kurjategijatel selles kinnituda (kasutades süsteemiuuendusi / OS-i uuesti installimisi), käivitades oma koodi kõige privileegeeritud režiimides jne. Ja SPI välkmälu piirkondadele juurdepääsu piiramine ei ole piisav. Seetõttu kasutatakse püsivara modifikatsioonide kaitsmiseks erinevaid mehhanisme, mis on spetsiifilised iga täitmisõhkkonna jaoks.

Nii on Intel ME püsivara allkirjastatud, et kontrollida sisukuse ja autentsuse üle, ning seda kontrollib ME-kontroller igal korral, kui see laaditakse ME UMA mällu. Seda kinnitamise protsessi oleme juba käsitlenud ühes meie artikleid, mille Intel ME subsystemile.

ACPI EC püsivara kontrollitakse tavaliselt ainult terviklikkuse osas. Kuid kuna see binaar on osa UEFI BIOS-ist, kehtivad sellele peaaegu alati samad kaitsemehhanismid, mida kasutab UEFI BIOS. Räägime neist.

Need mehhanismid võib jagada kaheks kategooriaks.

Kaitse kirjutamise eest UEFI BIOS piirkonda

1. SPI välkmälu füüsiline kaitse write-protect jumperiga;
2. UEFI BIOS piirkonna projektsiooni kaitse CPU aadressiruumi PRx veebiregistrite kaudu;
3. UEFI BIOS piirkonda kirjutamise katsete blokeerimine vastava SMI katkestuse genereerimise ja töötlemise kaudu, seades BIOS_WE/BLE ja SMM_BWP bitid chipseti registrites;
4. Täpsem variant sellisest kaitset on Intel BIOS Guard (PFAT).

Lisaks nendele mehhanismidele saavad müüjad välja töötada ja rakendada oma turvameetmeid (näiteks UEFI BIOS uuenduste kapslite digitaalallkirjastamine).

Oluline on märkida, et konkreetsetes süsteemides (sõltuvalt müüjast) ei pruugi kõik eespool mainitud kaitsemehhanismid olla rakendatud, need võivad olla üldse mitte rakendatud või võivad olla haavatavalt rakendatud. Rohkem nendest mehhanismidest ja nende rakendamise olukorrast saab lugeda selles artiklis. Huvi korral soovitame tutvuda kogu UEFI BIOS turvalisuse artiklite tsükliga, mille on koostanud CodeRush.

UEFI BIOS autentsuse kontrollimine

Kui räägime usaldusväärse laadimise tehnoloogiatest, tuleb esimese asjana meelde Secure Boot. Kuid arhitektuuriliselt on see mõeldud UEFI BIOS-ist väljaspool asuvate komponentide (draiverite, laadijate jne) autentsuse kontrollimiseks, mitte ise püsivara jaoks.

Seetõttu realiseeris Intel Bay Traili mikroarhitektuuriga SoC-ides (2012. aastal) riistvaralise, väljalülitamatu Secure Boot (Verified Boot), mis ei ole seotud eespool mainitud Secure Boot tehnoloogiaga. Hiljem (2013. aastal) täiustati seda mehhanismi ja selle nime all Intel Boot Guard vabastati lauaarvutite jaoks, mille mikroarhitektuur on Haswell.

Enne Intel Boot Guard'i kirjeldamist vaatame üle Intel 64 arhitektuuri täitmisruumid, mis on samas usaldusväärsuse juured selle usaldusväärse laadimise tehnoloogia jaoks.

Intel CPU

Käp ütleb, et protsessor on Intel 64 arhitektuuri peamine täitmisruum. Miks see ka usaldusväärsuse juur on? Selgub, et selleks teeb ta selle järgmiste elementide olemasolu:

• Microcode ROM — energia sõltumatu, mittetöötav mälu mikrokoodi salvestamiseks. Arvatakse, et mikrokood on protsessori käsu süsteemi teostamine lihtsates käskudes. Mikrokoodis esineb samuti vigu. Seega leidub BIOS-is binare, mis sisaldavad mikrokoodi värskendusi (need laaditakse käivitamise ajal, kuna ROM-i ei saa ümber kirjutada). Nende binaride sisu on krüpteeritud, mis oluliselt raskendab analüüsi (seetõttu teadlikud mikrokoodi täpsest sisust on ainult need, kes seda arendavad), ja allkirjastatud, et tagada terviklikkust ja autentsust;
• AES võti mikrokoodi värskenduste sisu dekrüpteerimiseks;
• RSA avaliku võtme hash, millega kontrollitakse mikrokoodi värskenduste allkirja;
• RSA avaliku võtme hash, millega kontrollitakse Intel'i välja töötatud koodimoodulite ACM (Authenticated Code Module) allkirja, mida CPU võib käivitada enne BIOSi täitmist (tervitame mikrokoodi) või selle töö ajal, teatavate sündmuste toimumisel.

Intel ME

Sellele alamsüsteemile on meie blogis pühendatud kuni kaks artikleid. Tuletame meelde, et see käivitatav keskkond põhineb kiibistikus oleva mikroprotsessoril ja on süsteemi kõige varjatum ja privileegitud.

Hoolimata varjatusest on Intel ME samuti usaldusjuur, kuna sellel on:

• ME ROM — energia sõltumatu, mittetöötav mälu (uuendamiseks meetod ei ole ette nähtud), mis sisaldab alguskoodi ning SHA256 RSA avaliku võtme hash, millega kontrollitakse Intel ME püsivara allkirja;
• AES võti salajase teabe hoidmiseks;
• juurdepääs kiibistikusse integreeritud fusible'ide (FPFs, Field Programmable Fuses) komplektile, et püsivalt hoida teatud teavet, sealhulgas ka tootja määratud teavet arvutisüsteemis.

Intel Boot Guard 1.x

Väike käsk. Artiklis käsitletavad Intel Boot Guard tehnoloogia versioonide numbrid on tinglikud ning võivad mitte vastata sellele numbrid, mida rakendatakse Intel'i sise-dokumentatsioonis. Lisaks on siin esitatud teave selle tehnoloogia rakendamise kohta saadud pöördemeteorite kaudu ja võib sisaldada ebatäpsusi võrreldes Intel Boot Guard'i spetsifikatsiooniga, mida tõenäoliselt kunagi ei avalikustata.

Nii et, Intel Boot Guard (BG) on riistvara toetav UEFI BIOSi autentimise tehnoloogia. Lähtuvalt selle lühikesest kirjeldusest raamatus [Platform Embedded Security Technology Revealed, peatükk Boot with Integrity, or Not Boot], töötab see usaldusväärse käivitamise ahelana. Ja esimene lüli selles on käivituskoodeks (mikrokood) CPU sees, mis aktiveeritakse RESET sündmuse korral ( ära sega seda BIOSi RESET-vektoriga!). CPU leiab SPI välkmälust Intel'i poolt loodud ja allkirjastatud koodimooduli (Intel BG startup ACM), laadib selle oma vahemälu, kinnitab (üleval on juba märgitud, et CPU-l on avaliku võtme sõrmjälg, millega kontrollitakse ACM-i allkirja) ja käivitab.

See koodimoodul vastutab UEFI BIOSi väikese algosade — Algse Käivitusploki (IBB) — autentimise eest, mis omakorda sisaldab funktsionaalsust UEFI BIOSi peamise osa autentimiseks. Seega võimaldab Intel BG veenduda BIOSi autentsuses enne operatsioonisüsteemi laadimist (mis võib toimuda Secure Boot tehnoloogia järelevalve all).

Intel BG tehnoloogia hõlmab kahte töörežiimi (milles üks ei sega teist, s.t. mõlemat režiimi saab süsteemis sisse lülitada või mõlemad välja lülitada).

Measured Boot

Measured Boot (MB) režiimis "mõõdab" iga käivituskomponent (alates CPU boot ROM'ist) järgmist, kasutades TPM (Trusted Platform Module) funktsioone. Neile, kes ei tea, selgitame.

TPM-il on PCR-id (Platform Configuration Registers), kuhu salvestatakse hüvitisoperatsiooni tulemus valemiga:

Seega sõltub praegune PCR-i väärtus eelnevast, samas kui need registrid nullitakse ainult süsteemi RESETimise korral.

Seega, MB režiimis peegeldavad PCR-id teatud hetkel ainulaadset (hüvitamisoperatsiooni võimaluste piires) koodi või andmete identifikaatorit, mida "mõõdeti". PCR-i väärtusi saab kasutada mõnedel andmete krüpteerimisoperatsioonidel (TPM_Seal). Pärast seda on nende dekrüpteerimine (TPM_Unseal) võimalik ainult siis, kui PCR-i väärtused käivitamise tulemusel ei ole muutunud (s.t. ühtegi "mõõdetud" komponenti ei ole muudetud).

Verified Boot

Kõige hirmutavam UEFI BIOSi modifitseerijatele on Verified Boot (VB) režiim, kus iga käivituskomponent kontrollib krüptograafiliselt järgmise terviklikkust ja autentsust. Ja juhul, kui kinnitamine ebaõnnestub, toimub üks järgmistest:

• aja alajamisku aeg 1 minutist 30 minutini (et kasutaja saaks aru, miks tema arvuti ei käivitu ja, kui võimalik, prooviks BIOS-i taastada);
• kohene väljalülitus (et kasutaja ei saaks midagi aru ja veel vähem midagi teha);
• töötamine rahuliku näoga (see on olukord, kus turvalisus ei ole prioriteet, sest on olulisemaid asju).

Tegevuse valik sõltub määratud Intel BG konfiguratsioonist (nimelt nn enforcement policy), mis on platvormi tootja poolt püsivalt salvestatud spetsiaalsesse salvestuspaika – kiibistikufuusidesse (FPF). Räägime sellest punktist hiljem rohkem.

Lisaks konfiguratsioonile genereerib tootja kaks RSA 2048 võtme ja loob kaks andmestruktuuri (nagu on kujutatud joonisel):

1. Tootja juurvõtme manifest (KEYM, OEM Root Key Manifest), kuhu paigutatakse selle manifesti SVN (Security Version Number), järgmise manifesti SHA256 räsiväärtus, RSA avalik võti (st tootja juurvõtme avalik osa) selle manifesti allkirja kontrollimiseks ja allkiri ise;
2. IBB manifest (IBBM, Initial Boot Block Manifest), kuhu paigutatakse selle manifesti SVN, IBB SHA256 räsiväärtus, avalik võti selle manifesti allkirja kontrollimiseks ja allkiri ise.

OEM Root Key avaliku võtme SHA256 räsiväärtus salvestatakse püsivalt kiibistikufuusidesse (FPF), nagu ka Intel BG konfiguratsioon. Kui Intel BG konfiguratsioon hõlmab selle tehnoloogia sisselülitamist, siis alates sellest hetkest saab BIOS-i uuendada (st neid manifeste uuesti arvutada) ainult OEM Root Key privaatosa omanik, st tootja.

Pildi vaatamisel tekivad kohe kahtlused, kas selline pikk valideerimise ahel on vajalik – oleks võinud kasutada ühte manifesti. Miks keeruliseks muuta?

Tegelikult annab Intel tootjale võimaluse kasutada erinevaid IBB võtmeid oma toodete erinevate seeriate jaoks ja ühte – juurena. Kui IBB võtme privaatosa (millega allkirjastatakse teine manifest) lekib, mõjutab see ainult ühte tootesarja ja ainult seni, kuni tootja genereerib uue paari ja lisab ümber arvutatud manifestid järgmise BIOS-i uuenduse juurde.

Kuid kui juurvõti (millega esimene manifest allkirjastatakse) on kompromiteeritud, ei saa seda asendada, kuna revokatsiooni protseduure ei ole ette nähtud, kuna selle võtme avaliku osa räsi programmeeritakse FPF-ides ühe korra ja igaveseks.

Intel Boot Guardi konfiguratsioon

Nüüd peatume detailselt Intel BG konfiguratsioonil ja selle loomise protsessil. Kui vaadata vastavat vahekaarti Intel System Tool Kit (STK) komplekti Flash Image Tooli kasutajaliideses, võib märgata, et Intel BG konfiguratsioon sisaldab müüja juurvõtme avaliku osa räsi, paar arusaamatut väärtust ja nn Intel BG profiili.

Selle profiili struktuur:

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 – ei tee midagi
                                              // 01b – väljalülitus ajastusega
                                              // 11b – kohe väljalülitus
	unsigned long : 26;
};

Üldiselt on Intel BG konfiguratsioon väga paindlik. Võtame näiteks lipu Force_Boot_Guard_ACM. Kui see on välja lülitatud, siis juhul, kui BG startup ACM-i moodulit SPI sealülitusmälu ei leita, ei toimu usaldusväärset käivitamist. Toimub usaldusväärne.

Oleme juba varem kirjutanud, et VB-režiimi jõustamispoliitikat saab seadistada nii, et verifitseerimisvea korral toimub taas usaldusväärne käivitamine.

Seda tuleb jätta müüjate otsustada...

Kasutajaliidese utiliit sisaldab järgmisi 'valmis' profiile:

Number
Režiim
Kirjeldus

0
No_FVME
Intel BG tehnoloogia on välja lülitatud

1
VE
VB režiim on sisse lülitatud, väljalülitus ajastusega

2
VME
Mõlemad režiimid on sisse lülitatud (VB ja MB), väljalülitus ajastusega

3
VM
Mõlemad režiimid on sisse lülitatud, ilma süsteemi väljalülitamiseta

4
FVE
VB režiim on sisse lülitatud, kohene väljalülitus

5
FVME
Mõlemad režiimid on sisse lülitatud, kohene väljalülitus

Nagu juba mainitud, peab Intel BG konfiguratsioon olema üks kord ja igaveseks süsteemi müüja poolt salvestatud kiibisti füüsi (FPF-ide) sisse – väike (uskumatute andmete kohaselt vaid 256 baiti) riistvaraline teabehoidla kiibisti sees, mida saab programmeerida väljaspool ettevõtte Intel tootmisvõimsust (seega on see Field Programmable Fuses).

See sobib suurepäraselt konfiguratsiooni hoidmiseks, sest:

• omab ühekordselt programmeeritavat ala andmete hoidmiseks (just sinna salvestatakse Intel BG konfiguratsioon);
• ainult Intel ME võib seda lugeda ja programmeerida.

Nii, et seadistada Intel BG tehnoloogia konfiguratsioon konkreetsele süsteemile, teeb tootja tootmisprotsessi ajal järgmist:

1. Intel STK-st pärit Flash Image Tool utiliidi abil luuakse firmware'i pilt, kus on määratletud Intel BG konfiguratsioon Intel ME piirkonna muutujates (nn ajutine peegeldus FPF-ide jaoks);
2. Intel STK-st pärit Flash Programming Tool utiliidi abil kirjutatakse see pilt süsteemi SPI mälule ja suletakse nn tootmisrežiim (samal ajal saadetakse vastav käsk Intel ME-le).

Nende toimingute tulemusena kinnitab Intel ME FPF-ides näidatud väärtused peegeldusest ME piirkonnas, määrab SPI mälupöörduslube soovitatud Intel'i väärtusteks (kuidas see artikli alguses kirjeldatud) ja teostab süsteemi RESET-i.

Intel Boot Guard'i rakenduse analüüs

Kuna selle tehnoloogia rakenduse analüüsimiseks kontrollisime järgmisi süsteeme Intel BG jälgede olemasolu osas:

Süsteem
Märkus

Gigabyte GA-H170-D3H
Skylake, tugi olemas

Gigabyte GA-Q170-D3H
Skylake, tugi olemas

Gigabyte GA-B150-HD3
Skylake, tugi olemas

MSI H170A Gaming Pro
Skylake, tugi puudub

Lenovo ThinkPad 460
Skylake, tugi olemas, tehnoloogia sisse lülitatud

Lenovo Yoga 2 Pro
Haswell, tugi puudub

Lenovo U330p
Haswell, tugi puudub

Allpool mõistetakse ‘toetust’ Intel BG käivitamise ACM mooduli, ülalmainitud manifestide ja BIOS-is oleva vastava koodi olemasolu, st rakendust analüüsimiseks.

Näiteks võtame Gigabyte GA-H170-D3H (versioon F4) tootja ametlikult veebisaidilt alla laaditud SPI mälupildi.

Intel CPU boot ROM

Esiteks räägime protsessori tegevustest, kui Intel BG tehnoloogia on aktiveeritud.

Dešifreeritud mikrokoodi näidiseid ei leidunud, seega on see, kuidas allpool kirjeldatud tegevused on rakendatud (mikrokoodis või riistvara tasandil) avatud küsimus. Siiski, see, et tänapäevased Intel protsessorid suudavad neid toiminguid teostada – on fakt.

Pärast RESET-olekust väljumist leiab protsessor (kelle aadressiruumis on juba mappitud mälusisaldus) FIT tabeli (Firmware Interface Table). Selle leidmine on lihtne, viidatakse sellele aadressil FFFF FFC0h.

Antud näite puhul asub sellel aadressil väärtus FFD6 9500h. Selle aadressi poole pöördudes näeb protsessor FIT tabelit, mille sisu on jagatud sissekanneteks. Esimene sissekanne on järgmise struktuuri pealkiri:

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_’
	unsigned long  NumEntries; // sh FIT päise sissekanne
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

Tundmatu põhjusel ei ole kontrolsummat nendes tabelites alati arvutatud (väli on jäetud nulliks).

Ülejäänud kirjed viitavad erinevatele binaarfailidele, mis tuleb analüüsida/teostada enne BIOSi käivitamist, st enne üleminekut pärandi RESET-vektorile (FFFF FFF0h). Iga sellise kirje struktuur on järgmine:

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

Väli EntryType näitab ploki tüüpi, millele see eelmine kirje viitab. Meil on teada mitmeid tüüpe:

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

Nüüd on selge, et üks kirje viitab Intel BG käivitamise ACM binaari asukohale. Selle binaari pealkirja struktuur on tüüpiline Inteli välja töötatud koodimoodulite (ACM-id, mikrokoodi uuendused, Intel ME koodimoodulid jne) jaoks.

typedef struct BG_ACM_HEADER
{
	unsigned short ModuleType;     // 2
	unsigned short ModuleSubType;  // 3
	unsigned long  HeaderLength;   // sõnavormingus
	unsigned long  : 32;
	unsigned long  : 32;
	unsigned long  ModuleVendor;   // 8086h
	unsigned long  Date;           // BCD formaadis
	unsigned long  TotalSize;      // sõnavormingus
	unsigned long  unknown1[6];
	unsigned long  EntryPoint;
	unsigned long  unknown2[16];
	unsigned long  RsaKeySize;     // sõnavormingus
	unsigned long  ScratchSize;    // sõnavormingus
	unsigned char  RsaPubMod[256];
	unsigned long  RsaPubExp;
	unsigned char  RsaSig[256];
};

Protsessor laadib selle binaari oma vahemällu, valideerib selle ja käivitab.

Intel BG käivitus ACM

Selle ACM-i töö analüüsi tulemusena selgus, et see teeb järgmist:

• saab Intel ME-lt Intel BG konfiguratsiooni, mis on salvestatud chipseti fusioonidesse (FPF-id);
• leiab KEYM ja IBBM manifestid, valideerib need.

Nende manifestide leidmiseks kasutab ACM samuti FIT tabelit, milles on määratud kaks tüüpi kirjeid, mis viitavad andmestruktuurile (vt FIT_ENTRY_TYPES kiirelt üle).

Peatuge mõneks ajaks manifestide juures. Esimese manifesti struktuuris näeme mitmeid ebaselgeid konstante, teise manifesti avaliku võtme räsi ja OEM Root Key avalikku võtit koos allkirjaga sisemises struktuuris:

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

OEM Root Key avalike avaliku võtme verifitseerimiseks kasutatakse SHA256 koodi, mis on antud hetkel juba saadud Intel ME-lt.

Liigume edasi teise mansiifi juurde. See koosneb kolmest struktuurist:

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Käivituspoliiid
	IBBS Ibbs;         // IBB kirjeldus
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // IBBM allkiri
};

Esimeses – mõned konstantid:

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

Teises on SHA256 hash IBB ja number deskriptoritest, mis kirjeldavad IBB sisu (st. mida arvestatakse hash'ina):

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

IBB-deskriptorid järgivad seda struktuuri, üks teise järel. Nende sisu on järgmise vormiga:

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

Kõik on lihtne: iga deskriptor sisaldab IBB tüki aadressi/suureust. Seega on nende deskriptorite (oma asukoha järjekorras) näidatud plokkide konkateneerimine IBB. Ja reeglina on IBB kõigi SEC ja PEI faasi moodulite kogum.

Teine mansiif lõpetab struktuur, mis sisaldab IBB avalikku võtit (verifitseerib SHA256 hash'iga esimesest mansiifiz) ja selle mansiifi allkirja:

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

Seega, enne UEFI BIOS täitmise algust käivitab protsessor ACM-i, mis kontrollib SEC- ja PEI-faasi koodiosade sisu autentsust. Edasi liigub protsessor ACM-ist, läheb RESET-vektorisse ja hakkab BIOS-i täitma.

Verifitseeritud PEI jaotises peab olema moodul, mis kontrollib BIOS-i ülejäänud osa (DXE kood). Selle mooduli arendab IBV (Independent BIOS Vendor) või süsteemi tootja ise. Kuna välja tulnud süsteemid, mis toetavad Intel BG-d, olid ainult Lenovo ja Gigabyte, vaatleme koodi, mis on saadud just neist süsteemidest.

UEFI BIOS moodul LenovoVerifiedBootPei

Lenovo puhul osutus see mooduliks LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, mille on välja töötanud Lenovo.

Selle töö seisneb (GUID järgi) DXE jaoks hash-tabeli leidmises ja DXE verifitseerimises.

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

Hash-tabel {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} on järgmise formaadiga:

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 moodul BootGuardPei

Gigabyte puhul osutus see mooduliks BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, mille on välja töötanud AMI, seega on see igas AMI BIOS-is, mis toetab Intel BG-d.

Selle algoritm on pisut erinev, kuid kokkuvõttes on selle tööpõhimõte sama:

int bootMode = EFI_PEI_SERVICES->GetBootMode();

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

Hash-tabel {389CC6F2-1EA8-467B-AB8A-78E769AE2A15}, mida ta otsib, on järgmise formaadiga:

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äägime lühidalt veel ühest Intel Boot Guard rakendusest, mis leiti uuemas süsteemis, mis põhineb Intel SoC-l mikroarhitektuuriga Apollo Lake — ASRock J4205-IT.

Kuigi seda versiooni rakendatakse ainult SoC-del (uued süsteemid protsessorite mikroarhitektuuriga Kaby Lake kasutavad endiselt Intel Boot Guard 1.x), on see huvitav uuringu allikaks uue arhitektuuri variandi kohta Intel SoC platvormides, kus on toimunud märgatavad muudatused, näiteks:

• BIOS ja Intel ME (täpsemalt Intel TXE, vastavalt terminoloogiale Intel SoC-i jaoks) on nüüd üks IFWI piirkond;
• kuigi platvormil oli lubatud Intel BG, selliseid struktuure nagu FIT, KEYM, IBBM ei leitud välkmälust;
• kui TXE ja ISH kiipe (x86) on lisatud kolmas kiip (jällegi ARC, muide) – PMC (Power Management Controller), mis on seotud toitesüsteemi töökindluse ja jõudluse jälgimisega.

Uue IFWI piirkonna sisu koosneb järgmistest moodulitest:

Positiivne
Name
Kirjeldus

0000 2000h
SMIP
mingi platvormi konfiguratsioon, allkirjastatud tarnija poolt

0000 6000h
RBEP
Intel TXE, x86 süsteemifaili koodilõik, allkirjastatud Intel

0001 0000h
PMCP
Intel PMC, ARC süsteemifaili koodilõik, allkirjastatud Intel

0002 0000h
FTPR
Intel TXE, x86 süsteemifaili koodilõik, allkirjastatud Intel

0007 B000h
UCOD
CPU mikrokoodiuuendused, allkirjastatud Intel

0008 0000h
IBBP
UEFI BIOS, SEC/PEI faasid, x86, allkirjastatud tarnija poolt

0021 8000h
ISHC
Intel ISH süsteemifaili koodilõik, x86, allkirjastatud tarnija poolt

0025 8000h
NFTP
Intel TXE, x86 süsteemifaili koodilõik, allkirjastatud Intel

0036 1000h
IUNP
teadmata

0038 1000h
OBBP
UEFI BIOS, DXE faas, x86, allkirjastamata

TXE firmavara analüüsi käigus selgus, et pärast RESET-i hoiab TXE protsessorit selles olekus kuni see valmistab ette CPU aadressiruumi põhilise sisu (FIT, ACM, RESET-vektor ...). Lisaks paigutab TXE need andmed enda SRAM-i, andes pärast seda protsessorile ajutise juurdepääsu sinna ja "vabastab" selle RESET-ist.

Rootkitide kaitsel

Kuid nüüd liigume "kuumale" teemale. Ühel päeval avastasime, et paljude süsteemide SPI välkmälu kirjeldustes on salvestatud juurdepääsuõigused SPI välkmälu piirkondadele nii, et kõik selle mälu kasutajad saavad kirjutada ja lugeda igasuguseid piirkondi. See tähendab, et mingit juurdepääsu ei olnud.

Kontrollides Intel STK tööriista MEinfo abil, nägime, et nende süsteemide tootmisrežiim ei olnud suletud, seega jäeti kiibistiku füüsi (FPF) määratlemata olekusse. Jah, Intel BG ei olnud niisugustes olukordades ei sisse lülitatud ega välja lülitatud.

Rääkides järgmistes süsteemidest (Intel BG kohta ja sellest, mis käesolevas artiklis edasi tuleb, räägime Haswell ja uuemate protsessori mikroarhitektuuridega süsteemidest):

• kõik Gigabyte tooted;
• kõik MSI tooted;
• 21 Lenovo sülearvuti mudelit ja 4 Lenovo serveri mudelit.

Muidugi, teavitasime neist avastustest neid tarnijaid ja ka Intelit.

Adekvaatne reaktsioon järgnes ainult Lenovolt, kes tunnustasid probleemi ja väljastasid plaane.

Gigabyte näiliselt võtsid nad teavet haavatavuse kohta vastu, kuid ei kommenteerinud seda.

Suhtlus MSI-ga meie palve saata oma avalik PGP-võti (et saata neile turvateade krüpteeritud kujul) on täiesti peatunud. Nad väidavad, et "on seadmete tootja ja PGP-võtmeid ei tooteta".

Aga läheme asja juurde. Kuna fusid on jäänud määramata, saab kasutaja (või kurjategija) need ise programmeerida (kõige keerulisem on leida Intel STK). Selleks tuleb teha järgmised toimingud.

1. Käivita Windowsi operatsioonisüsteem (üldiselt saab järgnevate sammude teha ka Linuxi alt, kui arendada Intel STK-le sarnane lahendus vajalikule OS-ile). Kasutades MEinfo utiliiti, veendu, et sellel süsteemil ei ole fusid programmeeritud.

2. Loe välkmälu sisu Flash Programming Tool abil.

3. Ava loetud pilt mistahes UEFI BIOS-i redigeerimise vahendiga, tee vajalikud muudatused (näiteks implementeeri rootkit), loo/muuda olemasolevaid struktuure KEYM ja IBBM ME piirkonnas.

Pildil on esiletõstetud RSA võtme avalik osa, mille hash programmeeritakse chipseti fusidesse koos ülejäänud Intel BG konfiguratsiooniga.

4. Kogu Flash Image Tool abil uus pildifail kokku (määrates Intel BG konfiguratsiooni).

5. Kirjuta uus pildifail välkmällu Flash Programming Tool abil, veendu MEinfo abil, et ME piirkond sisaldab nüüd Intel BG konfiguratsiooni.

6. Sulge tootmisrežiim Flash Programming Tool abil.

7. Süsteem taaskäivitub, pärast mida saab MEinfo abil veenduda, et FPF-id on nüüd programmeeritud.

Need toimingud lülitavad Intel BG igaveseks sellele süsteemile. Tegu ei saa olema tagasi võetud, mis tähendab:

• et sellel süsteemil saab UEFI BIOS-i värskendada ainult see, kellel on juurvõtme privaatne osa (st kes lülitas Intel BG sisse);
• kui selle süsteemi originaal firmware tagastatakse näiteks programmeerija kaudu, ei lülitu see isegi sisse (tulemus poliitika jõustamisest verifitseerimise vea korral);
• sellest UEFI BIOS-ist vabanemiseks tuleb asendada chipset programmeeritud FPF-idega "puhta" (st kui sul on juurdepääs autot väärt infrapuna jootmisjaamale, või lihtsalt asendada emaplaat).

Ettekujutamiseks, mida selline rootkit võib korda saata, tuleb hinnata, mis annab võimaluse käivitada oma kood UEFI BIOS-is. Öelgem, et kõige privileegeeritud protsessorirežiimis – SMM. Sellisel rootkitil võivad olla järgmised omadused:

• käivituda paralleelselt OS-iga (saab seadistada töötama SMI katkestuse genereerimise järgi, mis aktiveeritakse ajastuse järgi);
• omada kõiki SMM-režiimi eeliseid (täielik juurdepääs RAM-i sisule ja riistvarale, OS-ist varjamine);
• rootkiti programmikood võib olla salajases vormis ja dekrüpteeritakse käivitamisel SMM-režiimis. Krüpteerimise võtmena võib kasutada mis tahes andmeid, mis on saadaval ainult SMM-režiimis. Näiteks, SMRAM-i aadresside komplekti hash. Selle võtme saamiseks tuleb siseneda SMM-i. Seda saab teha kahel viisil. Leida RCE SMM koodis ja seda ära kasutada või lisada BIOS-i oma SMM-modul, mis ei ole võimalik, kuna oleme lülitanud sisse Boot Guard.

Seega võimaldab see haavatavus ründajal:

• luua süsteemis peidetud, kustutamatut rootkitit tundmatu eesmärgiga;
• käivitada oma kood Intel SoC-i sees ühe kiibi tuumades, nimelt Intel ISH-s (vaatame pilti tähelepanelikult).

Kuigi Intel ISH alamsüsteemi võimalusi ei ole veel uuritud, tundub see olevat huvitav rünnaku suund Intel ME-le.

Järeldused

1. Uuring võimaldas saada tehnilise kirjelduse Intel Boot Guard tehnoloogia tööst. Intel'i mudeli obscurity kaudu turvalisus pole kuigi ahvatlev.
2. Esitletud on rünnaku stsenaarium, mis võimaldab luua süsteemis kustutamatut rootkit'i.
3. Oleme näinud, et tänapäevased Intel'i protsessorid suudavad käivitada palju patenteeritud koodi enne BIOS-i alustamist.
4. Intel 64 arhitektuuriga platvormid muutuvad üha vähem sobivaks vabatahtliku tarkvara käivitamiseks: riistvaraline kinnitamine, üha kasvav hulk patenteeritud tehnoloogiaid ja alamsüsteeme (kolm tuuma SoC kiibistikus: x86 ME, x86 ISH ja ARC PMC).

Leevendused

Tootjatele, kes jätavad tahtlikult tootmisrežiimi avatuks, tuleks see kindlasti kinni panna. Praegu suletakse ainult silmad ja uued Kaby Lake süsteemid näitavad seda.

Kasutajad saavad oma süsteemides (mis on vastuvõtlikud eespool mainitud haavatavusele) Intel BG ise välja lülitada, käivitades Flash Programming Tooli parameetriga -closemnf. Enne seda tuleks veenduda (MEinfo abil), et Intel BG konfigureerimine ME piirkonnas võimaldab tõepoolest selle tehnoloogia väljalülitamist pärast FPF-ides programmeerimist.

Allikas: habr.com