Šrödingeri usaldusväärne laadimine. Intel Boot Guard

Räägime jälle madalast tasemest ja kõneleme x86-ühilduvate arvutusplatvormide tarkvarade turvalisusest. Seekord on uurimise peamine komponent Intel Boot Guard (mitte segi ajada Intel BIOS Guard'iga!) – riistvaraliselt toetatud BIOS-i usaldusväärse käivitamise tehnoloogia, mille tootja saab tootmisprotsessi käigus pidevalt aktiveerida või deaktiveerida. Uurimise retsept on meile juba tuttav: viilutada rikka pikaajalise analüüsi abil selle tehnoloogia rakendust, kirjeldada selle arhitektuuri, täiendades dokumenteerimata detailidega, lisada maitse järgi rünnakusuundi ning segada kokku. Tuleb lisada ka tuleku jutustamine, kuidas mitmete tootjate pikaajaline tootmisviga võimaldab potentsiaalsetel kurjategijatel kasutada seda tehnoloogiat süsteemis eemaldamatute (isegi programmeerija poolt) varjatud rootkitide loomiseks.

Muide, artikli aluseks on ettekanded "Ruutkittide kaitsel: Intel BootGuard" konverentsil ZeroNights 2016 ja 29. kohtumine DefCon Russia (mõlemad esitlused siit).

Arvutusplatvormi tarkvara Intel 64 arhitektuuriga

Alustuseks vastame küsimusele: mis on tänapäeva Intel 64 arhitektuuri arvutiplatvormi püsivara? Muidugi, UEFI BIOS. Kuid see vastus ei ole täpne. Vaatame joonist, kus on kujutatud selle arhitektuuri lauaarvuti (või sülearvuti) versiooni.

Aluseks on kombinatsioon:

• Protsessor (CPU, Central Processing Unit), kuhu on integreeritud graafikatuum (kui mitte kõigis mudelites) ja mälukontroller (IMC, Integrated Memory Controller);
• Kiibist (PCH, Platform Controller Hub), mis sisaldab erinevaid kontrollerite komponente, mis suhtlevad perifeersete seadmetega ning haldavad all süsteeme. Nende seas on ka tuntud Intel Management Engine (ME), millel on samuti oma püsivara (Intel ME firmware).

Sülearvutites eeldatakse, et lisaks ülaltoodud komponentidele on olemas ka sisseehitatud kontroller (ACPI EC, Advanced Control and Power Interface Embedded Controller), mis vastutab toitesüsteemi, puuteplaadi, klaviatuuri, Fn-klahvide (ekraani heledus, heli valjus, klaviatuuri valgustus jne) ja muu töövõime eest. Ka sellel on oma püsivara.

Seega on ülaltoodud püsivara kogum arvutiplatvormi püsivara (system firmware), mis salvestatakse ühisesse SPI välkmälusse. Et kasutajad ei segaks, kellel on milline, on see mälu jagatud järgnevateks piirkondadeks (nagu on näidatud joonisel):

• UEFI BIOS;
• ACPI EC püsivara (eraldi piirkond ilmus koos Skylake protsessori mikroarhitektuuriga (2015. aasta), kuid praktikas ei ole me veel näinud selle kasutamise näiteid, seega jääb sisseehitatud kontrolleri püsivara endiselt UEFI BIOS-i koostisosaks);
• Intel ME püsivara;
• integreeritud GbE (Gigabit Ethernet) võrkaadlase konfiguratsioon (MAC-aadress jne);
• välkmälude descriptorid (Flash Descriptors) – peamine välkmälu piirkond, mis sisaldab viiteid teistele piirkondadele ning juurdepääsus lubade haldamist.

SPI-vööndi haldamine (s vastavalt määratud lubadele) toimub SPI-sillaga, mis on integreeritud SPI-kontrollerisse, mille kaudu pääseb juurde sellele mälule. Kui loodud load on Intel'i soovitatud väärtustes (turvalisuse kaalutlustel), siis on iga SPI flash-mälu kasutajal täielik ligipääs (lugemine/kirjutamine) ainult oma piirkonnale. Ülejäänud on kas ainult lugemiseks või üldse ligipääsetavad. On teada, et paljudes süsteemides on CPU-l täielik ligipääs UEFI BIOS-ile ja GbE-le, lugemisõigus ainult flash-deskriptoritele ning Intel ME piirkonnale ei ole üldse ligipääsu. Miks paljudes, mitte kõigis? See, mis on soovitatav, ei ole tingimata kohustuslik. Loodame sellest rohkem rääkida artikli edasises osas.

Arvutiplatvormi püsivara kaitsemehhanismid modifitseerimise vastu

On ilmne, et arvutiplatvormi püsivara tuleks kaitsta võimaliku kompromiteerimise vastu, mis võiks võimaldada potentsiaalsel ründajal süsteemi jääda (elu uuendustes / OS-i uuesti installimises), käivitada oma koodi kõige privileege pakkuvatel režiimidel jne. Ja juurdepääsu jagamine SPI flash-mälu piirkondadele ei ole loomulikult piisav. Seetõttu kasutatakse püsivara kaitsmiseks muudatuste eest erinevaid mehhanisme, mis on spetsiifilised iga täitmiskeskkonna jaoks.

Näiteks on Intel ME püsivara allkirjastatud, et kontrollida terviklikkust ja autentsust, ning seda kontrollitakse ME-kontrolleri poolt iga kord, kui see laaditakse ME UMA mällu. Seda kontrollimisprotsessi oleme juba käsitlenud ühes meie artiklites, mis käsitleb Intel ME alamsüsteemi.

ACPI EC püsivara kontrollitakse tavaliselt vaid terviklikkuse osas. Kuid kuna see binaarosa on osa UEFI BIOS-ist, kehtivad sellele peaaegu alati samad kaitsemehhanismid, mida kasutab UEFI BIOS. Nendest räägimegi.

Need mehhanismid võib jagada kahte kategooriasse.

Kirjutuskaitse UEFI BIOS piirkonnas

1. SPI flash-mälu sisu füüsiline kaitse write-protect jumperiga;
2. UEFI BIOS-i piirkonna kaitse CPU aadressiruumi PRx registreerimiseks chipseti kaudu;
3. Katsed UEFI BIOS-i piirkonna kirjutamisõiguste lukustamine vastava SMI katkestuse genereerimise ja töötlemise kaudu chipseti BIOS_WE/BLE ja SMM_BWP bitide seadistamisega;
4. Kavandatud kaitse edasiarendus on Intel BIOS Guard (PFAT).

Lisaks nendele mehhanismidele saavad tarnijad arendada ja rakendada ka oma turvameetmeid (näiteks UEFI BIOS-i uuenduste kapslite allkirjastamine).

Oluline on märkida, et konkreetses süsteemis (tarnijast sõltuvalt) ei pruugi rakenduda kõik eespool nimetatud kaitsemehhanismid, need ei pruugi üldse rakenduda või võivad olla haavatavalt rakendatud. Täpsemalt nende mehhanismide ja nende rakendamise olukorra kohta saab lugeda selles artiklis. Soovitame huvilistel tutvuda terve UEFI BIOS-i turvateemaline artiklite tsükkel CodeRush.

UEFI BIOS-i autentimise kontrollimine

Kui räägime usaldusväärsete käivitustehnoloogiate kohta, tuleb esimesena meelde Secure Boot. Siiski on see arhitektuuriliselt mõeldud UEFI BIOS'ile väliste komponentide (draiverite, käivitajate jne) autentimise kontrollimiseks, mitte selle enda püsivara kontrollimiseks.

Seetõttu rakendas Intel 2012. aastal Bay Trail mikroarhitektuuriga SoC-ides riistvaralist mitteväljalülitatavat Secure Boot'i (Verified Boot), mis ei ole seotud eelnevalt mainitud Secure Boot tehnoloogiaga. Hiljem (2013. aastal) täiustati seda mehhanismi ja see toodi turule Intel Boot Guard nime all lauaarvutitele Haswell mikroarhitektuuriga.

Enne Intel Boot Guard'i kirjeldamist uurime Intel 64 arhitektuuri täitmise keskkondi, mis samal ajal on selle usaldusväärse käivitustehnoloogia usaldusallikad.

Intel CPU

Käp ütleb, et protsessor on põhiline täitmise keskkond Intel 64 arhitektuuris. Miks ta on usaldusallikas? Tundub, et see tuleneb tema järgmistest omadustest:

• Mikrokood ROM — volatility-free, non-rewritable memory for storing microcode. It is believed that microcode is the implementation of the processor's instruction set in simple commands. Bugs can also occur in microcode. bugs. Therefore, the BIOS can contain binaries with microcode updates (applied during boot time, as ROM cannot be rewritten). The content of these binaries is encrypted, which greatly complicates analysis (thus, specific microcode content is known only to those who develop it) and is signed to ensure integrity and authenticity;
• AES key for decrypting the content of the microcode updates;
• hash of the RSA public key used to verify the signature of the microcode updates;
• hash of the RSA public key used to verify the signature of the Intel company's ACM (Authenticated Code Module) code modules, which the CPU can execute before BIOS execution begins (hello microcode) or during its operation in case of certain events.

Intel ME

Our blog has even dedicated two artikkel. Tulet teadmiseks, et see täitmis keskkond põhineb mikrokontrolleris, mis on integreeritud kiibistikku ja on süsteemis kõige varjatum ja privileege täis.

Hoolimata oma varjatusest on Intel ME usaldusallikas, kuna sellel on:

• ME ROM — energiat mitte vajav, mitte ümbertõstetav mälu (uuendamise võimalust ei ole ette nähtud), mis sisaldab käivituskoodi ning SHA256 RSa avaliku keyhashi, millega kontrollitakse Intel ME püsivara allkirja;
• AES-võti salajase teabe säilitamiseks;
• aitab pääseda kiibistikuga integreeritud fuse'ide komplektile (FPFs, Field Programmable Fuses), et püsivalt salvestada teatud teavet, sealhulgas selliseid, nagu on määranud arvutisüsteemi tarnija.

Intel Boot Guard 1.x

Väike vabandus. Intel Boot Guardi tehnoloogia versiooninumbrid, millega me selles artiklis opereerime, on tinglikud ja ei pruugi mingil moel vastata numbritele, mida kasutatakse Intel'i sise-dokumentatsioonis. Lisaks võivad siin toodud andmed selle tehnoloogia rakendamise kohta olla saadud tagasitehnoloogia abil ja need võivad sisaldada ebatäpsusi võrreldes Intel Boot Guard'i spetsifikatsiooniga, mis tõenäoliselt kunagi ei avalikustata.

Nii et Intel Boot Guard (BG) on riistvaraliselt toetatud UEFI BIOS'i autentimise tehnoloogia. Lähtuvalt selle väikesest kirjelduse lõigust raamatus [Platform Embedded Security Technology Revealed, Peatükk Boot with Integrity, or Not Boot] toimib see kui usaldusväärne käivitusketi element. Ja esimene lüli selles on käivituskood (mikrokood), mis on CPU sees ja mis aktiveeritakse RESET sündmuse korral (ära sega seda BIOS'i RESET-vektoriga!). CPU leiab SPI välkmälust Intel'i välja töötatud ja allkirjastatud koodimooduli (Intel BG startup ACM), laadib selle oma vahemällu, verifitseerib (eelnevalt mainitud, et CPU-l on selleks avaliku võtme hash, millega kontrollitakse ACM'i allkirja) ja käivitab.

See koodimoodul vastutab UEFI BIOS-i väikese algusosa — algse laadimissektori (IBB) tuvastamise eest, mis omakorda sisaldab funktsionaalsust UEFI BIOS-i põhiosa tuvastamiseks. Nii võimaldab Intel BG veenduda BIOS-i autentsuses enne operatsioonisüsteemi käivitamist (mis võib toimuda Secure Boot tehnoloogia järelevalve all).

Intel BG tehnoloogia hõlmab kahte töörežiimi (kusjuures üks ei sega teist, st mõlemad režiimid võivad olla süsteemis sisselülitatud või välja lülitatud).

Measured Boot

Measured Boot (MB) režiimis "mõõdab" iga laadimisosa (alustades CPU boot ROM-ist) järgmist, kasutades TPM (Trusted Platform Module) võimalusi. Neile, kes ei ole kursis, anname lühikese seletuse.

TPM-il on PCR-id (Platform Configuration Registers), kuhu salvestatakse sõnumi hashimise tulemused, kasutades valemit:

Seega sõltub praegune PCR-i väärtus eelmisest, kusjuures andmed registreid nullitakse ainult süsteemi RESET-i korral.

Seega, MB-režiimis peegeldavad PCR-id mingil hetkel unikaalset (vastavalt hashing-operations võimalustele) koodi või andmete identifikaatorit, mis on "mõõdetud". PCR-i väärtusi võib kasutada mõnede andmete krüpteerimise operatsioonides (TPM_Seal). Pärast seda on nende dekodeerimine (TPM_Unseal) võimalik ainult siis, kui PCR-i väärtused ei ole laadimise käigus muutunud (st ühtegi "mõõdetud" komponenti ei ole modifitseeritud).

Verified Boot

Verified Boot (VB) režiim on kõige hirmutavam UEFI BIOS-i modifitseerimise armastajate jaoks, kuna iga käivitamise komponent kontrollib krüptograafiliselt järgmise terviklikkust ja ehtsust. Ja kui kontrollimisel tekib viga, toimub üks järgmistest:

• väljalülitamine 1 minutist 30 minutini (et kasutaja saaks aru, miks tema arvuti ei käivitu ja vajadusel prooviks BIOS-i taastada);
• kohene väljalülitamine (et kasutaja ei oleks suuteline aru saama ja veel vähem midagi tegema);
• töötamine rahuliku näoga (tuleb ette haruldasi olukordi, kus turvalisus ei ole prioriteet, kuna tegemist on olulisematega).

Tegevuse valik sõltub määratud Intel BG konfiguratsioonist (nimelt nn enforcement policy), mis on arvutiplatvormi müüja püsivalt salvestatud spetsiaalsesse salvestusse – chipseti fuse'desse (FPF-id). Sellel hetkel peatume hiljem rohkem.

Lisaks konfiguratsioonile genereerib müüja kaks RSA 2048 võtit ja loob kaks andmestruktuuri (nagu on kujutatud pildil):

1. Müüja juurvõtme manifest (KEYM, OEM Root Key Manifest), kuhu lisatakse selle manifesti SVN (Security Version Number), järgnevate manifestide SHA256 rämps, RSA avalik võtme (st müüja juurvõtme avalik osa) allkirja kontrollimiseks ja ise allkiri;
2. IBB manifest (IBBM, Initial Boot Block Manifest), kuhu lisatakse selle manifesti SVN, IBB SHA256 rämps, allkirja kontrollimiseks avalik võtme ja ise allkiri.

OEM Root Key SHA256 avaliku võtme hash salvestatakse püsivalt kiibi fusioonides (FPF), nagu ka Intel BG konfiguratsioonis. Kui Intel BG konfiguratsioon võimaldab selle tehnoloogia aktiveerimist, siis alates sellest hetkest saab antud süsteemis BIOS-i uuendada (st nende manifestide uuesti arvutamine) ainult OEM Root Key privaatse osa omanik, st tarnija.

Pildile vaadates tekivad kohe küsimused, kas on tõepoolest vajalik nii pikk kontrollimisõhk — oleks võinud kasutada üht manifesti. Miks keerulisemaks muuta?

Tegelikult annab Intel sel viisil tarnijale võimaluse kasutada erinevaid IBB võtmeid oma toodete erinevate rida jaoks ning üht — juurena. Kui IBB võtme privaatne osa (millega teine manifest allkirjastatakse) lekib, mõjutab intsident ainult üht toote seeriat ja ainult seni, kuni tarnija genereerib uue paari ja hõlvab arvutatud manifestid järgmises BIOS-i uuenduses.

Kuid kui juurvõti (mille abil allkirjastatakse esimene manifakt) on kompromiteeritud, ei ole selle vahetamine võimalik, kuna revokatsiooniprotseduuri ei ole ette nähtud. Selle põhivõtme avaliku osa hash on programmeeritud FPF-idesse üks kord ja igaveseks.

Intel Boot Guardi konfiguratsioon

Nüüd vaatame lähemalt Intel BG konfiguratsiooni ja selle loomise protsessi. Kui vaadata Intel System Tool Kit (STK) komplekti Flash Image Tool kasutajaliideses vastavat vahekaarti, on näha, et Intel BG konfiguratsioon sisaldab tootja juurvõtme avaliku osa hash'i, 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 midagi teha
                                              // 01b – väljalülitamine ajaga
                                              // 11b – kohene väljalülitamine
	unsigned long : 26;
};

Üldiselt on Intel BG konfiguratsioon väga paindlik. Vaatame näiteks lippu Force_Boot_Guard_ACM. Kui see on välja lülitatud ja kui BG startup ACM mitte leiab SPI välkmälust, siis ei toimu usaldusväärset laadimist. Toimub usaldusväärne laadimine.

Oleme juba varem maininud, et VB režiimi jõustamispoliitikat saab seadistada nii, et kinnituse tõrke korral toimub jällegi usaldusväärne laadimine.

Jätta sellised asjad tarnijate otsustada…

GUI tööriist sisaldab järgmisi "valmis" profiile:

Number
Režiim
Kirjeldus

0
No_FVME
Intel BG tehnoloogia on väljas

1
VE
VB režiim on aktiveeritud, väljalülitus ajapiiranguga

2
VME
mõlemad režiimid (VB ja MB) on aktiveeritud, väljalülitus ajapiiranguga

3
VM
mõlemad režiimid on aktiveeritud, süsteemi ei väljalülitata

4
FVE
VB režiim on aktiveeritud, kohene väljalülitus

5
FVME
mõlemad režiimid on aktiveeritud, kohene väljalülitus

Kuna juba mainitud, peab Intel BG konfiguratsioon olema üks kord ja igaveseks tarnija poolt kirjutatud süsteemi fusioonidesse (FPF-id) – väikesele (väidetavalt ainult 256 baidi) riistvaralisele andmehoidla, mis asub kiibistikus ja mida saavad programmeerida väljaspool ettevõtte Intel tootmisvõimekust (seetõttu just Field Programmable Fuses).

See on suurepärane konfiguratsiooni salvestamiseks, kuna:

• tal on ühekordselt programmeeritav ala andmete salvestamiseks (just sinna, kuhu salvestatakse Intel BG konfiguratsioon);
• seda suudab lugeda ja programmeerida ainult Intel ME.

Seega, et konfiguratsioon teha Intel BG tehnoloogiat konkreetsele süsteemile, teostab tootja tootmisprotsessi käigus järgmist:

1. Intel STK-s asuva Flash Image Tooli abil loob ta spetsifitseeritud Intel BG konfiguratsiooni firmavariandi (nn ajutine peegel FPF-ide jaoks);
2. Flash Programming Tooli abil (ka Intel STK-s) kirjutab selle pildi süsteemi SPI vilkuvale mälule ja lõpetab nn tootmisrežiimi (samal ajal saadetakse vastav käsk Intel ME-le).

Nende toimingute tulemusena kinnitab Intel ME FPF-idesse peeglisse salvestatud väärtused ja seadistab SPI vilkuva mälu descriptorid soovitatavateks ettevõtte Intel väärtusteks (nagu artikli alguses kirjeldatud) ning teostab süsteemi RESET-i.

Intel Boot Guardi implementatsiooni analüüs

Konkreetse näite analüüsimiseks kontrollisime järgmisi süsteeme Intel BG tehnoloogia jälgede osas:

Süsteem
Märkus

Gigabyte GA-H170-D3H
Skylake, toetus olemas

Gigabyte GA-Q170-D3H
Skylake, toetus olemas

Gigabyte GA-B150-HD3
Skylake, toetus olemas

MSI H170A Gaming Pro
Skylake, toetus puudub

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

Lenovo Yoga 2 Pro
Haswell, toetus puudub

Lenovo U330p
Haswell, toetus puudub

Allal "toetuse" all mõistetakse Intel BG käivitamise ACM mooduli olemasolu, eespool mainitud manifestide ja vastava koodi olemasolu BIOS-is, st rakendust analüüsimiseks.

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

Intel CPU käivitamise ROM

Esiteks räägime processor'i tegevustest, kui Intel BG tehnoloogia on aktiveeritud.

Dekodeeritud mikroprogrammi näidiseid ei leitud, seetõttu on küsimus, kuidas allpool kirjeldatud tegevused on rakendatud (mikroprogrammis või riistvaras) endiselt avatud. Sellegipoolest on fakt, et kaasaegsed Intel protsessorid "oskavad" neid toiminguid teostada.

Pärast RESET olekust väljumist leiab protsessor (mille aadressiruumi on juba mappitud flash-mälu sisu) FIT (Firmware Interface Table) tabeli. Selle leidmine on lihtne, viidatud aadress on kirjutatud aadressile FFFF FFC0h.

Täpsemal juhul on sellel aadressil väärtus FFD6 9500h. Kui protsessor pöördub sellele aadressile, näeb ta FIT tabelit, mille sisu on jagatud kirjeteks. 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;
};

Tundub, et kontrollsummat ei arvestata nendes tabelites sageli (väli jääb nulliks).

Ülejäänud kirjed viitavad erinevatele binaarfailidele, mille need tuleb parsoida/teostada enne BIOSi käivitamist, st enne üleminekut pärand 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;
};

EntryType väli näitab ploki tüüpi, millele see 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
};

On nüüd selge, et üks kirje viitab Intel BG käivitamise ACM binaari asukohale. Selle binaari päise struktuur on tüüpiline Intel ettevõtte arendatud koodimoodulitele (ACM-ed, mikrokoodi värskendused, Intel ME koodijooned, …).

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 binaari enda vahemällu, kinnitab selle ja käivitab.

Intel BG käivitamise ACM

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

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

Nende manifestide leidmiseks kasutab ACM samuti FIT tabelit, kus on määratud kaks tüüpi kirjeid struktuuri andmete näitamiseks (vt FIT_ENTRY_TYPES eespool).

Keskendume lähemalt manifestidele. Esimese manifesti struktuuris näeme mitmeid ebaselgeid konstante, teise manifesti avaliku võti ja avaliku võtme OEM Root Key koos allkirjaga, mis on 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 avalikuklahvi verifitseerimiseks kasutatakse SHA256 hash'i fuse'idest, mis on juba saadud Intel ME poolt.

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

Esimeses – mõned konstantide kirjeldused:

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-st ja number deskriptoritest, mis kirjeldavad IBB sisu (st. millest hash'i 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 formaadis:

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

Kõik on lihtne: iga deskriptor sisaldab IBB tüki aadressi/suurust. Seega, nende deskriptorite viidatud plokkide concatenatsioon (deskriptorite järjekorras) moodustab IBB. Üksikasjalikumalt on IBB kõigi SEC ja PEI faasi moodulite kogu.

Teine manifest lõpetab struktureeritud, mis sisaldab IBB avalikku võtit (kontrollitakse esimesest manifestist SHA256 hash'iga) ja selle manifesti allkirja:

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

Seega, enne UEFI BIOS käivitamist alustab protsessor ACM-i, mis kontrollib SEC ja PEI koodifaasi sektsioonide sisu autentisust. Edasi liigub protsessor ACM-ist välja, läheb RESET-vektorile ja hakkab BIOS-i täitma.

Verifitseeritud PEI sektsioon peab sisaldama moodulit, mis kontrollib BIOS-i ülejäänud osa (DXE kood). Selle mooduli arendab IBV (Independent BIOS Vendor) või süsteemi tootja ise. Kuna meie käsutuses olevad ja Intel BG-d toetavad süsteemid olid ainult Lenovo ja Gigabyte, vaatleme koodi, mis on välja tõstetud just nendest süsteemidest.

UEFI BIOS moodul LenovoVerifiedBootPei

Lenovo korral osutus see mooduliks LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, mille on arendanud Lenovo.

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

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ärgneva vorminguga:

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'i puhul osutus see olema BootGuardPei moodul {B41956E1-7CA2-42DB-9562-168389F0F066}, mille on välja töötanud AMI, seega on see olemas igas AMI BIOS-is, mis toetab Intel BG.

Selle töö algoritm on veidi teine, kuid põhineb samadel põhimõtetel:

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 hash tabel {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} on järgmise vorminguga:

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

Kuigi see versioon rakendub ainult SoC-ides (uued süsteemid Kaby Lake'i mikroarhitektuuriga jätkavad Intel Boot Guard 1.x kasutamist), on see suur huvi uue arhitektuuri variandi uurimise osas Intel SoC platvormide jaoks, kus on toimunud märgatavad muutused, näiteks:

• BIOS-i ja Intel ME (täpsemalt Intel TXE, vastavalt Intel SoC terminoloogiale) piirkonnad on nüüd üks IFWI piirkond;
• Kuigi platvormil oli sisse lülitatud Intel BG, ei leitud mälust selliseid struktuure nagu FIT, KEYM, IBBM;
• Lisaks x86 TXE ja ISH tuumadele on kiibistikku lisatud kolmas tuum (muide, taas ARC) – PMC (Power Management Controller), mis on seotud energiahalduse ja jõudluse jälgimise tagamisega.

Uue IFWI piirkonna sisu koosneb järgmistest moodulitest:

Asemik
Nimi
Kirjeldus

0000 2000h
SMIP
mingi platvormi konfiguratsioon, allkirjastatud tarnijaga

0000 6000h
RBEP
Intel TXE, x86, allkirjastatud Intel’i poolt, firmware koodiosa

0001 0000h
PMCP
Intel PMC, ARC, allkirjastatud Intel’i poolt, firmware koodiosa

0002 0000h
FTPR
Intel TXE, x86, allkirjastatud Intel’i poolt, firmware koodiosa

0007 B000h
UCOD
CPU mikrokoodi värskendused, allkirjastatud Intel’i poolt

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

0021 8000h
ISHC
Intel ISH, x86, allkirjastatud tarnijaga, firmware koodiosa

0025 8000h
NFTP
Intel TXE, x86, allkirjastatud Intel’i poolt, firmware koodiosa

0036 1000h
IUNP
teadmata

0038 1000h
OBBP
UEFI BIOS, DXE faas, x86, ei ole allkirjastatud

TXE firmware’ analüüsi käigus selgus, et pärast RESET-i hoiab TXE protsessorit selles olekus kuni põhilise aadressiruumi sisu valmistamiseni CPU jaoks (FIT, ACM, RESET-vektor ...). Samuti paigutab TXE need andmed endasse SRAM-i, pärast mida annab ajutiselt protsessorile sinna ligipääsu ja "vabastab" selle RESET-ist.

Rootkitide kaitsel

Käime nüüd "kuumade" teemade juurde. Üks kord avastasime, et paljudes süsteemides on SPI-flaashi descriptorites salvestatud õigused SPI-flaashmälu piirkondadele nii, et kõik selle mälu kasutajad saavad lugeda ja kirjutada ükskõik millisesse piirkonda. See tähendab, et ei mingit.

MEinfo utiliidi (Intel STK) abil kontrollides nägime, et nende süsteemide tootmisrežiim ei olnud suletud, seega on chipseti fusid (FPF-id) jätatud määramatuks. Jah, Intel BG ei ole sellistes olukordades kas sisse või välja lülitatud.

Räägime järgmistest süsteemidest (intel BG ja selle kohta, mis järgnevas artiklis kajastub, käsitleme Haswelli ja uuemate protsessori mikroarhitektuuride süsteeme):

• kogu Gigabyte'i tooteportfell;
• kogu MSI tooteportfell;
• 21 Lenovo sülearvuti mudelit ja 4 Lenovo serveri mudelit.

Loomulikult teavitasime selle leidmisest neid tootjaid ja ka ettevõtet Intel.

Adekvaatne reaktsioon järgnes ainult Lenovo, kes tunnustasid probleemi ja väljastasid plaastri.

Gigabyte kuigi nad tunnustasid haavatavuse teavet, ei kommenteerinud nad kuidagi.

Suhtlemine MSI meie palve saata oma avatud PGP-võti (et edastada neile turveteade krüpteeritud kujul) jäi täielikult toppama. Nad väitsid, et "nad on seadmete tootja ja PGP-võtmeid ei tooda."

Aga läheme asja juurde. Kuna fusid on jäetud määramata olekusse, saab kasutaja (või ründaja) need ise programmeerida (kõige keerulisem on leida Intel STK). Selleks on vaja teha järgmised toimingud.

1. Laadige Windowsi opsüsteemi (üldiselt, järgmisi toiminguid saadakse teha ka Linuxilt, kui arendada vajalik Intel STK selle opsüsteemi jaoks). Kasutades MEinfo utiliiti, veenduge, et fusid ei ole antud süsteemis programmeeritud.

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

3. Avage loetud pilt igasuguste UEFI BIOSi redigeerimise vahenditega, tehke vajalikud muudatused (näiteks sisestage rootkit), looge/muudetage olemasolevad KEYM ja IBBM struktuurid ME piirkonnas.

Pildil on esile tõstetud RSA võtme avalik osa, mille hash programmeeritakse koos muu Intel BG konfiguratsiooniga kiibi fusidesse.

4. Flash Image Tooli abil luua uus parda pildifail (seades Intel BG konfigureerimise).

5. Uue pildifaili kirjutamine välkmälu Flash Programming Tooli abil, veenduda MEinfo abil, et ME piirkond sisaldab nüüd Intel BG konfigureerimist.

6. Flash Programming Tooli abil sulgeda tooterežiim.

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

Need toimingud kehtestavad Intel BG sellel süsteemil igaveseks. Tulemusi ei saa tagasi võtta, mis tähendab: Uuendada UEFI BIOS-i sellel süsteemil saab ainult privaatse juurvõtme omanik (st see, kes aktiveeris Intel BG);

• kui proovida sellele süsteemile taastada originaal parda pildifail näiteks programmeerija kaudu, ei käivitu see isegi (tagajärg vigase tõendi olukorras);
• Selle UEFI BIOS-ist vabanemiseks tuleb asendada kiibistik, millel on programmeeritud FPF-id, "puhas" (st uuesti joota kiibistik, kui pääsete ligi infrapuna jootmisjaamale, mille hind on nagu auto, või lihtsalt asendada emaplaat).
• selliset UEFI BIOS-ist vabanemiseks on vajalik asendada FPF-idega programmeeritud kiibistik "puhta" vastu (st. kui teil on juurdepääs auto hinnalaga infrapuna jootmisjaamale, siis jootke kiibistik ümber või lihtsalt vahetage emaplaat).

Kuna mõista, mida selline rootkit teha suudab, tuleb hinnata, milliseid võimalusi annab see oma koodi täitmiseks UEFI BIOS keskkonnas. Ütleme, et see on protsessori kõige privileege antud olek – SMM. Sellisel rootkitil võivad olla järgmised omadused:

• töötada paralleelselt operatsioonisüsteemiga (saab seadistada töötamise SMI katkestuse genereerimise kaudu, mis aktiveeritakse ajastaja järgi);
• omada kõiki SMM režiimi eeliseid (täielik juurdepääs RAM-i sisule ja riistvarale, varjatus OS-i eest);
• rootkiti tarkvarakood võib olla krüpteeritud kujul ja dekrüpteeritakse SMM režiimis käivitamisel. Krüptimise võtmena võib kasutada mis tahes andmeid, mis on kergesti kätte saadavad ainult SMM režiimis. Näiteks SMRAM-i aadresside kogumi hajutamine. Selle võtme saamiseks tuleb pääseda SMM-i. Ja seda saab teha kahel viisil. Leida RCE SMM koodist ja seda ära kasutada või lisada BIOS-i oma SMM moodul, mis ei ole võimalik, kuna me oleme sisse lülitanud Boot Guard.

Seega võimaldab see haavatavus ründajal:

• luua süsteemis varjatud, eemaldamatud rootkitid teadmata otstarbeks;
• täitma oma koodi ühe Intel SoC kiibi tuuma sees, nimelt Intel ISH (vaatame pilti hoolikalt).

Kuigi Intel ISH allhangete võimeid pole veel uuritud, tundub see olevat huvitav ründesuund Intel ME-le.

Järeldused

1. Uuring võimaldas saada tehnilist kirjeldust Intel Boot Guard tehnoloogia toimimisest. Miinus paar saladust Intel'i turvalisuse mudelis, mis tugineb varjamisele.
2. Esitati rünnakuskeem, mis võimaldab süsteemis luua kustutamatut rootkit'i.
3. Näitasime, et tänapäeva Intel protsessorid suudavad käivitada palju patenteeritud koodi enne BIOS-i tööle asumist.
4. Intel 64 arhitektuuriga platvormid muutuvad järjest vähem sobilikuks vabavarade käitamiseks: riistvaraline kontroll, kasvav arv patenteeritud tehnoloogiaid ja alusüsteeme (kolm tuuma SoC kiibis: x86 ME, x86 ISH ja ARC PMC).

Leevendused

Tarnijad, kes jätavad tahtlikult tootmisrežiimi avatuks, peaksid selle kindlasti sulgema. Seni sulgevad vaid silmad ja uued Kaby Lake süsteemid seda näitavad.

Kasutajad saavad ise Intel BG-d oma süsteemides (mis on välja toodud kirjelduse järgi) välja lülitada, käivitades utiliidi Flash Programming Tool parameetriga -closemnf. Eelnevalt tuleks veenduda (MEinfo abil), et Intel BG konfigureerimine ME piirkonnas eeldab selle tehnoloogia väljalülitamist pärast FPF-ide programmeerimist.

Allikas: habr.com