Traust stígvél Schrödinger. Intel Boot Guard

Við leggjum til að fara aftur niður á lágt plan og tala um öryggi fastbúnaðar x86-samhæfra tölvukerfa. Að þessu sinni er aðaluppistaða rannsóknarinnar Intel Boot Guard (ekki að rugla saman við Intel BIOS Guard!) - vélbúnaðarstudd BIOS traust ræsitækni sem söluaðili tölvukerfis getur varanlega virkjað eða slökkt á framleiðslustigi. Jæja, við þekkjum nú þegar rannsóknaruppskriftina: Skerið smátt og smátt útfærslu þessarar tækni með öfugri verkfræði, lýsið arkitektúr hennar, fyllið hana með óskráðum smáatriðum, kryddið hana með árásarvektorum eftir smekk og blandið henni saman. Við skulum bæta eld með sögu um hvernig klónaður galla í framleiðslu nokkurra söluaðila í mörg ár gerir hugsanlegum árásarmanni kleift að nota þessa tækni til að búa til falið rótarsett sem ekki er hægt að fjarlægja (jafnvel forritara) í kerfinu.

Við the vegur, greinin er byggð á skýrslunum „On Guard for Rootkits: Intel BootGuard“ frá ráðstefnunni ZeroNights 2016 og 29. fundur DefCon Rússland (báðar kynningar hér).

Fastbúnaður fyrir tölvuvettvang með Intel 64 arkitektúr

Til að byrja með skulum við svara spurningunni: hver er vélbúnaðar nútíma tölvuvettvangs með Intel 64 arkitektúr? Auðvitað, UEFI BIOS. En þetta svar mun ekki vera rétt. Við skulum kíkja á myndina sem sýnir skrifborðsútgáfu (fartölvu) af þessum arkitektúr.

Grunnurinn er hlekkurinn:

• Örgjörvi (CPU, Central Processing Unit), sem, auk aðalkjarna, hefur innbyggðan grafíkkjarna (ekki í öllum gerðum) og minnisstýringu (IMC, Integrated Memory Controller);
• Flísasett (PCH, Platform Controller Hub), sem inniheldur ýmsa stýringar til að hafa samskipti við jaðartæki og stjórna undirkerfum. Þar á meðal er hin alræmda Intel Management Engine (ME), sem einnig er með fastbúnað (Intel ME fastbúnað).

Fartölvur, til viðbótar við ofangreint, krefjast samþættrar stýringar (ACPI EC, Advanced Control og Power Interface Embedded Controller), sem er ábyrgur fyrir rekstri raforkuundirkerfisins, snertiborðs, lyklaborðs, Fn-lykla (birtustig skjás, hljóðstyrks, lyklaborðs) baklýsingu osfrv.). ) og fleira. Og hann hefur líka sinn eigin vélbúnað.

Svo, samsetningin af ofangreindum fastbúnaði er fastbúnaður tölvuvettvangsins (kerfisfastbúnaðar), sem er geymdur á sameiginlegu SPI-flassminni. Svo að notendur þessa minnis ruglast ekki á því hvar einhver liggur, er innihaldi þessarar minnis skipt í eftirfarandi svæði (eins og sýnt er á myndinni):

• UEFI BIOS;
• ACPI EC fastbúnaðar (sérstakt svæði birtist með Skylake örgjörva örarkitektúrnum (2015), en í náttúrunni höfum við ekki enn séð dæmi um notkun þess, þannig að innbyggður stjórnandi vélbúnaðar er enn hluti af UEFI BIOS);
• Intel ME vélbúnaðar;
• stillingar (MAC vistfang, osfrv.) á innbyggða GbE (Gigabit Ethernet) net millistykkinu;
• flasslýsingar - aðalsvæði flassminni, sem inniheldur vísa til annarra svæða, auk heimilda til að fá aðgang að þeim.

Aðgreining á aðgangi að svæðum (í samræmi við tilgreindar heimildir) er meðhöndluð af SPI strætómeistaranum - SPI stjórnandi sem er innbyggður í flísasettið, þar sem aðgangur er að þessu minni. Ef heimildirnar eru stilltar á þau gildi sem Intel mælir með (af öryggisástæðum), þá hefur hver notandi SPI flasssins fullan aðgang (lesa/skrifa) aðeins að sínu svæði. Afgangurinn er annað hvort skrifvarinn eða óaðgengilegur. Þekkt staðreynd: á mörgum kerfum hefur örgjörvinn fullan aðgang að UEFI BIOS og GbE, lesaðgang aðeins að flasslýsingum og alls enginn aðgangur að Intel ME svæðinu. Hvers vegna margir og ekki allir? Það sem mælt er með er valfrjálst. Við munum segja þér meira síðar í greininni.

Aðferðir til að vernda fastbúnað tölvuvettvangs fyrir breytingum

Augljóslega ætti að verja fastbúnað tölvuvettvangs fyrir hugsanlegri málamiðlun, sem myndi gera hugsanlegum árásarmanni kleift að ná fótfestu í honum (lifa af stýrikerfisuppfærslur / enduruppsetningar), keyra kóðann sinn í forréttindastillingum osfrv. Og að afmarka aðgang að SPI-flassminnissvæðum er auðvitað ekki nóg. Þess vegna eru ýmsar aðferðir sem eru sértækar fyrir hvert framkvæmdarumhverfi notaðar til að vernda fastbúnaðinn fyrir breytingum.

Svo, Intel ME fastbúnaðurinn er undirritaður fyrir heilleika og áreiðanleikastýringu og er athugaður af ME stjórnandi í hvert skipti sem honum er hlaðið inn í ME UMA minni. Þetta sannprófunarferli hefur þegar verið rætt af okkur í einu af greinartileinkað Intel ME undirkerfinu.

Og ACPI EC vélbúnaðar, að jafnaði, er aðeins athugað með tilliti til heilleika. Hins vegar, vegna þess að þessi tvöfaldur er innifalinn í UEFI BIOS, er það næstum alltaf háð sömu verndaraðferðum og UEFI BIOS notar. Við skulum tala um þá.

Þessum aðferðum má skipta í tvo flokka.

Skrifvörn á UEFI BIOS svæði

1. Líkamleg vernd á innihaldi SPI-flassminnisins með skrifverndarstökkva;
2. Verndun á vörpun UEFI BIOS svæðisins í CPU vistfangarýminu með því að nota PRx skrár kubbasettsins;
3. Loka á tilraunir til að skrifa á UEFI BIOS svæðið með því að búa til og vinna úr samsvarandi SMI truflun með því að stilla BIOS_WE / BLE og SMM_BWP bitana í flísaskránum;
4. Fullkomnari útgáfa af þessari vernd er Intel BIOS Guard (PFAT).

Auk þessara aðferða geta söluaðilar þróað og innleitt eigin öryggisráðstafanir (til dæmis undirritað hylki með UEFI BIOS uppfærslum).

Það er mikilvægt að hafa í huga að á tilteknu kerfi (fer eftir söluaðila) er ekki víst að öllum ofangreindum verndaraðferðum sé beitt, þeim er ekki hægt að beita yfirleitt eða þeim er hugsanlega útfært á viðkvæman hátt. Þú getur lesið meira um þessar aðferðir og stöðuna við innleiðingu þeirra í Þessi grein. Fyrir áhugasama mælum við með að þú lesir alla greinaröðina um UEFI BIOS öryggi frá CodeRush.

UEFI BIOS Authentication Staðfesting

Þegar við tölum um trausta ræsitækni er það fyrsta sem kemur upp í hugann Secure Boot. Hins vegar, byggingarfræðilega séð, er það hannað til að auðkenna íhluti utan UEFI BIOS (rekla, hleðslutæki, osfrv.), En ekki vélbúnaðinn sjálfur.

Þess vegna innleiddi Intel í SoCs með Bay Trail örarkitektúrnum (2012) örugga ræsingu sem ekki er hægt að skipta um vélbúnað (Staðfest stígvél), sem hefur ekkert að gera með fyrrnefndri Secure Boot tækni. Síðar (2013) var þessi vélbúnaður endurbættur og, undir nafninu Intel Boot Guard, var gefinn út fyrir skjáborð með Haswell örarkitektúr.

Áður en við lýsum Intel Boot Guard skulum við skoða framkvæmdaumhverfið í Intel 64 arkitektúrnum, sem samanlagt eru rætur trausts fyrir þessa traustu ræsitækni.

Intel CPU

Cap gefur til kynna að örgjörvinn sé aðalframkvæmdarumhverfið í Intel 64 arkitektúrnum. Hvers vegna er það líka rót traustsins? Það kemur í ljós að það er eign eftirfarandi þátta sem gerir það svo:

• Microcode ROM er óstöðugt, óendurskrifanlegt minni til að geyma örkóða. Talið er að örkóði sé útfærsla á leiðbeiningakerfi örgjörva á einföldustu leiðbeiningunum. Gerist líka í örkóða pöddur. Þannig að í BIOS er hægt að finna tvöfalda skrá með örkóðauppfærslum (þeir eru settir ofan á við ræsingu, vegna þess að ekki er hægt að skrifa yfir ROM). Innihald þessara tvíþætta er dulkóðað, sem flækir mjög greiningu (þess vegna er tiltekið innihald örkóðans aðeins þekkt af þeim sem þróa hann), og undirritað til að stjórna heilleika og áreiðanleika;
• AES lykill til að afkóða innihald örkóðauppfærslu;
• kjötkássa af RSA almenningslykil sem staðfestir undirskrift örkóðauppfærslu;
• RSA public key hash, sem athugar undirskrift Intel-þróaðra ACM (Authenticated Code Module) kóðaeininga, sem örgjörvinn getur keyrt áður en BIOS byrjar (halló örkóði) eða meðan á notkun þess stendur, þegar einhver atvik eiga sér stað.

Intel ME

Þetta undirkerfi á blogginu okkar var helgað tvö Grein. Mundu að þetta keyranlega umhverfi er byggt á örstýringunni sem er innbyggður í flísasettið og er það falið og mest forréttinda í kerfinu.

Þrátt fyrir laumuspilið er Intel ME líka rót traustsins vegna þess að það hefur:

• ME ROM - óstöðugt, óendurskrifanlegt minni (engin uppfærsluaðferð fylgir), sem inniheldur upphafskóðann, sem og SHA256 kjötkássa RSA almenningslykilsins, sem athugar undirskrift Intel ME fastbúnaðarins;
• AES lykill til að geyma leynilegar upplýsingar;
• aðgangur að öryggi (FPF, Field Programmable Fuses) sem er samþætt í flísasettinu til varanlegrar geymslu á sumum upplýsingum, þar á meðal upplýsingum sem tilgreindar eru af söluaðila tölvukerfisins.

Intel Boot Guard 1.x

Lítill fyrirvari. Útgáfunúmer Intel Boot Guard tækni sem við notum í þessari grein eru handahófskennd og hafa ef til vill ekkert með númerið sem notað er í innri Intel skjölum að gera. Að auki voru upplýsingarnar um útfærslu þessarar tækni sem gefnar eru hér fengnar við bakverkfræði og geta innihaldið ónákvæmni miðað við forskriftina fyrir Intel Boot Guard, sem ólíklegt er að verði nokkurn tíma birt.

Svo, Intel Boot Guard (BG) er vélbúnaðarstudd UEFI BIOS auðkenningartækni. Miðað við litla lýsingu hennar í bókinni [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], virkar það sem traust ræsikeðja. Og fyrsti hlekkurinn í honum er ræsikóði (örkóði) inni í örgjörvanum, sem er ræstur af RESET atburðinum (ekki að rugla saman við RESET vektorinn í BIOS!). Örgjörvinn finnur kóðaeiningu (Intel BG startup ACM) þróuð og undirrituð af Intel á SPI flassminni, hleður því inn í skyndiminni, staðfestir það (það var þegar tekið fram hér að ofan að örgjörvinn er með opinber lykla kjötkássa sem staðfestir ACM undirskriftina ) og byrjar.

Þessi kóðaeining ber ábyrgð á að sannreyna lítinn upphafshluta UEFI BIOS - Initial Boot Block (IBB), sem aftur á móti inniheldur virkni til að sannreyna meginhluta UEFI BIOS. Þannig gerir Intel BG þér kleift að sannreyna áreiðanleika BIOS áður en þú ræsir stýrikerfið (sem hægt er að framkvæma undir eftirliti Secure Boot tækni).

Intel BG tæknin býður upp á tvær aðgerðastillingar (og önnur truflar hina, þ.e.a.s. hægt er að virkja báðar stillingarnar á kerfinu og báðar er hægt að gera óvirkar).

Mælt stígvél

Í Measured Boot (MB) ham, "mælir" hver ræsihluti (byrjar með CPU ræsi ROM) þann næsta með því að nota eiginleika Trusted Platform Module (TPM). Fyrir þá sem ekki vita, leyfðu mér að útskýra.

TPM hefur PCR (Platform Configuration Registers), sem skrá niðurstöður kjötkássaaðgerðarinnar samkvæmt formúlunni:

Þeir. núverandi PCR gildi fer eftir því fyrra og þessar skrár eru aðeins endurstilltar þegar kerfið er endurstillt.

Þannig, í MB-ham, á einhverjum tímapunkti, endurspegla PCR einstakt (innan getu kjötkássaaðgerðarinnar) auðkenni kóðans eða gagna sem voru „mældar“. Hægt er að nota PCR gildin við dulkóðun sumra gagna (TPM_Seal) aðgerða. Eftir það verður afkóðun þeirra (TPM_Unseal) aðeins möguleg ef PCR gildin hafa ekki breyst vegna hleðslu (þ.e.a.s. ekki einum „mældum“ íhlut hefur verið breytt).

Staðfest ræsi

Það skelfilegasta fyrir þá sem vilja breyta UEFI BIOS er Verified Boot (VB) stillingin, þar sem hver ræsihluti staðfestir dulritunarlega heilleika og áreiðanleika næsta. Og ef um sannprófunarvillu er að ræða, (eitt af eftirfarandi) á sér stað:

• lokun með tímamörkum frá 1 mínútu í 30 mínútur (svo að notandinn hafi tíma til að skilja hvers vegna tölvan hans ræsist ekki og, ef mögulegt er, myndi reyna að endurheimta BIOS);
• tafarlaus lokun (svo að notandinn hafi ekki tíma til að skilja og að auki gera);
• framhald vinnu með beinu andliti (tilfellið þegar það er enginn tími fyrir öryggi, vegna þess að það eru mikilvægari hlutir að gera).

Val á aðgerð fer eftir tilgreindri Intel BG uppsetningu (þ.e. á svokallaðri framfylgdarstefnu), sem er varanlega skráð af söluaðila tölvupallsins í sérhönnuðu geymslurými - flísaöryggi (FPF). Við munum fjalla nánar um þetta atriði síðar.

Til viðbótar við uppsetninguna býr seljandinn til tvo RSA 2048 lykla og býr til tvö gagnaskipulag (sýnt á myndinni):

1. Upplýsingaskrá rótarlykils seljanda (KEYM, OEM Root Key Manifest), sem setur SVN (Security Version Number) þessarar upplýsingaskrár, SHA256 kjötkássa almenningslykils næstu upplýsingaskrár, RSA almenningslykilsins (þ.e. rótarlykill seljanda) til að staðfesta undirskrift þessa upplýsingaskrá og undirskriftina sjálfa;
2. IBB Manifest (IBBM, Initial Boot Block Manifest), sem setur SVN þessarar upplýsingaskrár, SHA256 kjötkássa IBB, opinbera lykilinn til að staðfesta undirskrift þessarar upplýsingaskrár og undirskriftina sjálfa.

SHA256 kjötkássa OEM rótarlykilsins er varanlega skrifað á flísaöryggi (FPF), rétt eins og Intel BG stillingar. Ef Intel BG uppsetningin gerir ráð fyrir því að þessi tækni sé tekin inn, þá getur þetta kerfi héðan í frá aðeins eigandi einkahluta OEM rótarlykilsins uppfært BIOS (þ.e. geta endurreiknað þessar upplýsingar), þ. seljanda.

Þegar myndin er skoðuð vakna strax efasemdir um þörfina fyrir svo langa sannprófunarkeðju - þú hefðir getað notað eina upplýsingaskrá. Af hverju að flækja?

Reyndar veitir Intel þannig söluaðilanum tækifæri til að nota mismunandi IBB lykla fyrir mismunandi vörulínur og einn sem rót. Ef einkahluti IBB lykilsins (sem undirritar seinni upplýsingaskrána) lekur mun atvikið aðeins hafa áhrif á eina vörulínu og aðeins þar til seljandinn býr til nýtt par og gerir endurreiknaða upplýsingaskrána kleift í næstu BIOS uppfærslu.

En ef rótarlykillinn er í hættu (sem fyrsta skráningarskráin er undirrituð með), verður ekki hægt að skipta um hann, afturköllunarferlið er ekki veitt. kjötkássa hins opinbera hluta þessa lykils er forritað í FPF í eitt skipti fyrir öll.

Intel Boot Guard stillingar

Nú skulum við skoða nánar Intel BG stillingar og ferlið við sköpun hennar. Ef þú horfir á samsvarandi flipa í GUI Flash Image Tool frá Intel System Tool Kit (STK), munt þú taka eftir því að Intel BG uppsetningin inniheldur kjötkássa af opinbera hluta rótarlykils seljanda, nokkra óljósa gildi og svo framvegis. Intel BG prófíl.

Uppbygging þessa prófíls:

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

Almennt séð er Intel BG uppsetningin mjög sveigjanleg eining. Skoðum til dæmis Force_Boot_Guard_ACM fánann. Þegar það er hreinsað, ef BG startup ACM einingin á SPI flassinu finnst ekki, mun engin traust ræsing eiga sér stað. Það verður ekki treystandi.

Við skrifuðum þegar hér að ofan að hægt er að stilla framfylgdarstefnu fyrir VB ham þannig að ef staðfesting mistekst, aftur, muni ótraust niðurhal eiga sér stað.

Leyfðu söluaðilum svona hlutum...

GUI tólsins veitir eftirfarandi „tilbúna“ snið:

Nei
Ham
Lýsing

0
Nei_FVME
Intel BG tækni óvirk

1
VE
VB hamur virkur, lokun eftir tímamörk

2
VME
báðar stillingar eru virkar (VB og MB), lokun eftir tímamörkum

3
VM
báðar stillingar eru virkar án þess að slökkva á kerfinu

4
FVE
VB hamur virkur, tafarlaus lokun

5
FVME
báðar stillingar virkar, tafarlaus lokun

Eins og áður hefur verið nefnt verður Intel BG stillingar að vera skrifaðar í eitt skipti fyrir öll af kerfisframleiðandanum í flísaöryggi (FPF) - litla (samkvæmt óstaðfestum upplýsingum, aðeins 256 bæti) vélbúnaðarupplýsingageymsla inni í flísinni, sem hægt er að forrita utan af framleiðslustöðvum Intel (svo þess vegna Forritanlegt á vettvangi öryggi).

Það er frábært til að geyma stillingar vegna þess að:

• hefur einu sinni forritanlegt gagnageymslusvæði (bara þar sem Intel BG stillingin er skrifuð);
• aðeins Intel ME getur lesið og forritað það.

Svo, til að stilla uppsetninguna fyrir Intel BG tækni á tilteknu kerfi, gerir söluaðilinn eftirfarandi við framleiðslu:

1. Með því að nota Flash Image Tool (frá Intel STK), býr til vélbúnaðarmynd með tiltekinni Intel BG stillingu sem breytur innan Intel ME svæðinu (svokallaður tímabundinn spegill fyrir FPF);
2. Með því að nota Flash Programming Tool (frá Intel STK), skrifar þessa mynd í SPI flassminni kerfisins og lokar svokölluðu. framleiðsluhamur (í þessu tilfelli er samsvarandi skipun send til Intel ME).

Sem afleiðing af þessum aðgerðum mun Intel ME skuldbinda sig til FPF sem gefin gildi úr speglinum fyrir FPF á ME svæðinu, stilla heimildirnar í SPI flasslýsingum á gildin sem Intel mælir með (lýst í upphafi grein) og framkvæma endurstillingu kerfisins.

Intel Boot Guard útfærslugreining

Til að greina innleiðingu þessarar tækni á tilteknu dæmi skoðuðum við eftirfarandi kerfi fyrir ummerki um Intel BG tækni:

System
Athugið

Gígabæta GA-H170-D3H
Skylake, það er stuðningur

Gígabæti GA-Q170-D3H
Skylake, það er stuðningur

Gígabæti GA-B150-HD3
Skylake, það er stuðningur

MSI H170A Gaming Pro
Skylake, enginn stuðningur

Lenovo ThinkPad 460
Skylake, stuðningur í boði, tækni virkjuð

Lenovo Yoga 2 Pro
Haswell, enginn stuðningur

Lenovo U330p
Haswell, enginn stuðningur

„Stuðningur“ þýðir tilvist Intel BG ræsingu ACM einingarinnar, upplýsingaskránna sem nefnd eru hér að ofan og samsvarandi kóða í BIOS, þ.e. útfærslur til greiningar.

Sem dæmi skulum við taka þann sem hlaðið er niður af skrifstofunni. mynd söluaðila vefsvæðis af SPI flassminni fyrir Gigabyte GA-H170-D3H (útgáfa F4).

Intel CPU ræsi ROM

Fyrst af öllu, við skulum tala um aðgerðir örgjörvans ef Intel BG tækni er virkjuð.

Það var ekki hægt að finna sýnishorn af afkóðaða örkóðanum, því hvernig aðgerðirnar sem lýst er hér að neðan eru útfærðar (í örkóða eða í vélbúnaði) er opin spurning. Engu að síður er staðreyndin að nútíma Intel örgjörvar „geta“ framkvæmt þessar aðgerðir.

Eftir að hafa farið úr RESET ástandinu finnur örgjörvinn (þar sem innihald flassminnsins er þegar kortlagt) FIT (Firmware Interface Table). Auðvelt er að finna það, bendilinn á það er skrifaður á heimilisfangið FFFF FFC0h.

Í þessu dæmi inniheldur þetta heimilisfang gildið FFD6 9500h. Með því að snúa sér að þessu heimilisfangi sér örgjörvinn FIT töfluna, en innihald hennar er skipt í færslur. Fyrsta færslan er fyrirsögn eftirfarandi skipulags:

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

Af einhverjum óþekktum ástæðum er gátsumman ekki alltaf reiknuð í þessum töflum (reiturinn er skilinn eftir núll).

Þær færslur sem eftir eru benda til ýmissa binaries sem þarf að þátta / keyra áður en BIOS er keyrt, þ.e. áður en skipt er yfir í eldri RESET vektor (FFFF FFF0h). Uppbygging hverrar slíkrar færslu er sem hér segir:

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

Reiturinn EntryType gefur til kynna hvers konar blokk þessi færsla bendir á. Við þekkjum nokkrar tegundir:

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ú er augljóst að ein af færslunum bendir á staðsetningu Intel BG ræsingar ACM tvöfaldans. Hausuppbygging þessa tvöfalda er dæmigerð fyrir kóðaeiningar þróaðar af Intel (ACM, örkóðauppfærslur, Intel ME kóðahlutar, ...).

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

Örgjörvinn hleður þessu tvöfalda inn í skyndiminni, sannreynir og ræsir.

Intel BG gangsetning ACM

Sem afleiðing af greiningu á starfi þessa ACM varð ljóst að það gerir eftirfarandi:

• fær frá Intel ME Intel BG stillingarnar sem eru skrifaðar á öryggi kubbasettsins (FPFs);
• finnur KEYM og IBBM birtingarmyndir, sannreynir þær.

Til að finna þessar birtingarmyndir notar ACM einnig FIT töfluna, sem hefur tvenns konar færslur til að benda á þessar mannvirki (sjá FIT_ENTRY_TYPES hér að ofan).

Skoðum stefnuskrárnar nánar. Í uppbyggingu fyrstu upplýsingaskránnar sjáum við nokkra óljósa fasta, kjötkássa af opinbera lyklinum úr annarri upplýsingunni og opinberan OEM rótarlykil sem er undirritaður sem hreiður uppbygging:

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

Til að sannreyna opinbera lykil OEM rótarlykilsins, minnumst við þess að SHA256 kjötkássa frá öryggi er notuð, sem á þessari stundu hefur þegar borist frá Intel ME.

Við skulum halda áfram að annarri stefnuskránni. Það samanstendur af þremur mannvirkjum:

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

Sá fyrsti inniheldur nokkra fasta:

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

Annað inniheldur SHA256 kjötkássa IBB og fjölda lýsinga sem lýsa innihaldi IBB (þ.e. úr hverju kjötkássa er reiknuð):

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 lýsingarnar fylgja þessari uppbyggingu, hver á eftir öðrum. Efni þeirra er með eftirfarandi sniði:

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

Það er einfalt: hver lýsing inniheldur heimilisfang/stærð IBB-klumps. Þannig er samtenging kubbanna sem þessir lýsingar benda á (í röð lýsinganna sjálfra) IBB. Og að jafnaði er IBB sambland af öllum einingum í SEC og PEI áfanganum.

Önnur upplýsingaskrá endar með uppbyggingu sem inniheldur IBB almenningslykil (staðfest með SHA256 kjötkássa frá fyrstu upplýsingaskrá) og undirskrift þessarar upplýsingaskrá:

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

Svo, jafnvel áður en UEFI BIOS framkvæmdin hefst, mun örgjörvinn ræsa ACM, sem mun sannreyna áreiðanleika innihalds hluta með SEC og PEI áfangakóðanum. Næst fer örgjörvinn út úr ACM, hreyfist meðfram RESET vektornum og byrjar að keyra BIOS.

PEI staðfesta skiptingin verður að innihalda einingu sem mun athuga restina af BIOS (DXE kóða). Þessi eining er þegar í þróun af IBV (Independent BIOS Vendor) eða kerfissöluaðilanum sjálfum. Vegna þess að Aðeins Lenovo og Gigabyte kerfi reyndust vera okkur til ráðstöfunar og með Intel BG stuðning, skulum við íhuga kóðann sem dreginn er út úr þessum kerfum.

UEFI BIOS mát LenovoVerifiedBootPei

Í tilviki Lenovo reyndist það vera LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D} einingin, þróuð af Lenovo.

Hlutverk þess er að fletta upp (með GUID) kjötkássatöflu fyrir DXE og staðfesta 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 mát BootGuardPei

Í tilviki Gigabyte reyndist það vera BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066} einingin, þróuð af AMI, og því til staðar í hvaða AMI BIOS sem er með Intel BG stuðningi.

Reikniritið fyrir notkun þess er nokkuð frábrugðið, en það styttist í það sama:

int bootMode = EFI_PEI_SERVICES->GetBootMode();

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

Hash-taflan {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} sem hún flettir upp hefur eftirfarandi snið:

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

Við skulum tala stuttlega um aðra útfærslu á Intel Boot Guard, sem fannst í nýrra kerfi byggt á Intel SoC með Apollo Lake örarkitektúr - ASRock J4205-IT.

Þó að þessi útgáfa verði aðeins notuð í SoCs (ný kerfi með Kaby Lake örgjörva örarkitektúr halda áfram að nota Intel Boot Guard 1.x), þá er það mikill áhugi á að kanna nýjan arkitektúrvalkost fyrir palla byggða á Intel SoCs, sem hefur verið áþreifanlegur breytingar, til dæmis:

• BIOS og Intel ME svæði (eða öllu heldur Intel TXE, samkvæmt Intel SoC hugtökum) eru nú eitt IFWI svæði;
• þó að Intel BG hafi verið virkt á pallinum, fundust mannvirki eins og FIT, KEYM, IBBM ekki í flassminni;
• auk TXE og ISH kjarna (x86), var þriðji kjarna (aftur ARC, við the vegur) bætt við kubbasettið - PMC (Power Management Controller), sem tengist því að tryggja virkni raforkuundirkerfisins og eftirlit með afköstum.

Innihald nýja IFWI svæðisins er sett af eftirfarandi einingum:

Offset
nafn
Lýsing

0000 2000 klst
SMIP
einhver vettvangsstilling, undirrituð af seljanda

0000 6000 klst
RBEP
Intel TXE vélbúnaðarkóðahluti, x86, undirritaður af Intel

0001 0000 klst
PMCP
vélbúnaðarkóðahluti Intel PMC, ARC, undirritaður af Intel

0002 0000 klst
FTPR
Intel TXE vélbúnaðarkóðahluti, x86, undirritaður af Intel

0007B000h
UCOD
CPU örkóðauppfærslur undirritaðar af Intel

0008 0000 klst
IBBP
UEFI BIOS, SEC/PEI fasar, x86, seljandi undirritaður

0021 8000 klst
ISHC
kóðahluta Intel ISH fastbúnaðar, x86, undirritaður af seljanda

0025 8000 klst
NFTP
Intel TXE vélbúnaðarkóðahluti, x86, undirritaður af Intel

0036 1000 klst
IUNP
er óþekkt

0038 1000 klst
OBBP
UEFI BIOS, DXE phase, x86, óundirritað

Við greiningu á TXE fastbúnaðinum kom í ljós að eftir RESET heldur TXE örgjörvanum í þessu ástandi þar til hann undirbýr grunninnhald vistfangarýmisins fyrir CPU (FIT, ACM, RESET vektor ...). Þar að auki setur TXE þessi gögn í SRAM sitt, eftir það veitir það örgjörvanum tímabundið aðgang þar og „losar“ þau úr RESET.

Á varðbergi gagnvart rootkits

Jæja, nú skulum við halda áfram í "heitt". Við komumst einu sinni að því að í mörgum kerfum hafa SPI flasslýsingar heimildir til að fá aðgang að svæðum í SPI flassminni þannig að allir notendur þessa minnis geta bæði skrifað og lesið hvaða svæði sem er. Þeir. glætan.

Eftir að hafa athugað með MEinfo tólinu (frá Intel STK), sáum við að framleiðsluhamurinn á þessum kerfum var ekki lokaður, þess vegna voru flísaöryggin (FPF) skilin eftir í óákveðnu ástandi. Já, Intel BG er hvorki virkt né óvirkt í slíkum tilvikum.

Við erum að tala um eftirfarandi kerfi (varðandi Intel BG og það sem verður lýst síðar í greininni, við munum tala um kerfi með Haswell örgjörva örarkitektúr og hærri):

• allar Gigabyte vörur;
• allar MSI vörur;
• 21 Lenovo fartölvu gerðir og 4 Lenovo netþjóna gerðir.

Auðvitað tilkynntum við þessum söluaðilum um fundinn, sem og Intel.

Fullnægjandi viðbrögð fylgdu aðeins frá Lenovosem viðurkenndi vandamálið og gaf út plástur.

Gigabyte Svo virðist sem þeir hafi samþykkt upplýsingar um varnarleysið en ekki tjáð sig á neinn hátt.

Samskipti við MSI algjörlega tafðist að beiðni okkar um að senda opinbera PGP lykilinn okkar (til að senda þeim dulkóðaða öryggisráðgjöf). Þeir sögðu að þeir "eru vélbúnaðarframleiðandi og framleiði ekki PGP lykla."

En meira að segja. Þar sem öryggin eru skilin eftir í óskilgreindu ástandi getur notandinn (eða árásarmaðurinn) forritað þau sjálfur (það erfiðast er finna Intel STK). Þetta krefst eftirfarandi skrefa.

1. Ræstu í Windows OS (almennt séð er einnig hægt að gera skrefin sem lýst er hér að neðan undir Linux, ef þú þróar hliðstæðu Intel STK fyrir viðkomandi stýrikerfi). Notaðu MEinfo tólið til að ganga úr skugga um að öryggin á þessu kerfi séu ekki forrituð.

2. Lestu innihald flash-minni með því að nota Flash-forritunartólið.

3. Opnaðu lesmyndina með því að nota hvaða UEFI BIOS klippitæki sem er, gerðu nauðsynlegar breytingar (útfærðu til dæmis rótsett), búðu til / breyttu núverandi KEYM og IBBM uppbyggingu á ME svæðinu.

Opinberi hluti RSA-lykilsins er auðkenndur á myndinni, kjötkássa þess verður forrituð í öryggi flísanna ásamt restinni af Intel BG uppsetningunni.

4. Notaðu Flash Image Tool til að búa til nýja fastbúnaðarmynd (með því að stilla Intel BG stillingar).

5. Skrifaðu nýja mynd til að blikka með því að nota Flash-forritunartólið, staðfestu með MEinfo að ME-svæðið inniheldur nú Intel BG stillinguna.

6. Notaðu Flash-forritunartólið til að loka framleiðsluhamnum.

7. Kerfið mun endurræsa, eftir það, með því að nota MEinfo, geturðu staðfest að FPF eru nú forrituð.

Þessar aðgerðir að eilífu virkjaðu Intel BG á þessu kerfi. Það verður ómögulegt að afturkalla aðgerðina, sem þýðir:

• aðeins eigandi einkahluta rótarlykilsins (þ.e. sá sem virkjaði Intel BG) mun geta uppfært UEFI BIOS á þessu kerfi;
• ef þú skilar upprunalega fastbúnaðinum í þetta kerfi, til dæmis með því að nota forritara, mun hann ekki einu sinni kveikja á honum (afleiðing framfylgdarstefnu ef staðfestingarvilla kemur upp);
• til að losna við svona UEFI BIOS þarftu að skipta út kubbasettinu fyrir forritaða FPF fyrir "hreint" (þ.e.a.s. endurlóða kubbasettið ef þú hefur aðgang að innrauðri lóðastöð á verði bíls, eða bara skipta um móðurborðið ).

Til að skilja hvað slíkt rootkit getur gert þarftu að meta hvað gerir það mögulegt að keyra kóðann þinn í UEFI BIOS umhverfi. Segðu, í mest forréttinda ham örgjörvans - SMM. Slík rootkit getur haft eftirfarandi eiginleika:

• vera framkvæmt samhliða stýrikerfinu (þú getur stillt vinnslu með því að búa til SMI truflun, sem verður ræst af tímamæli);
• hafa alla kosti þess að vera í SMM ham (fullur aðgangur að innihaldi vinnsluminni og vélbúnaðar, leynd frá stýrikerfinu);
• Rootkit kóðann er hægt að dulkóða og afkóða þegar hann er ræstur í SMM ham. Öll gögn sem eru aðeins tiltæk í SMM ham er hægt að nota sem dulkóðunarlykil. Til dæmis, kjötkássa úr setti af vistföngum í SMRAM. Til að fá þennan lykil þarftu að klifra upp í SMM. Og þetta er hægt að gera á tvo vegu. Finndu RCE í SMM kóðanum og nýttu hann, eða bættu þinni eigin SMM einingu við BIOS, sem er ómögulegt, þar sem við virkuðum Boot Guard.

Þannig gerir þessi varnarleysi árásarmanni kleift að:

• búa til falið, ófjarlægt rootkit af óþekktum tilgangi í kerfinu;
• keyrðu kóðann þinn á einum af kubbakjarnanum inni í Intel SoC, nefnilega á Intel ISH (skoðaðu myndina betur).

Þrátt fyrir að hæfileikar Intel ISH undirkerfisins hafi ekki enn verið kannaðar, virðist það vera áhugaverður árásarvektor gegn Intel ME.

Niðurstöður

1. Rannsóknin gaf tæknilega lýsingu á því hvernig Intel Boot Guard tækni virkar. Að frádregnum nokkrum leyndarmálum í öryggi Intel í gegnum myrkulíkanið.
2. Árásaratburðarás er sett fram sem gerir kleift að búa til ófjarlægjanlegt rootkit í kerfinu.
3. Við höfum séð að nútíma Intel örgjörvar geta keyrt mikið af sérkóða jafnvel áður en BIOS byrjar.
4. Pallar með Intel 64 arkitektúr verða æ minna hentugir til að keyra ókeypis hugbúnað: sannprófun á vélbúnaði, vaxandi fjölda sértækni og undirkerfa (þrír kjarna í SoC flísinni: x86 ME, x86 ISH og ARC PMC).

Mótvægisaðgerðir

Söluaðilar sem viljandi skilja framleiðsluhaminn eftir opna ættu örugglega að loka honum. Enn sem komið er eru þeir aðeins að loka augunum og nýju Kaby Lake kerfin sýna þetta.

Notendur geta slökkt á Intel BG á kerfum sínum (sem verða fyrir áhrifum af varnarleysinu sem lýst er) með því að keyra Flash forritunartólið með -closemnf valkostinum. Í fyrsta lagi ættir þú að ganga úr skugga um (með MEinfo) að uppsetning Intel BG á ME svæðinu gerir ráð fyrir því að nákvæmlega slökkva á þessari tækni eftir forritun í FPF.

Heimild: www.habr.com