Teeme ettepaneku minna uuesti madalale tasemele ja rääkida püsivara x86-ga ühilduvate arvutiplatvormide turvalisusest. Seekord on uurimistöö peamiseks koostisosaks Intel Boot Guard (mitte segi ajada Intel BIOS Guardiga!) – riistvaratoega BIOS-i usaldusväärne alglaadimistehnoloogia, mille arvutisüsteemi müüja saab tootmisfaasis püsivalt lubada või keelata. Noh, me juba teame uurimisretsepti: lõigake selle tehnoloogia rakendamine peeneks pöördprojekteerimise teel, kirjeldage selle arhitektuuri, täites selle dokumenteerimata detailidega, maitsestage seda maitse järgi ründevektoritega ja segage seda. Lisame tuld looga sellest, kuidas aastaid mitme müüja tootmises tekkinud kloonitud viga võimaldab potentsiaalsel ründajal selle tehnoloogia abil luua peidetud juurkomplekti, mida ei saa (isegi programmeerija) süsteemist eemaldada.
Muide, artikkel põhineb konverentsi ettekannetel “On Guard for Rootkits: Intel BootGuard” ja 29. kohtumine (mõlemad ettekanded ).
Intel 64 arhitektuuriga arvutiplatvormi püsivara
Alustuseks vastame küsimusele: milline on Intel 64 arhitektuuriga kaasaegse arvutiplatvormi püsivara? Muidugi UEFI BIOS. Kuid see vastus ei ole täpne. Vaatame joonist, mis näitab selle arhitektuuri lauaarvuti (sülearvuti) versiooni.
Link on aluseks:
- Protsessor (CPU, Central Processing Unit), millel on lisaks põhituumadele sisseehitatud graafikatuum (mitte kõigil mudelitel) ja mälukontroller (IMC, Integrated Memory Controller);
- Kiibistik (PCH, Platform Controller Hub), mis sisaldab erinevaid kontrollereid välisseadmetega suhtlemiseks ja alamsüsteemide haldamiseks. Nende hulgas on kurikuulus Intel Management Engine (ME), millel on ka püsivara (Intel ME püsivara).
Sülearvutid vajavad lisaks ülaltoodule integreeritud kontrollerit (ACPI EC, Advanced Control and Power Interface Embedded Controller), mis vastutab toite alamsüsteemi, puuteplaadi, klaviatuuri, Fn-klahvide (ekraani heledus, helitugevus, klaviatuur) toimimise eest. taustvalgus jne) ja palju muud. Ja tal on ka oma püsivara.
Seega on ülaltoodud püsivara kombinatsioon arvutiplatvormi püsivara (süsteemi püsivara), mis on salvestatud ühisele SPI-välkmällule. Et selle mälu kasutajad ei satuks segadusse, kus keegi valetab, on selle mälu sisu jagatud järgmisteks piirkondadeks (nagu on näidatud joonisel):
- UEFI BIOS;
- ACPI EC püsivara (eraldi piirkond ilmus Skylake'i protsessori mikroarhitektuuriga (2015), kuid looduses pole me selle kasutamise näiteid veel näinud, seega on manustatud kontrolleri püsivara endiselt osa UEFI BIOS-ist);
- Intel ME püsivara;
- sisseehitatud GbE (Gigabit Ethernet) võrguadapteri konfigureerimine (MAC-aadress jne);
- välkmälude deskriptorid – välkmälu põhipiirkond, mis sisaldab viiteid teistele piirkondadele ja ka neile juurdepääsuõigusi.
Piirkondadele juurdepääsu diferentseerimisega (vastavalt määratud õigustele) tegeleb SPI siini juht - kiibikomplekti sisseehitatud SPI-kontroller, mille kaudu sellele mälule juurdepääsetakse. Kui õigused on seatud Inteli (turvakaalutlustel) soovitatud väärtustele, on igal SPI-välgu kasutajal täielik juurdepääs (lugemine/kirjutamine) ainult oma piirkonnale. Ülejäänud on kas kirjutuskaitstud või kättesaamatud. Tuntud fakt: paljudes süsteemides on CPU-l täielik juurdepääs UEFI BIOS-ile ja GbE-le, lugemisõigus ainult välklambi deskriptoritele ja puudub juurdepääs Intel ME piirkonnale. Miks paljud ja mitte kõik? Soovitatav on valikuline. Me räägime teile hiljem artiklis.
Arvutiplatvormi püsivara muutmise eest kaitsmise mehhanismid
Ilmselt peaks arvutiplatvormi püsivara olema kaitstud võimalike kompromisside eest, mis võimaldaks potentsiaalsel ründajal selles jalad alla saada (OS-i värskendused / uuesti installimised üle elada), oma koodi kõige privilegeeritud režiimides käivitada jne. Ja SPI välkmälu piirkondadele juurdepääsu piiramisest muidugi ei piisa. Seetõttu kasutatakse püsivara kaitsmiseks muudatuste eest erinevaid igale täitmiskeskkonnale omaseid mehhanisme.
Seega on Intel ME püsivara terviklikkuse ja autentsuse kontrollimiseks allkirjastatud ning ME-kontroller kontrollib seda iga kord, kui see ME UMA mällu laaditakse. Oleme seda kinnitamisprotsessi juba ühes artiklis arutanud pühendatud Intel ME alamsüsteemile.
Ja ACPI EC püsivara kontrollitakse reeglina ainult terviklikkuse osas. Kuid kuna see kahendfail on UEFI BIOS-is kaasatud, kehtivad sellele peaaegu alati samad kaitsemehhanismid, mida kasutab UEFI BIOS. Räägime neist.
Need mehhanismid võib jagada kahte kategooriasse.
Kirjutamiskaitse UEFI BIOS-i piirkonda
- SPI-välkmälu sisu füüsiline kaitse kirjutuskaitsega hüppajaga;
- UEFI BIOS-i piirkonna projektsiooni kaitsmine protsessori aadressiruumis, kasutades kiibistiku PRx-registreid;
- UEFI BIOS-i piirkonda kirjutamise katsete blokeerimine, genereerides ja töötledes vastava SMI katkestuse, määrates kiibistiku registrites bitid BIOS_WE / BLE ja SMM_BWP;
- Selle kaitse täiustatud versioon on Intel BIOS Guard (PFAT).
Lisaks nendele mehhanismidele saavad müüjad välja töötada ja rakendada oma turvameetmeid (näiteks allkirjastada kapslid UEFI BIOS-i värskendustega).
Oluline on märkida, et konkreetses süsteemis (olenevalt müüjast) ei pruugita kõiki ülaltoodud kaitsemehhanisme rakendada, neid ei pruugita üldse rakendada või need võivad olla rakendatud haavataval viisil. Lisateavet nende mehhanismide ja nende rakendamise olukorra kohta saate lugeda . Huvilistel soovitame lugeda kogu artiklite seeriat UEFI BIOS-i turvalisuse kohta .
UEFI BIOS-i autentimise kontrollimine
Kui räägime usaldusväärsetest alglaadimistehnoloogiatest, tuleb esimese asjana meelde Secure Boot. Kuid arhitektuuriliselt on see loodud UEFI BIOS-i väliste komponentide (draiverid, laadijad jne), mitte püsivara enda autentimiseks.
Seetõttu juurutas Intel Bay Trail mikroarhitektuuriga (2012) SoC-des riistvaralise mittelülitatava Secure Boot (Verified Boot), millel pole eelmainitud Secure Boot tehnoloogiaga midagi pistmist. Hiljem (2013) seda mehhanismi täiustati ja Intel Boot Guard nime all lasti see välja Haswelli mikroarhitektuuriga lauaarvutitele.
Enne Intel Boot Guardi kirjeldamist vaatame Intel 64 arhitektuuri käitusaegu, mis koos on selle usaldusväärse alglaadimistehnoloogia usalduse juured.
Intel CPU
Cap viitab sellele, et protsessor on Intel 64 arhitektuuri peamine täitmiskeskkond. Miks on see ka usalduse juur? Selgub, et järgmiste elementide omamine muudab selle selliseks:
- Mikrokoodi ROM on püsiv, mitteümberkirjutatav mälu mikrokoodi salvestamiseks. Arvatakse, et mikrokood on protsessori juhiste süsteemi rakendamine kõige lihtsamate juhiste järgi. Juhtub ka mikrokoodis . Nii et BIOS-ist leiate mikrokoodivärskendustega binaarfaile (need on alglaadimise ajal peal, kuna ROM-i ei saa üle kirjutada). Nende binaarfailide sisu on krüpteeritud, mis raskendab analüüsi oluliselt (seetõttu on mikrokoodi konkreetne sisu teada ainult selle väljatöötajatele) ning terviklikkuse ja autentsuse kontrollimiseks allkirjastatud;
- AES-võti mikrokoodivärskenduste sisu dekrüpteerimiseks;
- RSA avaliku võtme räsi, mis kontrollib mikrokoodide värskenduste allkirja;
- RSA avaliku võtme räsi, mis kontrollib Inteli väljatöötatud ACM (Authenticated Code Module) koodimoodulite signatuuri, mida CPU saab käivitada enne BIOS-i käivitumist (tere mikrokood) või selle töö ajal, kui ilmnevad mingid sündmused.
Intel ME
See meie ajaveebi alamsüsteem oli pühendatud . Tuletame meelde, et see käivitatav keskkond põhineb kiibikomplekti sisseehitatud mikrokontrolleril ning on süsteemis kõige peidetum ja privilegeeritum.
Vaatamata vargusele on Intel ME ka usalduse juur, kuna sellel on:
- ME ROM - püsiv, mitteümberkirjutatav mälu (värskendusmeetodit ei pakuta), mis sisaldab stardikoodi ja RSA avaliku võtme SHA256 räsi, mis kontrollib Intel ME püsivara allkirja;
- AES-võti salajase teabe salvestamiseks;
- juurdepääs kiibikomplekti integreeritud kaitsmete komplektile (FPF-id, Field Programmable Fuse) teatud teabe, sealhulgas arvutisüsteemi müüja määratud teabe alaliseks salvestamiseks.
Intel Boot Guard 1.x
Väike lahtiütlus. Selles artiklis kasutatavad Intel Boot Guard tehnoloogia versiooninumbrid on suvalised ja neil ei pruugi olla midagi pistmist Inteli sisedokumentatsioonis kasutatava nummerdamisega. Lisaks saadi siin antud teave selle tehnoloogia rakendamise kohta pöördprojekteerimise käigus ja see võib sisaldada ebatäpsusi võrreldes Intel Boot Guardi spetsifikatsioonidega, mida tõenäoliselt kunagi ei avaldata.
Seega on Intel Boot Guard (BG) riistvaratoega UEFI BIOS-i autentimistehnoloogia. Otsustades selle väikese kirjelduse järgi raamatus [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], toimib see usaldusväärse alglaadimisahelana. Ja esimene link selles on CPU sees olev alglaadimiskood (mikrokood), mille käivitab RESET sündmus (mitte segi ajada BIOS-i RESET-vektoriga!). Protsessor leiab SPI välkmälust Inteli poolt välja töötatud ja allkirjastatud koodimooduli (Intel BG startup ACM), laadib selle oma vahemällu, kontrollib seda (eespool oli juba märgitud, et CPU-l on avaliku võtme räsi, mis kontrollib ACM-i allkirja ) ja käivitub.
See koodimoodul vastutab UEFI BIOS-i väikese algosa - esialgse alglaadimisploki (IBB) - kontrollimise eest, mis omakorda sisaldab funktsioone UEFI BIOS-i põhiosa kontrollimiseks. Seega võimaldab Intel BG teil kontrollida BIOS-i autentsust enne OS-i käivitamist (mida saab teha Secure Boot tehnoloogia järelevalve all).
Intel BG tehnoloogia pakub kahte töörežiimi (ja üks ei sega teist, st mõlemat režiimi saab süsteemis lubada ja mõlemat saab keelata).
Mõõdetud Boot
Mõõdetud alglaadimise (MB) režiimis "mõõdab" iga alglaadimiskomponent (alates CPU alglaadimis-ROM-ist) järgmist, kasutades usaldusväärse platvormi mooduli (TPM) võimalusi. Neile, kes ei tea, las ma selgitan.
TPM-il on PCR-id (Platform Configuration Registers), mis salvestavad räsitoimingu tulemuse järgmise valemi järgi:
Need. praegune PCR väärtus sõltub eelmisest ja need registrid lähtestatakse ainult siis, kui süsteem on RESET.
Seega peegeldavad PCR-id MB-režiimis mingil ajahetkel "mõõdetud" koodi või andmete unikaalset (räsioperatsiooni võimaluste piires) identifikaatorit. PCR väärtusi saab kasutada teatud andmete krüptimisel (TPM_Seal). Pärast seda on nende dekrüpteerimine (TPM_Unseal) võimalik ainult siis, kui PCR väärtused pole laadimise tulemusena muutunud (st ühtegi "mõõdetud" komponenti pole muudetud).
Kontrollitud alglaadimine
Kõige hirmsam neile, kellele meeldib UEFI BIOS-i muuta, on Verified Boot (VB) režiim, kus iga alglaadimiskomponent kontrollib krüptograafiliselt järgmise terviklikkust ja autentsust. Ja kinnitusvea korral ilmneb (üks järgmistest):
- väljalülitamine ajalõpu järgi 1 minutist 30 minutini (et kasutajal oleks aega mõista, miks tema arvuti ei käivitu, ja võimalusel prooviks BIOS-i taastada);
- viivitamatu seiskamine (et kasutajal poleks aega aru saada ja pealegi teha);
- töö jätkamine sirge näoga (juhul, kui pole aega ohutuseks, sest on tähtsamad tegemised).
Toimingu valik sõltub määratud Intel BG konfiguratsioonist (nimelt nn jõustamispoliitikast), mille arvutiplatvormi müüja salvestab püsivalt spetsiaalselt loodud salvestusruumi - kiibistiku kaitsmed (FPF). Peatume sellel punktil hiljem üksikasjalikumalt.
Lisaks konfiguratsioonile genereerib tarnija kaks RSA 2048 võtit ja loob kaks andmestruktuuri (näidatud joonisel):
- Tarnija juurvõtme manifest (KEYM, OEM Root Key Manifest), mis lisab selle manifesti SVN-i (turbeversiooni numbri), järgmise manifesti avaliku võtme SHA256 räsi, RSA avaliku võtme (st. hankija juurvõti), et kontrollida selle manifesti allkirja ja allkirja ennast;
- IBB manifest (IBBM, Initial Boot Block Manifest), mis paneb selle manifesti SVN-i, IBB SHA256 räsi, selle manifesti allkirja kontrollimise avaliku võtme ja allkirja enda.
OEM-juurvõtme SHA256 räsi kirjutatakse püsivalt kiibistiku kaitsmetesse (FPF-idesse), nagu Inteli BG konfiguratsioon. Kui Intel BG konfiguratsioon näeb ette selle tehnoloogia kaasamise, siis nüüdsest saab selles süsteemis BIOS-i uuendada (st saab neid manifeste ümber arvutada) vaid OEM-juurvõtme privaatse osa omanik, s.t. müüja.
Pilti vaadates tekib kohe kahtlus nii pika kontrolliahela vajalikkuses - oleks võinud kasutada ühte manifesti. Miks teha keeruliseks?
Tegelikult annab Intel seega müüjale võimaluse kasutada erinevate tootesarjade jaoks erinevaid IBB-võtmeid ja üht juurena. Kui IBB-võtme privaatne osa (mis allkirjastab teise manifesti) lekib, mõjutab juhtum ainult ühte tootesarja ja ainult seni, kuni tarnija loob uue paari ja lubab järgmises BIOS-i värskenduses ümberarvutatud manifestid.
Kui aga juurvõti on ohus (millega esimene manifest on allkirjastatud), pole seda võimalik asendada, tühistamise protseduuri ei pakuta. selle võtme avaliku osa räsi programmeeritakse lõplikult FPF-idesse.
Intel Boot Guard konfiguratsioon
Nüüd vaatame lähemalt Intel BG konfiguratsiooni ja selle loomise protsessi. Kui vaatate Intel System Tool Kit (STK) Flash Image Tooli GUI vastavat vahekaarti, märkate, et Inteli BG konfiguratsioon sisaldab müüja juurvõtme avaliku osa räsi, mis on paar ebaselget. väärtused ja nii edasi. Intel BG profiil.
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 – do nothing
// 01b – shutdown with timeout
// 11b – immediate shutdown
unsigned long : 26;
};Üldiselt on Inteli BG konfiguratsioon väga paindlik üksus. Mõelge näiteks lipule Force_Boot_Guard_ACM. Kui see kustutatakse ja kui SPI-välklambi BG käivitus-ACM-moodulit ei leita, siis usaldusväärset alglaadimist ei toimu. See saab olema ebausaldusväärne.
Eespool juba kirjutasime, et VB-režiimi jõustamispoliitikat saab konfigureerida nii, et kui kinnitamine ebaõnnestub, toimub taas ebausaldusväärne allalaadimine.
Jätke sellised asjad müüjate otsustada...
Utiliidi GUI pakub järgmisi "valmis" profiile:
Ei.
Režiim
Kirjeldus
0
No_FVME
Intel BG tehnoloogia on keelatud
1
VE
VB-režiim lubatud, väljalülitamine ajalõpu tõttu
2
VME laiendus
mõlemad režiimid on lubatud (VB ja MB), väljalülitamine ajalõpu järgi
3
VM
mõlemad režiimid on lubatud ilma süsteemi välja lülitamata
4
FVE
VB-režiim lubatud, kohene väljalülitamine
5
FVME
mõlemad režiimid lubatud, kohene väljalülitamine
Nagu juba mainitud, tuleb süsteemi tarnijal Intel BG konfiguratsioon lõplikult kirjutada kiibistiku kaitsmetesse (FPF) – väikesesse (kontrollimata info kohaselt vaid 256 baiti) riistvaralise teabe salvestusruumi kiibistiku sees, mida saab programmeerida väljastpoolt. Inteli tootmishoonetest (see on põhjus, miks Välja programmeeritav kaitsmed).
See on suurepärane konfiguratsiooni salvestamiseks, kuna:
- omab ühekordselt programmeeritavat andmesalvestusala (just sinna, kuhu on kirjutatud Intel BG konfiguratsioon);
- ainult Intel ME saab seda lugeda ja programmeerida.
Intel BG tehnoloogia konfiguratsiooni määramiseks konkreetses süsteemis teeb müüja tootmise ajal järgmist.
- Flash Image Tooli (Intel STK) abil loob püsivara kujutise antud Inteli BG konfiguratsiooniga muutujatena Intel ME piirkonnas (nn FPF-ide ajutine peegel);
- Kasutades Flash Programming Tooli (firmalt Intel STK), kirjutab selle pildi süsteemi SPI välkmällu ja sulgeb nn. tootmisrežiim (sel juhul saadetakse vastav käsk Intel ME-le).
Nende toimingute tulemusena kehtestab Intel ME FPF-idele peeglist antud väärtused ME-piirkonna FPF-ide jaoks, seab SPI välklampide deskriptorites olevad õigused Inteli soovitatud väärtustele (kirjeldatud jaotise alguses). artikkel) ja viige läbi süsteemi RESET.
Intel Boot Guard juurutamise analüüs
Selle tehnoloogia rakendamise analüüsimiseks konkreetse näite põhjal kontrollisime Intel BG tehnoloogia jälgede suhtes järgmisi süsteeme:
Süsteem
Märkus
Gigabyte GA-H170-D3H
Skylake, tugi on olemas
Gigabyte GA-Q170-D3H
Skylake, tugi on olemas
Gigabyte GA-B150-HD3
Skylake, tugi on olemas
MSI H170A Gaming Pro
Skylake, tuge pole
Lenovo ThinkPad 460
Skylake, tugi on saadaval, tehnoloogia on lubatud
Lenovo Jooga 2 Pro
Haswell, toetust pole
Lenovo U330p
Haswell, toetust pole
"Tugi" tähendab Intel BG käivitusmooduli ACM, ülalmainitud manifestide ja vastava koodi olemasolu BIOS-is, s.t. teostused analüüsiks.
Võtame näiteks kontorist alla laaditud. SPI-välkmälu müüja saidi kujutis Gigabyte GA-H170-D3H jaoks (versioon F4).
Inteli protsessori alglaadimis-ROM
Kõigepealt räägime protsessori toimimisest, kui Intel BG tehnoloogia on lubatud.
Dekrüpteeritud mikrokoodi näidiseid ei õnnestunud leida, seetõttu on lahtine küsimus, kuidas allpool kirjeldatud toiminguid rakendatakse (mikrokoodis või riistvaras). Sellegipoolest on tõsiasi, et kaasaegsed Inteli protsessorid "saavad" neid toiminguid teha.
Pärast RESET-olekust väljumist leiab protsessor (mille aadressiruumis on välkmälu sisu juba kaardistatud) FIT-i (Firmware Interface Table). Selle leidmine on lihtne, kursor sellele on kirjutatud aadressil FFFF FFC0h.
Selles näites sisaldab see aadress väärtust FFD6 9500h. Sellele aadressile pöördudes näeb protsessor FIT tabelit, mille sisu on kirjeteks jagatud. Esimene kirje on järgmise struktuuri pealkiri:
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;
};
Mingil teadmata põhjusel ei arvutata neis tabelites alati kontrollsummat (väli jäetakse tühjaks).
Ülejäänud kirjed viitavad erinevatele binaarfailidele, mida tuleb enne BIOS-i käivitamist parsida/käivitada, st. enne kui lülitute pärandvektorile RESET (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 sisestus osutab. Teame mitut tüüpi:
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 ilmne, et üks kirjetest osutab Intel BG käivitus-ACM-binaarfaili asukohale. Selle kahendfaili päisestruktuur on tüüpiline Inteli poolt välja töötatud koodimoodulitele (ACM-id, mikrokoodivärskendused, Intel ME koodilõigud jne).
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];
};
Protsessor laadib selle kahendfaili oma vahemällu, kontrollib ja käivitab.
Intel BG käivitus ACM
Selle ACM-i töö analüüsi tulemusena selgus, et see teeb järgmist:
- võtab Intel ME-lt vastu kiibistiku kaitsmetele (FPF) kirjutatud Intel BG konfiguratsiooni;
- leiab KEYM ja IBBM manifestid, kontrollib neid.
Nende manifestide leidmiseks kasutab ACM ka FIT-tabelit, milles on nendele struktuuridele osutamiseks kahte tüüpi kirjeid (vt ülalt FIT_ENTRY_TYPES).
Vaatame manifeste lähemalt. Esimese manifesti struktuuris näeme mitmeid ebaselgeid konstante, teise manifesti avaliku võtme räsi ja avalikku OEM-i juurvõtit, mis on allkirjastatud pesastatud struktuurina:
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-i juurvõtme avaliku võtme kontrollimiseks tuletame meelde, et kasutatakse kaitsmetest SHA256 räsi, mis on praegu Intel ME-lt juba saadud.
Liigume edasi teise manifesti juurde. See koosneb kolmest struktuurist:
typedef struct IBB_MANIFEST
{
ACBP Acbp; // Boot policies
IBBS Ibbs; // IBB description
IBB_DESCRIPTORS[];
PMSG Pmsg; // IBBM signature
};Esimene sisaldab mõningaid konstante:
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
};Teine sisaldab IBB SHA256 räsi ja deskriptorite arvu, mis kirjeldavad IBB sisu (st millest räsi arvutatakse):
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 üksteise järel. Nende sisu on järgmises vormingus:
typedef struct IBB_DESCRIPTOR
{
unsigned long : 32;
unsigned long BaseAddress;
unsigned long Size;
};See on lihtne: iga deskriptor sisaldab IBB tüki aadressi/suurust. Seega on nende deskriptorite (deskriptorite endi järjekorras) osutatud plokkide konkatenatsioon IBB. Ja reeglina on IBB kõigi SEC- ja PEI-faasi moodulite kombinatsioon.
Teine manifest lõpeb struktuuriga, mis sisaldab IBB avalikku võtit (kontrollitud esimese manifesti SHA256 räsi abil) ja selle manifesti allkirja:
typedef struct PMSG
{
char Tag[8]; // ‘__PMSG__’
unsigned char : 8; // 10h
BG_RSA_ENTRY IbbKey;
};
Nii et isegi enne UEFI BIOS-i käivitamist käivitab protsessor ACM-i, mis kontrollib SEC- ja PEI-faasikoodiga jaotiste sisu autentsust. Järgmisena väljub protsessor ACM-ist, liigub mööda RESET-vektorit ja alustab BIOS-i käivitamist.
PEI kinnitatud partitsioon peab sisaldama moodulit, mis kontrollib ülejäänud BIOS-i (DXE-kood). Seda moodulit arendab juba IBV (Independent BIOS Vendor) või süsteemi tarnija ise. Sest Meie käsutusse osutusid ainult Lenovo ja Gigabyte süsteemid ning Intel BG toega, arvestame nendest süsteemidest eraldatud koodiga.
UEFI BIOS-i moodul LenovoVerifiedBootPei
Lenovo puhul osutus selleks Lenovo välja töötatud moodul LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}.
Selle ülesanne on otsida (GUID-i järgi) DXE räsitabel ja kontrollida DXE-d.
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-i moodul BootGuardPei
Gigabyte'i puhul osutus see BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066} mooduliks, mille on välja töötanud AMI ja mis on seetõttu olemas igas Intel BG toega AMI BIOS-is.
Selle tööalgoritm on mõnevõrra erinev, kuid taandub samale:
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;
}Otsitav räsitabel {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} on järgmises vormingus:
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 Guardi teostusest, mis leiti uuemast Intel SoC-l põhinevast Apollo Lake mikroarhitektuuriga süsteemist – ASRock J4205-IT.
Kuigi seda versiooni kasutatakse ainult SoC-des (uued Kaby Lake'i protsessori mikroarhitektuuriga süsteemid kasutavad jätkuvalt Intel Boot Guard 1.x), pakub see suurt huvi Inteli SoC-del põhinevate platvormide uue arhitektuurivõimaluse uurimise vastu, mis on olnud käegakatsutav. muudatused, näiteks:
- BIOS ja Intel ME piirkonnad (või õigemini Intel TXE, vastavalt Intel SoC terminoloogiale) on nüüd üks IFWI piirkond;
- kuigi Intel BG oli platvormil lubatud, ei leitud välkmälust selliseid struktuure nagu FIT, KEYM, IBBM;
- lisaks TXE ja ISH tuumadele (x86) lisati kiibistikule kolmas tuum (muide, taas ARC) - PMC (Power Management Controller), mis on seotud toite alamsüsteemi töökindluse ja jõudluse jälgimisega.
Uue IFWI piirkonna sisu koosneb järgmistest moodulitest:
Eelarvamus
Nimi
Kirjeldus
0000 2000 tundi
SMIP
teatud platvormi konfiguratsioon, mille on allkirjastanud müüja
0000 6000 tundi
RBEP
Inteli TXE püsivara koodijaotis x86, allkirjastatud Inteli poolt
0001 0000 tundi
PMCP
püsivara koodijaotis Intel PMC, ARC, allkirjastanud Intel
0002 0000 tundi
FTPR
Inteli TXE püsivara koodijaotis x86, allkirjastatud Inteli poolt
0007B000h
UCOD
Inteli allkirjastatud protsessori mikrokoodi värskendused
0008 0000 tundi
IBBP
UEFI BIOS, SEC/PEI faasid, x86, müüja allkirjastatud
0021 8000 tundi
ISHC
Intel ISH püsivara x86 koodijaotis, mille on allkirjastanud müüja
0025 8000 tundi
FTP
Inteli TXE püsivara koodijaotis x86, allkirjastatud Inteli poolt
0036 1000 tundi
IUNP
teadmata
0038 1000 tundi
OBBP
UEFI BIOS, DXE faas, x86, allkirjastamata
TXE püsivara analüüsimisel sai selgeks, et pärast RESET-i hoiab TXE protsessori selles olekus, kuni valmistab CPU jaoks ette aadressiruumi põhisisu (FIT, ACM, RESET vektor ...). Veelgi enam, TXE paigutab need andmed oma SRAM-i, misjärel annab protsessorile ajutiselt seal juurdepääsu ja “vabastab” need RESET-ist.
Rootkittide valvel
Noh, liigume nüüd "kuuma" juurde. Kunagi avastasime, et paljudes süsteemides on SPI välkmälude deskriptoritel õigus pääseda juurde SPI välkmälu piirkondadele, nii et kõik selle mälu kasutajad saavad nii kirjutada kui ka lugeda mis tahes piirkonda. Need. pole võimalik.
Pärast MEinfo utiliidi (Intel STK) kontrollimist nägime, et nende süsteemide tootmisrežiim ei olnud suletud, seetõttu jäeti kiibistiku kaitsmed (FPF-id) määramatusse olekusse. Jah, Intel BG pole sellistel juhtudel lubatud ega keelatud.
Räägime järgmistest süsteemidest (Intel BG ja selle kohta, mida artiklis hiljem kirjeldatakse, räägime Haswelli protsessori mikroarhitektuuri ja uuematest süsteemidest):
- kõik Gigabyte'i tooted;
- kõik MSI tooted;
- 21 Lenovo sülearvuti mudelit ja 4 Lenovo serveri mudelit.
Loomulikult teatasime leiust nendele müüjatele ja ka Intelile.
Adekvaatne vastus järgnes alles alates Lenovokes tunnistas probleemi ja .
Gigabyte Tundub, et nad võtsid haavatavuse kohta info vastu, kuid ei kommenteerinud kuidagi.
Suhtlemine MSI täielikult seiskunud meie palvel saata meie avalik PGP-võti (et saata neile krüpteeritud turvateatis). Nad väitsid, et nad "on riistvaratootja ega tooda PGP-võtmeid."
Aga asja juurde. Kuna kaitsmed on jäetud määratlemata olekusse, saab kasutaja (või ründaja) need ise programmeerida (kõige keerulisem on ). Selleks on vaja järgmisi samme.
1. Käivitage Windows OS-i (üldiselt saab allpool kirjeldatud toiminguid teha ka Linuxi alt, kui arendate soovitud OS-i jaoks Intel STK analoogi). Utiliidi MEinfo abil veenduge, et selle süsteemi kaitsmed pole programmeeritud.
2. Lugege välkmälu sisu Flash Programming Tooli abil.
3. Avage loetud pilt mis tahes UEFI BIOS-i redigeerimistööriista abil, tehke vajalikud muudatused (näiteks juurutage juurkomplekt), looge / redigeerige ME-piirkonnas olemasolevaid KEYM-i ja IBBM-i struktuure.
Pildil on esile tõstetud RSA võtme avalik osa, mille räsi programmeeritakse koos ülejäänud Intel BG konfiguratsiooniga kiibistiku kaitsmetesse.
4. Looge Flash Image Tooli abil uus püsivara kujutis (määrates Intel BG konfiguratsiooni).
5. Kirjutage Flash Programming Tooli abil uus pilt, mis välgub, ja kontrollige MEinfo abil, et ME-piirkond sisaldab nüüd Inteli BG konfiguratsiooni.
6. Tootmisrežiimi sulgemiseks kasutage Flash Programming Tooli.
7. Süsteem taaskäivitub, pärast mida saate MEinfo abil kontrollida, kas FPF-id on nüüd programmeeritud.
Need toimingud igavesti lubage selles süsteemis Intel BG. Toimingut on võimatu tagasi võtta, mis tähendab:
- ainult juurvõtme privaatse osa omanik (st see, kes lubas Intel BG) saab selles süsteemis UEFI BIOS-i värskendada;
- kui tagastate sellesse süsteemi algse püsivara, näiteks programmeerija abil, ei lülitu see isegi sisse (jõustamispoliitika tagajärg kontrollivea korral);
- sellisest UEFI BIOS-ist vabanemiseks tuleb programmeeritud FPF-idega kiibistik “puhta” vastu välja vahetada (st kiibikomplekti uuesti jootma, kui auto hinnaga on ligipääs infrapuna jootejaamale või lihtsalt emaplaat välja vahetada ).
Et mõista, mida selline juurkomplekt suudab, peate hindama, mis võimaldab teie koodi UEFI BIOS-i keskkonnas käivitada. Ütleme, et protsessori kõige privilegeeritud režiimis - SMM. Sellisel juurkomplektil võivad olla järgmised omadused:
- käivitada paralleelselt OS-iga (saate konfigureerida töötlemise, genereerides SMI katkestuse, mille käivitab taimer);
- omama kõiki SMM-režiimi eeliseid (täielik juurdepääs RAM-i sisule ja riistvararessurssidele, OS-i salastatus);
- SMM-režiimis käivitamisel saab juurkomplekti koodi krüpteerida ja dekrüpteerida. Kõiki andmeid, mis on saadaval ainult SMM-režiimis, saab kasutada krüpteerimisvõtmena. Näiteks räsi SMRAM-i aadresside komplektist. Selle võtme saamiseks peate ronima SMM-i. Ja seda saab teha kahel viisil. Leidke SMM-koodist RCE ja kasutage seda või lisage BIOS-i oma SMM-moodul, mis on võimatu, kuna lubasime Boot Guardi.
Seega võimaldab see haavatavus ründajal:
- luua süsteemis tundmatu otstarbega peidetud eemaldamatu juurkomplekt;
- käivitage oma kood ühes Intel SoC sees olevas kiibistiku tuumas, nimelt Intel ISH-s (vaadake pilti lähemalt).
Kuigi Intel ISH alamsüsteemi võimalusi pole veel uuritud, tundub see olevat huvitav ründevektor Intel ME vastu.
Järeldused
- Uuring andis tehnilise kirjelduse, kuidas Intel Boot Guard tehnoloogia töötab. Miinus paar saladust Inteli turvalisuses läbi obscurity mudeli.
- Esitatakse ründestsenaarium, mis võimaldab luua süsteemis eemaldamatu juurkomplekti.
- Oleme näinud, et kaasaegsed Inteli protsessorid suudavad käivitada palju varalist koodi isegi enne BIOS-i käivitumist.
- Intel 64 arhitektuuriga platvormid muutuvad üha vähem sobivaks vaba tarkvara käitamiseks: riistvara kontrollimine, kasvav hulk patenteeritud tehnoloogiaid ja alamsüsteeme (SoC kiibistiku kolm tuuma: x86 ME, x86 ISH ja ARC PMC).
Leevendused
Müüjad, kes jätavad tahtlikult tootmisrežiimi avatuks, peaksid selle kindlasti sulgema. Siiani sulgevad nad ainult silmi ja uued Kaby Lake'i süsteemid näitavad seda.
Kasutajad saavad Intel BG oma süsteemides (mida mõjutab kirjeldatud haavatavus) keelata, käivitades Flashi programmeerimistööriista valikuga -closemnf. Esiteks peaksite (MEinfo abil) veenduma, et Intel BG konfiguratsioon ME piirkonnas võimaldab selle tehnoloogia täpselt välja lülitada pärast FPF-ides programmeerimist.
Allikas: www.habr.com