Patikimas Schrödingerio batas. „Intel“ įkrovos apsauga

Siūlome vėl nusileisti iki žemo lygio ir pakalbėti apie programinės aparatinės įrangos x86 suderinamų kompiuterių platformų saugumą. Šį kartą pagrindinė tyrimo sudedamoji dalis yra „Intel Boot Guard“ (nepainioti su „Intel BIOS Guard“!) – aparatinės įrangos palaikoma BIOS patikima įkrovos technologija, kurią kompiuterių sistemos pardavėjas gali visam laikui įjungti arba išjungti gamybos etape. Na, o tyrimo receptą jau žinome: plonai supjaustykite šios technologijos įgyvendinimą atvirkštine inžinerija, apibūdinkite jos architektūrą, užpildydami nedokumentuotomis detalėmis, pagardinkite atakos vektoriais pagal skonį ir sumaišykite. Prisidėkime prie pasakojimo apie tai, kaip daugelį metų klonuota klaida kelių pardavėjų gamyboje leidžia potencialiam užpuolikui panaudoti šią technologiją, kad sukurtų paslėptą šaknų rinkinį, kurio negali pašalinti (netgi programuotojas) sistemoje.

Beje, straipsnis parengtas remiantis konferencijos pranešimais „On Guard for Rootkits: Intel BootGuard“ „ZeroNights 2016“. ir 29 posėdis DefCon Rusija (abu pristatymai čia).

Kompiuterių platformos su Intel 64 architektūra programinė įranga

Pirmiausia atsakykime į klausimą: kokia yra šiuolaikinės kompiuterio platformos su Intel 64 architektūra programinė įranga? Žinoma, UEFI BIOS. Tačiau šis atsakymas nebus tikslus. Pažvelkime į paveikslą, kuriame pavaizduota šios architektūros darbalaukio (nešiojamojo kompiuterio) versija.

Nuoroda yra pagrindas:

• Procesorius (CPU, Central Processing Unit), kuris, be pagrindinių branduolių, turi įmontuotą grafinį branduolį (ne visuose modeliuose) ir atminties valdiklį (IMC, Integrated Memory Controller);
• Lustų rinkinys (PCH, Platform Controller Hub), kuriame yra įvairių valdiklių, skirtų sąveikai su periferiniais įrenginiais ir posistemių valdymui. Tarp jų yra liūdnai pagarsėjęs „Intel Management Engine“ (ME), kuris taip pat turi programinę-aparatinę įrangą („Intel ME“ programinė įranga).

Nešiojamiesiems kompiuteriams, be to, kas išdėstyta aukščiau, reikalingas integruotas valdiklis (ACPI EC, Advanced Control and Power Interface Embedded Controller), kuris yra atsakingas už maitinimo posistemio, jutiklinės dalies, klaviatūros, Fn klavišų (ekrano ryškumo, garso garsumo, klaviatūros) veikimą. foninis apšvietimas ir kt.) ir kt. Ir jis taip pat turi savo programinę įrangą.

Taigi, aukščiau pateiktos programinės įrangos derinys yra kompiuterio platformos programinė įranga (sistemos programinė įranga), kuri saugoma bendroje SPI „flash“ atmintyje. Kad šios atminties vartotojai nesusipainiotų, kur kas nors guli, šios atminties turinys suskirstytas į šiuos regionus (kaip parodyta paveikslėlyje):

• UEFI BIOS;
• ACPI EC programinė įranga (atskiras regionas atsirado su „Skylake“ procesoriaus mikroarchitektūra (2015 m.), tačiau lauke dar nematėme jos naudojimo pavyzdžių, todėl įterptojo valdiklio programinė įranga vis dar yra UEFI BIOS dalis);
• „Intel ME“ programinė įranga;
• integruoto GbE (Gigabit Ethernet) tinklo adapterio konfigūracija (MAC adresas ir kt.);
• „flash deskriptoriai“ – pagrindinė „flash“ atminties sritis, kurioje yra rodyklės į kitus regionus, taip pat leidimai juos pasiekti.

Prieigos prie regionų diferencijavimą (pagal nurodytus leidimus) tvarko SPI magistralės valdiklis – mikroschemų rinkinyje įmontuotas SPI valdiklis, per kurį pasiekiama ši atmintis. Jei leidimai nustatomi į „Intel“ (saugumo sumetimais) rekomenduojamas reikšmes, kiekvienas SPI blykstės vartotojas turi visišką prieigą (skaityti / rašyti) tik prie savo regiono. Likusieji yra tik skaitomi arba nepasiekiami. Žinomas faktas: daugelyje sistemų CPU turi visišką prieigą prie UEFI BIOS ir GbE, skaitymo prieigą tik prie blykstės deskriptorių ir išvis neturi prieigos prie Intel ME regiono. Kodėl daugelis, o ne visi? Tai, kas rekomenduojama, yra neprivaloma. Daugiau papasakosime vėliau straipsnyje.

Kompiuterio platformos programinės aparatinės įrangos apsaugos nuo modifikacijų mechanizmai

Akivaizdu, kad kompiuterio platformos programinė įranga turėtų būti apsaugota nuo galimo kompromiso, kuri leistų potencialiam užpuolikui joje įsitvirtinti (išgyventi OS atnaujinimus/perdiegimus), vykdyti savo kodą pačiais privilegijuotais režimais ir pan. Ir, žinoma, nepakanka prieigos prie SPI „flash“ atminties regionų. Todėl, norint apsaugoti programinę-aparatinę įrangą nuo modifikacijų, naudojami įvairūs kiekvienai vykdymo aplinkai būdingi mechanizmai.

Taigi, „Intel ME“ programinė įranga yra pasirašyta dėl vientisumo ir autentiškumo kontrolės, ir ją tikrina ME valdiklis kiekvieną kartą, kai ji įkeliama į ME UMA atmintį. Šį patvirtinimo procesą jau aptarėme viename iš straipsniaiskirta Intel ME posistemiui.

Ir ACPI EC programinė įranga, kaip taisyklė, tikrinama tik dėl vientisumo. Tačiau dėl to, kad šis dvejetainis failas yra įtrauktas į UEFI BIOS, jam beveik visada taikomi tie patys apsaugos mechanizmai, kuriuos naudoja UEFI BIOS. Pakalbėkime apie juos.

Šiuos mechanizmus galima suskirstyti į dvi kategorijas.

Rašymo apsauga į UEFI BIOS regioną

1. SPI „flash“ atminties turinio fizinė apsauga su apsaugos nuo įrašymo trumpikliu;
2. UEFI BIOS srities projekcijos apsauga procesoriaus adresų erdvėje naudojant mikroschemų rinkinio PRx registrus;
3. Blokuoti bandymus rašyti į UEFI BIOS regioną generuojant ir apdorojant atitinkamą SMI pertraukimą, nustatant BIOS_WE / BLE ir SMM_BWP bitus mikroschemų rinkinio registruose;
4. Pažangesnė šios apsaugos versija yra „Intel BIOS Guard“ (PFAT).

Be šių mechanizmų, pardavėjai gali kurti ir įdiegti savo saugumo priemones (pavyzdžiui, pasirašyti kapsules su UEFI BIOS atnaujinimais).

Svarbu pažymėti, kad konkrečioje sistemoje (priklausomai nuo pardavėjo) ne visi aukščiau išvardinti apsaugos mechanizmai gali būti taikomi, gali būti iš viso netaikomi arba įdiegti pažeidžiamai. Daugiau apie šiuos mechanizmus ir jų įgyvendinimo situaciją galite perskaityti Šis straipsnis. Tiems, kurie domisi, rekomenduojame perskaityti visą straipsnių seriją apie UEFI BIOS saugą nuo „CodeRush“.

UEFI BIOS autentifikavimo patikrinimas

Kai kalbame apie patikimas įkrovos technologijas, pirmas dalykas, kuris ateina į galvą, yra saugus įkrovimas. Tačiau architektūriniu požiūriu jis skirtas autentifikuoti išorinius UEFI BIOS komponentus (tvarkykles, įkroviklius ir kt.), o ne pačią programinę-aparatinę įrangą.

Todėl „Intel“ SoC su „Bay Trail“ mikroarchitektūra (2012 m.) įdiegė aparatinės įrangos neperjungiamą „Secure Boot“ („Verified Boot“), kuri neturi nieko bendra su minėta „Secure Boot“ technologija. Vėliau (2013 m.) šis mechanizmas buvo patobulintas ir pavadinimu „Intel Boot Guard“ buvo išleistas staliniams kompiuteriams su Haswell mikroarchitektūra.

Prieš aprašydami „Intel Boot Guard“, pažvelkime į „Intel 64“ architektūros vykdymo aplinkas, kurios kartu yra šios patikimos įkrovos technologijos pasitikėjimo šaknys.

"Intel" procesorius

„Cap“ rodo, kad procesorius yra pagrindinė „Intel 64“ architektūros vykdymo aplinka. Kodėl tai taip pat yra pasitikėjimo šaknis? Pasirodo, kad tai yra šių elementų turėjimas:

• Mikrokodo ROM yra nepastovi, neperrašoma atmintis, skirta mikrokodui saugoti. Manoma, kad mikrokodas yra procesoriaus instrukcijų sistemos įgyvendinimas pagal paprasčiausias instrukcijas. Taip pat atsitinka mikrokode klaidas. Taigi BIOS galite rasti dvejetainius failus su mikrokodų atnaujinimais (jie yra uždėti įkrovos metu, nes ROM negalima perrašyti). Šių dvejetainių failų turinys yra užšifruotas, o tai labai apsunkina analizę (todėl konkretus mikrokodo turinys yra žinomas tik jį kuriantiesiems), pasirašomas siekiant kontroliuoti vientisumą ir autentiškumą;
• AES raktas mikrokodų atnaujinimų turiniui iššifruoti;
• RSA viešojo rakto maiša, kuri patikrina mikrokodo atnaujinimų parašą;
• RSA viešojo rakto maiša, kuri tikrina Intel sukurtų ACM (Authenticated Code Module) kodo modulių parašą, kurį CPU gali paleisti prieš paleidžiant BIOS (hello microcode) arba jos veikimo metu, kai įvyksta kokie nors įvykiai.

Intel ME

Šis mūsų tinklaraščio posistemis buvo skirtas du Straipsnis. Prisiminkite, kad ši vykdomoji aplinka yra pagrįsta mikrovaldikliu, integruotu į mikroschemų rinkinį, ir yra labiausiai paslėpta bei privilegijuota sistemoje.

Nepaisant slaptumo, „Intel ME“ taip pat yra pasitikėjimo šaknis, nes turi:

• ME ROM - nepastovi, neperrašoma atmintis (nepateikiamas atnaujinimo būdas), kurioje yra pradžios kodas, taip pat RSA viešojo rakto SHA256 maiša, kuri tikrina Intel ME programinės aparatinės įrangos parašą;
• AES raktas slaptai informacijai saugoti;
• prieiga prie saugiklių rinkinio (FPF, Field Programmable Fuse), integruoto į lustų rinkinį, nuolatiniam tam tikros informacijos, įskaitant kompiuterio sistemos tiekėjo nurodytą informaciją, saugojimui.

Intel Boot Guard 1.x

Mažas atsisakymas. Šiame straipsnyje naudojami „Intel Boot Guard“ technologijos versijų numeriai yra savavališki ir gali nesusiję su numeracija, naudojama vidinėje „Intel“ dokumentacijoje. Be to, čia pateikta informacija apie šios technologijos įgyvendinimą buvo gauta atliekant atvirkštinę inžineriją ir gali būti netikslumų, palyginti su „Intel Boot Guard“ specifikacija, kuri vargu ar kada nors bus paskelbta.

Taigi, „Intel Boot Guard“ (BG) yra aparatinės įrangos palaikoma UEFI BIOS autentifikavimo technologija. Sprendžiant iš nedidelio aprašymo knygoje [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], ji veikia kaip patikima įkrovos grandinė. Ir pirmoji nuoroda jame yra įkrovos kodas (mikrokodas) procesoriaus viduje, kurį suaktyvina RESET įvykis (nepainiokite su RESET vektoriumi BIOS!). Centrinis procesorius randa SPI flash atmintyje Intel sukurtą ir pasirašytą kodo modulį (Intel BG startup ACM), įkelia jį į talpyklą, patikrina (jau buvo pažymėta aukščiau, kad CPU turi viešojo rakto maišą, kuri patikrina ACM parašą ) ir prasideda.

Šis kodo modulis yra atsakingas už mažos pradinės UEFI BIOS dalies - pradinio įkrovos bloko (IBB) - patikrinimą, kuriame, savo ruožtu, yra pagrindinės UEFI BIOS dalies tikrinimo funkcija. Taigi „Intel BG“ leidžia patikrinti BIOS autentiškumą prieš paleidžiant OS (tai gali būti atliekama prižiūrint „Secure Boot“ technologijai).

Intel BG technologija suteikia du veikimo režimus (ir vienas netrukdo kitam, t. y. sistemoje galima įjungti abu režimus, o abu – išjungti).

Išmatuota bagažinė

Išmatuoto įkrovos (MB) režimu kiekvienas įkrovos komponentas (pradedant CPU įkrovos ROM) „matuoja“ kitą, naudodamas patikimos platformos modulio (TPM) galimybes. Tiems, kurie nežino, paaiškinsiu.

TPM turi PCR (platformos konfigūracijos registrus), kurie įrašo maišos operacijos rezultatą pagal formulę:

Tie. dabartinė PGR reikšmė priklauso nuo ankstesnės, o šie registrai nustatomi iš naujo tik tada, kai sistema yra RESET.

Taigi, MB režimu tam tikru momentu PGR atspindi unikalų (neviršijant maišos operacijos galimybių) kodo arba duomenų, kurie buvo „išmatuoti“, identifikatorių. PGR reikšmės gali būti naudojamos kai kurių duomenų šifravimui (TPM_Seal). Po to jų iššifravimas (TPM_Unseal) bus įmanomas tik tuo atveju, jei PGR reikšmės nepasikeitė dėl įkėlimo (t. y. nebuvo pakeistas nei vienas „išmatuotas“ komponentas).

Patvirtinta įkrova

Pats baisiausias dalykas mėgstantiems modifikuoti UEFI BIOS yra Verified Boot (VB) režimas, kai kiekvienas įkrovos komponentas kriptografiškai patikrina kito vientisumą ir autentiškumą. Ir jei įvyksta patvirtinimo klaida, įvyksta (vienas iš šių):

• išjungimas pagal skirtąjį laiką nuo 1 minutės iki 30 minučių (kad vartotojas turėtų laiko suprasti, kodėl jo kompiuteris nepasileidžia, ir, jei įmanoma, bandytų atkurti BIOS);
• nedelsiant išjungti (kad vartotojas neturėtų laiko suprasti ir, be to, padaryti);
• darbo tęsimas tiesiu veidu (atvejis, kai nėra laiko saugumui, nes yra svarbesnių reikalų).

Veiksmo pasirinkimas priklauso nuo nurodytos Intel BG konfigūracijos (būtent nuo vadinamosios vykdymo politikos), kurią kompiuterio platformos pardavėjas nuolat įrašo į specialiai sukurtą saugyklą – mikroschemų rinkinio saugiklius (FPF). Šiuo klausimu mes gyvensime išsamiau vėliau.

Be konfigūracijos, tiekėjas sugeneruoja du RSA 2048 raktus ir sukuria dvi duomenų struktūras (parodyta paveikslėlyje):

1. Tiekėjo šakninio rakto aprašas (KEYM, OEM Root Key manifestas), kuriame pateikiamas šio aprašo SVN (saugos versijos numeris), kito aprašo viešojo rakto SHA256 maiša, RSA viešasis raktas (t. y. viešoji tiekėjo šakninis raktas), kad patikrintumėte šio manifesto parašą ir patį parašą;
2. IBB manifestas (IBBM, pradinio įkrovos bloko manifestas), kuriame pateikiamas šio aprašo SVN, IBB SHA256 maiša, viešasis raktas, skirtas šio manifesto parašui patikrinti, ir pats parašas.

OĮG šakninio rakto SHA256 maiša visam laikui įrašoma į mikroschemų rinkinio saugiklius (FPF), kaip ir Intel BG konfigūracija. Jei Intel BG konfigūracija numato šios technologijos įtraukimą, tai nuo šiol šioje sistemoje BIOS atnaujinti (t.y. galės perskaičiuoti šiuos manifestus) gali tik privačios OEM Root Key dalies savininkas, t.y. pardavėjas.

Pažvelgus į paveikslėlį, iškart kyla abejonių, ar reikia tokios ilgos tikrinimo grandinės – galėjote naudoti vieną manifestą. Kodėl komplikuoti?

Tiesą sakant, „Intel“ suteikia pardavėjui galimybę naudoti skirtingus IBB raktus skirtingoms produktų linijoms ir vieną kaip pagrindinį. Jei nutekės privati ​​IBB rakto dalis (kuri pasirašo antrąjį manifestą), incidentas paveiks tik vieną produktų liniją ir tik tol, kol pardavėjas sugeneruos naują porą ir įgalins perskaičiuotus aprašus kitame BIOS naujinime.

Bet jei šakninis raktas yra pažeistas (su kuriuo pasirašomas pirmasis manifestas), jo pakeisti nebus galima, atšaukimo procedūra nenumatyta. šio rakto viešosios dalies maiša kartą ir visiems laikams užprogramuojama į FPF.

„Intel Boot Guard“ konfigūracija

Dabar atidžiau pažvelkime į „Intel BG“ konfigūraciją ir jos kūrimo procesą. Jei pažvelgsite į atitinkamą skirtuką „Flash Image Tool“ grafinėje sąsajoje iš „Intel System Tool Kit“ (STK), pastebėsite, kad „Intel BG“ konfigūracija apima tiekėjo šakninio rakto viešosios dalies maišą, o kai kurie neaiški. vertybes ir pan. Intel BG profilis.

Šio profilio struktūra:

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

Apskritai „Intel BG“ konfigūracija yra labai lanksti. Apsvarstykite, pavyzdžiui, Force_Boot_Guard_ACM vėliavėlę. Kai jis išvalomas, jei BG paleisties ACM modulis SPI blykstėje nerastas, patikimas įkrovimas neįvyks. Tai bus nepatikima.

Aukščiau jau rašėme, kad VB režimo vykdymo politiką galima sukonfigūruoti taip, kad jei patvirtinimas nepavyktų, vėl atsiras nepatikimas atsisiuntimas.

Palikite tokius dalykus pardavėjams...

Priemonės GUI pateikia šiuos „paruoštus“ profilius:

Ne.
Režimas
aprašymas

0
No_FVME
Intel BG technologija išjungta

1
VE
VB režimas įjungtas, išjungimas pasibaigus laikui

2
VME
abu režimai įjungti (VB ir MB), išjungimas pasibaigus laikui

3
VM
abu režimai įjungti, neišjungiant sistemos

4
FVE
Įjungtas VB režimas, iš karto išjungiamas

5
FVME
abu režimai įjungti, iš karto išjungti

Kaip jau minėta, „Intel BG“ konfigūraciją sistemos tiekėjas turi vieną kartą ir visiems laikams įrašyti į mikroschemų rinkinio saugiklius (FPF) – nedidelę (pagal nepatikrintą informaciją, tik 256 baitai) aparatinės įrangos informacijos saugyklą mikroschemų rinkinio viduje, kurią galima programuoti išorėje. „Intel“ gamybos įrenginių (taigi todėl Programuojamas lauke saugiklius).

Tai puikiai tinka konfigūracijos saugojimui, nes:

• turi vienkartinę programuojamą duomenų saugojimo sritį (tik ten, kur parašyta Intel BG konfigūracija);
• tik Intel ME gali jį nuskaityti ir programuoti.

Taigi, norėdamas nustatyti „Intel BG“ technologijos konfigūraciją konkrečioje sistemoje, tiekėjas gamybos metu atlieka šiuos veiksmus:

1. Naudojant „Flash Image Tool“ (iš „Intel STK“), sukuriamas programinės įrangos vaizdas su nurodyta „Intel BG“ konfigūracija kaip kintamieji „Intel ME“ regione (vadinamasis laikinas FPF veidrodis);
2. Naudodamas Flash programavimo įrankį (iš Intel STK), įrašo šį vaizdą į sistemos SPI flash atmintį ir uždaro vadinamąjį. gamybos režimas (šiuo atveju atitinkama komanda siunčiama Intel ME).

Dėl šių operacijų Intel ME nustatys FPF nurodytas vertes iš veidrodžio ME regiono FPF, SPI blykstės deskriptorių leidimus nustatys į Intel rekomenduojamas vertes (aprašytas pradžioje straipsnis) ir atlikti sistemos RESET.

„Intel Boot Guard“ diegimo analizė

Norėdami išanalizuoti šios technologijos įgyvendinimą konkrečiu pavyzdžiu, patikrinome, ar šiose sistemose nėra „Intel BG“ technologijos pėdsakų:

Sistema
Atkreipti dėmesį

"Gigabyte GA-H170-D3H"
Skylake, yra palaikymas

Gigabyte GA-Q170-D3H
Skylake, yra palaikymas

Gigabyte GA-B150-HD3
Skylake, yra palaikymas

MSI H170A Gaming Pro
Skylake, jokios paramos

„Lenovo ThinkPad 460“
Skylake, galimas palaikymas, įjungta technologija

„Lenovo Yoga 2 Pro“
Haswell, jokio palaikymo

Lenovo U330p
Haswell, jokio palaikymo

„Palaikymas“ reiškia „Intel BG“ paleisties ACM modulio, aukščiau minėtų manifestų ir atitinkamo kodo buvimą BIOS, t.y. įgyvendinimai analizei.

Kaip pavyzdį paimkime atsisiųstą iš biuro. SPI „flash“ atminties, skirtos „Gigabyte GA-H170-D3H“ (versija F4), pardavėjo svetainės vaizdas.

„Intel“ procesoriaus įkrovos ROM

Pirmiausia pakalbėkime apie procesoriaus veiksmus, jei įjungta Intel BG technologija.

Iššifruoto mikrokodo pavyzdžių rasti nepavyko, todėl kaip yra įgyvendinami žemiau aprašyti veiksmai (mikrokode ar aparatinėje įrangoje), atviras klausimas. Nepaisant to, tai, kad šiuolaikiniai „Intel“ procesoriai „gali“ atlikti šiuos veiksmus, yra faktas.

Išėjus iš RESET būsenos, procesorius (kurio adresų erdvėje jau susietas „flash“ atminties turinys) suranda FIT (Firmware Interface Table). Jį rasti nesunku, rodyklė į ją rašoma adresu FFFF FFC0h.

Šiame pavyzdyje šiame adresu yra reikšmė FFD6 9500h. Atsigręžęs į šį adresą procesorius mato FIT lentelę, kurios turinys suskirstytas į įrašus. Pirmasis įrašas yra šios struktūros antraštė:

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

Dėl kažkokios nežinomos priežasties šiose lentelėse ne visada apskaičiuojama kontrolinė suma (laukas paliekamas niekinis).

Likę įrašai nurodo įvairius dvejetainius failus, kuriuos reikia išanalizuoti/vykdyti prieš paleidžiant BIOS, t.y. prieš perjungdami į senąjį RESET vektorių (FFFF FFF0h). Kiekvieno tokio įrašo struktūra yra tokia:

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

Lauke EntryType nurodomas bloko tipas, į kurį nukreipiamas šis įrašas. Mes žinome keletą tipų:

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

Dabar akivaizdu, kad vienas iš įrašų nurodo „Intel BG“ paleidimo ACM dvejetainio failo vietą. Šio dvejetainio failo antraštės struktūra būdinga „Intel“ sukurtiems kodo moduliams (ACM, mikrokodų atnaujinimai, „Intel ME“ kodo skyriai, ...).

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

Procesorius įkelia šį dvejetainį failą į talpyklą, patikrina ir paleidžia.

„Intel BG“ paleisties ACM

Atlikus šio ACM darbo analizę paaiškėjo, kad jis atlieka šiuos veiksmus:

• iš Intel ME gauna Intel BG konfigūraciją, įrašytą į mikroschemų rinkinio saugiklius (FPF);
• suranda KEYM ir IBBM manifestus, juos patikrina.

Norėdami rasti šiuos aprašus, ACM taip pat naudoja FIT lentelę, kurioje yra dviejų tipų įrašai, nurodantys šias struktūras (žr. FIT_ENTRY_TYPES aukščiau).

Pažvelkime į manifestus atidžiau. Pirmojo aprašo struktūroje matome keletą neaiškių konstantų, viešojo rakto maišą iš antrojo aprašo ir viešąjį OĮG šakninį raktą, pasirašytą kaip įdėta struktūra:

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

Norėdami patikrinti OEM šakninio rakto viešąjį raktą, primename, kad naudojama SHA256 maiša iš saugiklių, kuri šiuo metu jau gauta iš „Intel ME“.

Pereikime prie antrojo manifesto. Jį sudaro trys struktūros:

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

Pirmajame yra keletas 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
};

Antrajame yra IBB maiša SHA256 ir deskriptorių, apibūdinančių IBB turinį (t. y. iš ko apskaičiuojama maiša), skaičius:

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 aprašai vienas po kito laikosi šios struktūros. Jų turinys yra tokio formato:

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

Tai paprasta: kiekviename deskriptoriuje yra IBB gabalo adresas / dydis. Taigi blokų, kuriuos nurodo šie deskriptoriai (pačių aprašų tvarka), sujungimas yra IBB. Ir, kaip taisyklė, IBB yra visų SEC ir PEI fazių modulių derinys.

Antrasis aprašas baigiasi struktūra, kurioje yra IBB viešasis raktas (patvirtintas SHA256 maišos iš pirmojo aprašo) ir šio aprašo parašas:

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

Taigi, dar prieš pradedant UEFI BIOS vykdymą, procesorius paleis ACM, kuris patikrins sekcijų turinio autentiškumą su SEC ir PEI fazės kodu. Tada procesorius išeina iš ACM, juda RESET vektoriumi ir pradeda vykdyti BIOS.

PEI patvirtintame skaidinyje turi būti modulis, kuris patikrins likusią BIOS dalį (DXE kodas). Šį modulį jau kuria IBV (Independent BIOS Vendor) arba pats sistemos tiekėjas. Nes Mūsų žinioje pasirodė tik Lenovo ir Gigabyte sistemos ir turėdami Intel BG palaikymą, panagrinėkime iš šių sistemų ištrauktą kodą.

UEFI BIOS modulis LenovoVerifiedBootPei

„Lenovo“ atveju tai buvo „Lenovo“ sukurtas „LenovoVerifiedBootPei“ {B9F2AC77-54C7-4075-B42E-C36325A9468D} modulis.

Jo užduotis yra surasti (pagal GUID) DXE maišos lentelę ir patikrinti 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 modulis BootGuardPei

„Gigabyte“ atveju paaiškėjo, kad tai yra „BootGuardPei“ {B41956E1-7CA2-42DB-9562-168389F0F066} modulis, sukurtas AMI, todėl yra bet kurioje AMI BIOS su „Intel BG“ palaikymu.

Jo veikimo algoritmas šiek tiek skiriasi, tačiau jis yra tas pats:

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

Maišos lentelės {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} formatas yra toks:

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

Trumpai pakalbėkime apie kitą Intel Boot Guard įgyvendinimą, kuris buvo rastas naujesnėje sistemoje, paremtoje Intel SoC su Apollo Lake mikroarchitektūra – ASRock J4205-IT.

Nors ši versija bus naudojama tik SoC (naujose sistemose su „Kaby Lake“ procesoriaus mikroarchitektūra ir toliau naudojama „Intel Boot Guard 1.x“), ji labai domina naujos architektūros parinktį, skirtą platformoms, pagrįstoms „Intel SoC“, kuri tapo apčiuopiama. pakeitimai, pavyzdžiui:

• BIOS ir Intel ME regionai (tiksliau Intel TXE, pagal Intel SoC terminologiją) dabar yra vienas IFWI regionas;
• nors platformoje buvo įjungtas „Intel BG“, „flash“ atmintyje nerasta tokių struktūrų kaip FIT, KEYM, IBBM;
• be TXE ir ISH branduolių (x86), į mikroschemų rinkinį buvo įtrauktas trečias branduolys (beje, vėl ARC) - PMC (Power Management Controller), susijęs su maitinimo posistemio veikimo užtikrinimu ir veikimo stebėjimu.

Naujojo IFWI regiono turinys yra šių modulių rinkinys:

Kompensacija
pavadinimas
aprašymas

0000 2000 val
SMIP
tam tikra platformos konfigūracija, pasirašyta pardavėjo

0000 6000 val
RBEP
„Intel TXE“ programinės įrangos kodo skyrius, x86, pasirašytas „Intel“.

0001 0000 val
PMCP
programinės įrangos kodo skyrius Intel PMC, ARC, pasirašytas Intel

0002 0000 val
FTPR
„Intel TXE“ programinės įrangos kodo skyrius, x86, pasirašytas „Intel“.

0007B000h
UCOD
„Intel“ pasirašyti procesoriaus mikrokodo atnaujinimai

0008 0000 val
IBBP
UEFI BIOS, SEC/PEI fazės, x86, pardavėjas pasirašytas

0021 8000 val
ISHC
Pardavėjo pasirašytos „Intel ISH“ programinės įrangos x86 kodo skyrius

0025 8000 val
FTP
„Intel TXE“ programinės įrangos kodo skyrius, x86, pasirašytas „Intel“.

0036 1000 val
IUNP
nežinoma

0038 1000 val
OBBP
UEFI BIOS, DXE fazė, x86, nepasirašyta

Analizuojant TXE programinę-aparatinę įrangą, tapo akivaizdu, kad po RESET TXE išlaiko procesorių tokioje būsenoje, kol paruošia pagrindinį procesoriaus adresų erdvės turinį (FIT, ACM, RESET vektorius ...). Be to, TXE įdeda šiuos duomenis į savo SRAM, po to laikinai suteikia procesoriui ten prieigą ir „išleidžia“ iš RESET.

„Rootkit“ apsauga

Na, o dabar pereikime prie „karštojo“. Kartą atradome, kad daugelyje sistemų SPI „flash“ aprašai turi leidimus pasiekti SPI „flash“ atminties regionus, kad visi šios atminties vartotojai galėtų rašyti ir skaityti bet kurį regioną. Tie. negali būti.

Patikrinus su MEinfo programa (iš Intel STK), pamatėme, kad gamybos režimas šiose sistemose nebuvo uždarytas, todėl mikroschemų rinkinio saugikliai (FPF) buvo palikti neapibrėžtos būsenos. Taip, tokiais atvejais Intel BG nėra nei įjungtas, nei išjungtas.

Mes kalbame apie šias sistemas (kalbant apie Intel BG ir tai, kas bus aprašyta vėliau straipsnyje, kalbėsime apie sistemas su Haswell procesoriaus mikroarchitektūra ir naujesne versija):

• visi Gigabyte produktai;
• visi MSI produktai;
• 21 Lenovo nešiojamojo kompiuterio modelis ir 4 Lenovo serverių modeliai.

Žinoma, apie radinį pranešėme šiems pardavėjams, taip pat „Intel“.

Adekvatus atsakymas sekė tik nuo "Lenovo"kuris pripažino problemą ir išleido pleistrą.

"Gigabyte Panašu, kad informaciją apie pažeidžiamumą jie priėmė, tačiau niekaip nekomentavo.

Bendravimas su MSI visiškai sustojo mūsų prašymu išsiųsti viešąjį PGP raktą (siekiant išsiųsti jiems užšifruotą saugos pranešimą). Jie pareiškė, kad jie „yra techninės įrangos gamintojai ir negamina PGP raktų“.

Bet daugiau prie esmės. Kadangi saugikliai paliekami neapibrėžtoje būsenoje, vartotojas (arba užpuolikas) gali juos užprogramuoti pats (sunkiausia yra rasti Intel STK). Tam reikia atlikti šiuos veiksmus.

1. Paleiskite į Windows OS (paprastai toliau aprašytus veiksmus galima atlikti ir iš Linux, jei kuriate Intel STK analogą norimai OS). Naudodami MEinfo programą įsitikinkite, kad šios sistemos saugikliai nėra užprogramuoti.

2. Skaitykite „flash“ atminties turinį naudodami „Flash“ programavimo įrankį.

3. Atidarykite skaitytą vaizdą naudodami bet kurį UEFI BIOS redagavimo įrankį, atlikite reikiamus pakeitimus (pavyzdžiui, įdiekite rootkit), sukurkite / redaguokite esamas KEYM ir IBBM struktūras ME regione.

Paveikslėlyje paryškinta viešoji RSA rakto dalis, kurios maiša bus užprogramuota mikroschemų rinkinio saugikliuose kartu su likusia Intel BG konfigūracija.

4. Naudodami „Flash Image Tool“ sukurkite naują programinės įrangos atvaizdą (nustatydami „Intel BG“ konfigūraciją).

5. Parašykite naują vaizdą, kurį norite „flash“, naudodami „Flash“ programavimo įrankį, naudodami MEinfo patikrinkite, ar ME regione dabar yra „Intel BG“ konfigūracija.

6. Norėdami uždaryti gamybos režimą, naudokite „Flash“ programavimo įrankį.

7. Sistema bus paleista iš naujo, o po to naudodami MEinfo galėsite patikrinti, ar FPF dabar užprogramuoti.

Šie veiksmai per amžių amžius įgalinkite „Intel BG“ šioje sistemoje. Veiksmo anuliuoti bus neįmanoma, o tai reiškia:

• Tik privačios pagrindinio rakto dalies savininkas (t. y. tas, kuris įgalino „Intel BG“) galės atnaujinti UEFI BIOS šioje sistemoje;
• jei grąžinsite originalią programinę-aparatinę įrangą šiai sistemai, pavyzdžiui, naudodami programuotoją, ji net neįsijungs (vykdymo politikos pasekmė įvykus patikrinimo klaidai);
• norint atsikratyti tokios UEFI BIOS, reikia pakeisti mikroschemų rinkinį su programuotais FPF į „švarų“ (t.y. perlituoti lustų rinkinį, jei turi prieigą prie infraraudonųjų spindulių litavimo stotelės už automobilio kainą, arba tiesiog pakeisti pagrindinę plokštę ).

Norėdami suprasti, ką gali padaryti toks rootkit, turite įvertinti, kas leidžia vykdyti jūsų kodą UEFI BIOS aplinkoje. Tarkime, labiausiai privilegijuotu procesoriaus režimu - SMM. Toks rootkit gali turėti šias savybes:

• būti vykdomas lygiagrečiai su OS (galite sukonfigūruoti apdorojimą generuodami SMI pertraukimą, kurį suaktyvins laikmatis);
• turėti visus SMM režimo privalumus (visa prieiga prie RAM ir aparatinės įrangos išteklių turinio, slaptumas nuo OS);
• Rootkit kodas gali būti užšifruotas ir iššifruotas, kai jis paleistas SMM režimu. Bet kokie tik SMM režimu pasiekiami duomenys gali būti naudojami kaip šifravimo raktas. Pavyzdžiui, maiša iš adresų rinkinio SMRAM. Norėdami gauti šį raktą, turėsite patekti į SMM. Ir tai galima padaryti dviem būdais. Raskite RCE SMM kode ir išnaudokite jį arba pridėkite savo SMM modulį prie BIOS, o tai neįmanoma, nes įjungėme Boot Guard.

Taigi šis pažeidžiamumas leidžia užpuolikui:

• sukurti paslėptą, nepašalinamą nežinomos paskirties rootkit sistemoje;
• Vykdykite savo kodą viename iš „Intel SoC“ mikroschemų rinkinio branduolių, būtent „Intel ISH“ (atidžiau pažiūrėkite į paveikslėlį).

Nors Intel ISH posistemio galimybės dar neištirtos, atrodo, kad tai įdomus atakos vektorius prieš Intel ME.

išvados

1. Tyrime buvo pateiktas techninis Intel Boot Guard technologijos veikimo aprašymas. Minus pora „Intel“ saugumo paslapčių per neaiškumų modelį.
2. Pateikiamas atakos scenarijus, leidžiantis sistemoje sukurti neišimamą rootkit.
3. Matėme, kad šiuolaikiniai „Intel“ procesoriai gali vykdyti daug patentuoto kodo dar prieš paleidžiant BIOS.
4. Platformos su Intel 64 architektūra tampa vis mažiau tinkamos paleisti nemokama programinė įranga: aparatinės įrangos patikrinimas, vis daugiau patentuotų technologijų ir posistemių (trys branduoliai SoC mikroschemų rinkinyje: x86 ME, x86 ISH ir ARC PMC).

Sušvelninimai

Pardavėjai, kurie tyčia palieka atidarytą gamybos režimą, tikrai turėtų jį uždaryti. Kol kas jie tik užsimerkia ir naujosios Kaby Lake sistemos tai rodo.

Vartotojai gali išjungti „Intel BG“ savo sistemose (kurioms įtakos turi aprašytas pažeidžiamumas) paleisdami „Flash“ programavimo įrankį su parinktimi -closemnf. Pirmiausia turėtumėte įsitikinti (naudodami MEinfo), kad Intel BG konfigūracija ME regione numato tiksliai išjungti šią technologiją po programavimo FPF.

Šaltinis: www.habr.com