🥇Schrödinger fidinda elŝuto. Intel Boot Guard

Ni proponas denove malsupreniri al la malalta nivelo kaj paroli pri la sekureco de firmware x86-kongruaj komputilaj platformoj. Ĉi-foje, la ĉefa ingredienco de la esplorado estas Intel Boot Guard (ne konfuzu kun Intel BIOS Guard!) - aparataro subtenata de BIOS fidinda bototeknologio kiun komputilsistemvendisto povas konstante ebligi aŭ malŝalti en la produktadstadio. Nu, ni jam konas la esploran recepton: maldike tranĉu la efektivigon de ĉi tiu teknologio per inversa inĝenierado, priskribu ĝian arkitekturon, plenigu ĝin per nedokumentitaj detaloj, spicu ĝin per atakvektoroj por gustumi kaj miksi ĝin. Ni aldonu fajron kun rakonto pri kiel klonita cimo en la produktado de pluraj vendistoj dum jaroj permesas al potenciala atakanto uzi ĉi tiun teknologion por krei kaŝitan rootkit kiu ne povas esti forigita (eĉ de programisto) en la sistemo.

Cetere, la artikolo baziĝas sur la raportoj "On Guard for Rootkits: Intel BootGuard" de la konferenco ZeroNights 2016 kaj 29-a kunveno DefCon Rusio (ambaŭ prezentoj tie).

Firmvaro por komputila platformo kun Intel 64 arkitekturo

Komence, ni respondu la demandon: kio estas la firmvaro de moderna komputila platformo kun la arkitekturo Intel 64? Kompreneble, UEFI BIOS. Sed ĉi tiu respondo ne estos preciza. Ni rigardu la figuron, kiu montras la labortablan (tekkomputilon) version de ĉi tiu arkitekturo.

La bazo estas la ligo:

Procesoro (CPU, Central Processing Unit), kiu, krom la ĉefaj kernoj, havas enkonstruitan grafikan kernon (ne en ĉiuj modeloj) kaj memorregilon (IMC, Integrated Memory Controller);
Chipset (PCH, Platform Controller Hub), enhavanta diversajn regilojn por interagado kun ekstercentraj aparatoj kaj administrado de subsistemoj. Inter ili estas la konata Intel Management Engine (ME), kiu ankaŭ havas firmware (Intel ME firmware).

Tekkomputiloj, krom ĉi-supraj, postulas integran regilon (ACPI EC, Advanced Control and Power Interface Embedded Controller), kiu respondecas pri la funkciado de la potenca subsistemo, tuŝo, klavaro, Fn-klavoj (ekrana brilo, sona volumo, klavaro). kontraŭlumo, ktp.) kaj pli. Kaj li ankaŭ havas sian propran firmware.

Do, la kombinaĵo de ĉi-supra firmvaro estas la firmvaro de la komputila platformo (sistema firmvaro), kiu estas konservita en komuna SPI-flash-memoro. Por ke uzantoj de ĉi tiu memoro ne konfuziĝas, kie iu kuŝas, la enhavo de ĉi tiu memoro estas dividita en la sekvajn regionojn (kiel montrite en la figuro):

UEFI BIOS;
ACPI EC-firmvaro (aparta regiono aperis kun la Skylake-procesora mikroarkitekturo (2015), sed en la sovaĝa ni ankoraŭ ne vidis ekzemplojn de ĝia uzo, do la enigita regila firmvaro ankoraŭ estas parto de la UEFI BIOS);
Firvaro Intel ME;
agordo (MAC-adreso, ktp.) de la enkonstruita GbE (Gigabit Ethernet) retadaptilo;
fulmpriskribiloj - la ĉefa regiono de fulmmemoro, kiu enhavas montrilojn al aliaj regionoj, same kiel permesojn aliri ilin.

Diferencigo de aliro al regionoj (laŭ la specifitaj permesoj) estas pritraktata de la SPI-busmastro - la SPI-regilo enkonstruita en la pecetaro, per kiu ĉi tiu memoro estas alirita. Se la permesoj estas agordita al la valoroj rekomenditaj (pro sekurecaj kialoj) de Intel, tiam ĉiu uzanto de la SPI-fulmo havas plenan aliron (legi/skribi) nur al sia regiono. La ceteraj estas aŭ nurlegeblaj aŭ nealireblaj. Konata fakto: en multaj sistemoj, la CPU havas plenan aliron al la UEFI BIOS kaj GbE, legan aliron nur al fulmaj priskribiloj, kaj tute ne aliron al la Intel ME-regiono. Kial multaj kaj ne ĉiuj? Kio estas rekomendita estas nedeviga. Ni rakontos al vi pli poste en la artikolo.

Mekanismoj por protekti la firmvaro de komputila platformo kontraŭ modifo

Evidente, la firmvaro de komputila platformo devus esti protektita kontraŭ ebla kompromiso, kio permesus al ebla atakanto akiri piedtenon en ĝi (travivi OS ĝisdatigojn / reinstalojn), ekzekuti sian kodon en la plej privilegiitaj reĝimoj, ktp. Kaj limigi aliron al SPI-memorregionoj, kompreneble, ne sufiĉas. Tial diversaj mekanismoj specifaj por ĉiu ekzekutmedio estas uzataj por protekti la firmvaro kontraŭ modifoj.

Do, la Intel ME-firmvaro estas subskribita por integreco kaj aŭtentikeckontrolo, kaj estas kontrolita de la ME-regilo ĉiufoje kiam ĝi estas ŝarĝita en la ME UMA-memoron. Ĉi tiu kontrola procezo jam estis diskutita de ni en unu el la artikolojdediĉita al la subsistemo Intel ME.

Kaj ACPI EC-firmvaro, kiel regulo, estas kontrolita nur por integreco. Tamen, pro la fakto, ke ĉi tiu binaro estas inkluzivita en la UEFI BIOS, ĝi preskaŭ ĉiam estas submetita al la samaj protektaj mekanismoj, kiujn la UEFI BIOS uzas. Ni parolu pri ili.

Ĉi tiuj mekanismoj povas esti dividitaj en du kategoriojn.

Skribu protekton al UEFI BIOS-regiono

Fizika protekto de la enhavo de la fulmmemoro SPI kun skribprotekta saltilo;
Protekto de la projekcio de la UEFI BIOS-regiono en la CPU-adresspaco uzante la PRx-registrojn de la pecetaro;
Blokado de provoj skribi al la UEFI BIOS-regiono per generado kaj prilaborado de la responda SMI-interrompo metante la BIOS_WE / BLE kaj SMM_BWP-bitojn en la pecetaj registroj;
Pli altnivela versio de ĉi tiu protekto estas Intel BIOS Guard (PFAT).

Aldone al ĉi tiuj mekanismoj, vendistoj povas evoluigi kaj efektivigi siajn proprajn sekureciniciatojn (ekzemple, subskribante kapsulojn kun UEFI-BIOS-ĝisdatigoj).

Gravas noti, ke en specifa sistemo (depende de la vendisto), ne ĉiuj ĉi-supraj protektaj mekanismoj povas esti aplikataj, ili eble tute ne estas aplikataj, aŭ ili povas esti efektivigitaj en vundebla maniero. Vi povas legi pli pri ĉi tiuj mekanismoj kaj la situacio kun ilia efektivigo en ĉi tiu artikolo. Por tiuj, kiuj interesiĝas, ni rekomendas, ke vi legu la tutan serion de artikoloj pri UEFI BIOS-sekureco de CodeRush.

UEFI-BIOS-Konfirmo-Konfirmo

Kiam ni parolas pri fidindaj ekŝargaj teknologioj, la unua afero, kiu venas al la menso, estas Secure Boot. Tamen, arkitekture, ĝi estas desegnita por aŭtentikigi komponentojn eksteraj al la UEFI BIOS (ŝoforoj, ŝargiloj, ktp.), kaj ne la firmvaro mem.

Tial, Intel en SoCs kun la Bay Trail mikroarkitekturo (2012) efektivigis aparataron ne-ŝanĝeblan Secure Boot (Verified Boot), kiu havas nenion komunan kun la menciita Secure Boot-teknologio. Poste (2013), tiu mekanismo estis plibonigita kaj, sub la nomo Intel Boot Guard, estis liberigita por skribotabloj kun la Haswell-mikroarkitekturo.

Antaŭ ol priskribi Intel Boot Guard, ni rigardu rultempojn en la arkitekturo Intel 64, kiuj, en kombinaĵo, estas la radikoj de fido por ĉi tiu fidinda bototeknologio.

Intel-CPU

Cap sugestas, ke la procesoro estas la ĉefa ekzekuta medio en la arkitekturo Intel 64. Kial ĝi ankaŭ estas la radiko de fido? Rezultas, ke estas la posedo de la sekvaj elementoj, kio faras ĝin tiel:

Microcode ROM estas nevolatila, ne-reskribebla memoro por stoki mikrokodon. Oni kredas, ke mikrokodo estas la efektivigo de la procesora instrukciosistemo sur la plej simplaj instrukcioj. Okazas ankaŭ en mikrokodo cimoj. Do en la BIOS vi povas trovi binarojn kun mikrokodaj ĝisdatigoj (ili estas supermetitaj je lanĉo, ĉar la ROM ne povas esti anstataŭita). La enhavo de ĉi tiuj binaroj estas ĉifrita, kio ege malfaciligas la analizon (tial la specifa enhavo de la mikrokodo estas konata nur de tiuj, kiuj disvolvas ĝin), kaj subskribita por kontroli la integrecon kaj aŭtentikecon;
AES-ŝlosilo por malĉifri la enhavon de mikrokodaj ĝisdatigoj;
hash de la publika ŝlosilo RSA kiu kontrolas la subskribon de mikrokodaj ĝisdatigoj;
RSA publika ŝlosilo hash, kiu kontrolas la subskribon de Intel-evoluinta ACM (Authenticated Code Module) kodmoduloj, kiujn la CPU povas funkcii antaŭ ol la BIOS komenciĝas (saluton mikrokodo) aŭ dum ĝia funkciado, kiam kelkaj okazaĵoj okazas.

Intel ME

Ĉi tiu subsistemo en nia blogo estis dediĉita al du artikoloj. Memoru, ke ĉi tiu plenumebla medio baziĝas sur la mikroregilo enkonstruita en la pecetaro kaj estas la plej kaŝita kaj privilegiita en la sistemo.

Malgraŭ la kaŝemo, Intel ME ankaŭ estas la radiko de fido, ĉar ĝi havas:

ME ROM - ne-volatila, ne-reskribebla memoro (neniu ĝisdatiga metodo provizita), enhavanta la startkodon, same kiel la SHA256 hash de la RSA publika ŝlosilo, kiu kontrolas la subskribon de la Intel ME-firmvaro;
AES-ŝlosilo por stoki sekretajn informojn;
aliro al aro de fuzeoj (FPFoj, Field Programable Fuses) integritaj en la pecetaron por permanenta stokado de iuj informoj, inkluzive de informoj precizigitaj fare de la komputilsistemvendisto.

Intel Boot Guard 1.x

Malgranda malgarantio. La versinumeroj de Intel Boot Guard-teknologio, kiujn ni uzas en ĉi tiu artikolo, estas arbitraj kaj eble havas nenion komunan kun la numerado uzata en interna Intel-dokumentado. Krome, la informoj pri la efektivigo de ĉi tiu teknologio donita ĉi tie estis akiritaj dum inversa inĝenierado, kaj povas enhavi erarojn kompare kun la specifo por Intel Boot Guard, kiu verŝajne neniam estos publikigita.

Do, Intel Boot Guard (BG) estas aparataro subtenata UEFI BIOS-aŭtentikigteknologio. Juĝante laŭ ĝia malgranda priskribo en la libro [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], ĝi funkcias kiel fidinda botoĉeno. Kaj la unua ligilo en ĝi estas la startkodo (mikrokodo) ene de la CPU, kiu estas ekigita de la evento RESET (ne konfuzu kun la RESET-vektoro en la BIOS!). La CPU trovas kodmodulon (Intel BG startup ACM) evoluigitan kaj subskribitan de Intel sur la SPI-flash-memoro, ŝarĝas ĝin en sian kaŝmemoron, kontrolas ĝin (estas jam supre notite, ke la CPU havas publikan ŝlosilon hash kiu kontrolas la ACM subskribon). ) kaj komenciĝas.

Ĉi tiu kodmodulo respondecas pri kontrolado de malgranda komenca parto de la UEFI BIOS - Komenca Boot Block (IBB), kiu, siavice, enhavas la funkciojn por kontroli la ĉefan parton de la UEFI BIOS. Tiel, Intel BG permesas vin kontroli la aŭtentikecon de la BIOS antaŭ ol ekfunkciigi la OS (kiu povas esti farita sub la superrigardo de Secure Boot-teknologio).

Intel BG-teknologio disponigas du reĝimojn de operacio (kaj unu ne malhelpas la alian, t.e. ambaŭ reĝimoj povas esti ebligitaj sur la sistemo, kaj ambaŭ povas esti malŝaltitaj).

Mezurita Boto

En Measured Boot (MB) reĝimo, ĉiu lanĉkomponento (komencante kun la CPU-ŝarga ROM) "mezuras" la venontan uzante la kapablojn de la Trusted Platform Module (TPM). Por tiuj, kiuj ne scias, lasu min klarigi.

TPM havas PCR-ojn (Platform Configuration Registers), kiuj registras la rezulton de la haĉa operacio laŭ la formulo:

Tiuj. la nuna PCR-valoro dependas de la antaŭa, kaj ĉi tiuj registroj estas rekomencigitaj nur kiam la sistemo estas RESET.

Tiel, en MB-reĝimo, ĉe iu punkto en tempo, PCRoj reflektas unikan (ene de la kapabloj de la hashoperacio) identigilon de la kodo aŭ datenoj kiuj estis "mezuritaj". La PCR-valoroj povas esti uzataj en la ĉifrado de iuj datumoj (TPM_Seal) operacio. Post tio, ilia deĉifrado (TPM_Unseal) eblos nur se la PCR-valoroj ne ŝanĝiĝis kiel rezulto de ŝarĝo (t.e., eĉ ne unu "mezurita" komponanto estis modifita).

Konfirmita Boot

La plej timiga afero por tiuj, kiuj ŝatas modifi la UEFI-BIOS-on, estas la Verified Boot (VB) reĝimo, en kiu ĉiu ekŝarga komponanto kriptografie kontrolas la integrecon kaj aŭtentikecon de la sekva. Kaj en kazo de kontrola eraro, (unu el la sekvaj) okazas:

malŝalto de tempodaŭro de 1 minuto ĝis 30 minutoj (por ke la uzanto havu tempon kompreni kial lia komputilo ne ekfunkciigas, kaj, se eble, provus restarigi la BIOS);
tuja haltigo (por ke la uzanto ne havu tempon por kompreni kaj, krome, fari);
daŭrigo de laboro kun rekta vizaĝo (la kazo kiam ne estas tempo por sekureco, ĉar estas pli gravaj aferoj por fari).

La elekto de ago dependas de la specifita Intel BG-agordo (nome, de la tiel nomata plenuma politiko), kiu estas konstante registrita de la komputilplatformo-vendisto en speciale desegnita stokado - chipset fuses (FPFs). Ni priparolos ĉi tiun punkton pli detale poste.

Aldone al la agordo, la vendisto generas du RSA 2048-ŝlosilojn kaj kreas du datumstrukturojn (montritajn en la figuro):

La manifesto de la radikŝlosilo de la vendisto (KEYM, OEM Root Key Manifest), kiu metas la SVN (Security Version Number) de ĉi tiu manifesto, la SHA256 hash de la publika ŝlosilo de la sekva manifesto, la RSA publika ŝlosilo (t.e. la publika parto de la manifesto). vendisto radikŝlosilo) por kontroli la subskribon de ĉi tiu manifesto kaj la subskribon mem;
La IBB-Manifesto (IBBM, Initial Boot Block Manifest), kiu metas la SVN de ĉi tiu manifesto, la SHA256-haŝiŝon de la IBB, la publikan ŝlosilon por kontroli la subskribon de ĉi tiu manifesto, kaj la subskribon mem.

La SHA256 hash de la OEM Root Key estas konstante skribita al chipset fuzeoj (FPFs), same kiel la Intel BG-agordo. Se la agordo de Intel BG provizas la inkludon de ĉi tiu teknologio, tiam de ĉi tiu momento ĉi tiu sistemo nur la posedanto de la privata parto de la OEM Root Key povas ĝisdatigi la BIOS (t.e. povi rekalkuli ĉi tiujn manifestojn), t.e. vendisto.

Kiam vi rigardas la bildon, tuj ekestas duboj pri la bezono de tia longa kontrola ĉeno - vi povus esti uzinta unu manifeston. Kial kompliki?

Fakte, Intel tiel donas al la vendisto la ŝancon uzi malsamajn IBB-ŝlosilojn por malsamaj produktaj linioj kaj unu kiel la radiko. Se la privata parto de la IBB-ŝlosilo (kiu subskribas la duan manifeston) estas likita, la okazaĵo influos nur unu produktserio kaj nur ĝis la vendisto generas novan paron kaj ebligas la rekalkulitajn manifestojn en la venonta BIOS-ĝisdatigo.

Sed se la radika ŝlosilo estas kompromitita (per kiu la unua manifesto estas subskribita), ne eblos anstataŭigi ĝin, la revoka proceduro ne estas provizita. la haŝo de la publika parto de ĉi tiu ŝlosilo estas programita en FPF-ojn unufoje por ĉiam.

Agordo de Intel Boot Guard

Nun ni rigardu pli detale la agordon de Intel BG kaj la procezon de ĝia kreado. Se vi rigardas la respondan langeton en la GUI de la Flash Image Tool de la Intel System Tool Kit (STK), vi rimarkos, ke la agordo de Intel BG inkluzivas hash de la publika parto de la radika ŝlosilo de la vendisto, kelkajn obskurajn. valoroj, ktp. Intel BG-profilo.

La strukturo de ĉi tiu profilo:

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

Ĝenerale, la agordo de Intel BG estas tre fleksebla ento. Konsideru, ekzemple, la flagon Force_Boot_Guard_ACM. Kiam ĝi estas malbarita, se la BG-komenca ACM-modulo sur la SPI-fulmo ne estas trovita, neniu fidinda lanĉo okazos. Ĝi estos nefidinda.

Ni jam skribis supre, ke la plenuma politiko por la VB-reĝimo povas esti agordita tiel ke se la konfirmo malsukcesas, denove okazos nefidinda elŝuto.

Lasu tiajn aferojn al la vendistoj...

La GUI de la ilo disponigas la sekvajn "pretajn" profilojn:

Salono
Modo
Priskribo

0
Ne_FVME
Teknologio Intel BG malŝaltita

1
VE
VB-reĝimo ebligita, malŝalto per tempodaŭro

2
VME
ambaŭ reĝimoj estas ebligitaj (VB kaj MB), ĉesigo per tempotempo

3
VM
ambaŭ reĝimoj estas ebligitaj, sen malŝalti la sistemon

4
FVE
VB-reĝimo ebligita, tuja ĉesigo

5
FVME
ambaŭ reĝimoj ebligitaj, tuja ĉesigo

Kiel jam menciite, la agordo de Intel BG devas esti skribita unufoje por ĉiam fare de la sistemvendisto en chipset-fuzeojn (FPF) - malgrandan (laŭ nekontrolitaj informoj, nur 256 bajtoj) hardvarinformkonservadon ene de la pecetaro, kiu povas esti programita ekstere. de la produktadinstalaĵoj de Intel (do jen kial Kampo Programebla fuzeoj).

Ĝi estas bonega por stoki agordon ĉar:

havas unufojan programeblan datumstokan areon (ĝuste kie la Intel BG-agordo estas skribita);
nur Intel ME povas legi kaj programi ĝin.

Do, por agordi la agordon por Intel BG-teknologio sur specifa sistemo, la vendisto faras la jenon dum produktado:

Uzante la ilon Flash Image Tool (de Intel STK), kreas firmvarbildon kun donita Intel BG-agordo kiel variabloj ene de la Intel ME-regiono (la tielnomita provizora spegulo por FPF-oj);
Uzante la Flash Programing Tool (de Intel STK), skribas ĉi tiun bildon al la SPI-flash-memoro de la sistemo kaj fermas la tn. reĝimo de fabrikado (en ĉi tiu kazo, la responda komando estas sendita al Intel ME).

Kiel rezulto de ĉi tiuj operacioj, Intel ME transdonos al FPF-oj la specifitajn valorojn de la spegulo por FPF-oj en la ME-regiono, starigos la permesojn en SPI-fulmaj priskribiloj al la valoroj rekomenditaj de Intel (priskribitaj komence de la artikolo) kaj fari sistemon RESET.

Intel Boot Guard Implementation Analysis

Por analizi la efektivigon de ĉi tiu teknologio sur specifa ekzemplo, ni kontrolis la sekvajn sistemojn por spuroj de Intel BG-teknologio:

sistemo
Примечание

Gigabajto GA-H170-D3H
Skylake, ekzistas subteno

Gigabajto GA-Q170-D3H
Skylake, ekzistas subteno

Gigabajto GA-B150-HD3
Skylake, ekzistas subteno

MSI H170A Gaming Pro
Skylake, neniu subteno

Lenovo ThinkPad 460
Skylake, subteno disponebla, teknologio ebligita

Lenovo Yoga 2 Avantaĝo
Haswell, neniu subteno

Lenovo U330p
Haswell, neniu subteno

"Subteno" signifas la ĉeeston de la Intel BG startup ACM modulo, la manifestoj menciitaj supre kaj la responda kodo en la BIOS, t.e. efektivigoj por analizo.

Kiel ekzemplo, ni prenu tiun elŝutitan el la oficejo. vendista retejo-bildo de SPI fulmmemoro por Gigabyte GA-H170-D3H (versio F4).

Intel CPU-ŝarga ROM

Antaŭ ĉio, ni parolu pri la agoj de la procesoro se Intel BG-teknologio estas ebligita.

Ne eblis trovi specimenojn de la deĉifrita mikrokodo, tial, kiel la agoj priskribitaj malsupre estas efektivigitaj (en mikrokodo aŭ en aparataro) estas malferma demando. Tamen, la fakto, ke modernaj Intel-procesoroj "povas" plenumi ĉi tiujn agojn estas fakto.

Post eliro de la stato RESET, la procesoro (en kies adresspaco la enhavo de la fulmmemoro jam estas mapita) trovas la FIT (Firmware Interface Table). Trovi ĝin estas facila, la montrilo al ĝi estas skribita ĉe la adreso FFFF FFC0h.

En ĉi tiu ekzemplo, ĉi tiu adreso enhavas la valoron FFD6 9500h. Turnante al ĉi tiu adreso, la procesoro vidas la FIT-tabelon, kies enhavo estas dividita en registrojn. La unua eniro estas la titolo de la sekva strukturo:

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

Pro iu nekonata kialo, la ĉeksumo ne ĉiam estas kalkulita en ĉi tiuj tabeloj (la kampo estas lasita nula).

La ceteraj enskriboj montras diversajn binarojn, kiuj devas esti analizitaj / ekzekutitaj antaŭ ol la BIOS estas ekzekutita, t.e. antaŭ ol ŝanĝi al la heredaĵo RESET-vektoro (FFFF FFF0h). La strukturo de ĉiu tia eniro estas kiel sekvas:

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

La kampo EntryType indikas la tipon de bloko al kiu ĉi tiu eniro montras. Ni scias pri pluraj specoj:

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

Nun estas evidente, ke unu el la eniroj montras al la loko de la binaro de la starta ACM de Intel BG. La kapstrukturo de ĉi tiu duumaro estas tipa por kodmoduloj evoluigitaj fare de Intel (ACMoj, mikrokodaj ĝisdatigoj, Intel ME-kodsekcioj, ...).

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

La procesoro ŝarĝas ĉi tiun binaron en sian kaŝmemoron, kontrolas kaj lanĉas.

Intel BG-komenco ACM

Kiel rezulto de la analizo de la laboro de ĉi tiu ACM, evidentiĝis, ke ĝi faras la jenon:

ricevas de Intel ME la Intel BG-agordon skribitan al la chipset-fuzeoj (FPF);
trovas KEYM kaj IBBM manifestojn, kontrolas ilin.

Por trovi ĉi tiujn manifestojn, ACM ankaŭ uzas la FIT-tabelon, kiu havas du specojn de enskriboj por montri ĉi tiujn strukturojn (vidu FIT_ENTRY_TYPES supre).

Ni rigardu pli detale la manifestojn. En la strukturo de la unua manifesto, ni vidas plurajn obskurajn konstantojn, haŝon de la publika ŝlosilo de la dua manifesto, kaj publikan OEM-Radikan Ŝlosilon subskribitan kiel nesta strukturo:

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

Por kontroli la publikan ŝlosilon de la OEM Root Key, ni memoras, ke la SHA256 hash de la fuzeoj estas uzata, kiu nuntempe jam ricevis de Intel ME.

Ni transiru al la dua manifesto. Ĝi konsistas el tri strukturoj:

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

La unua enhavas kelkajn konstantojn:

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

La dua enhavas la SHA256-haŝiŝon de la IBB kaj la nombron da priskribiloj kiuj priskribas la enhavon de la IBB (t.e. de kio la haŝo estas kalkulita):

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

La IBB-priskribiloj sekvas ĉi tiun strukturon, unu post la alia. Ilia enhavo havas la jenan formaton:

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

Ĝi estas simpla: ĉiu priskribilo enhavas la adreson/grandecon de IBB-peco. Tiel, la kunligado de la blokoj indikitaj de ĉi tiuj priskribiloj (en la ordo de la priskribiloj mem) estas IBB. Kaj, kiel regulo, IBB estas kombinaĵo de ĉiuj moduloj de la SEC kaj PEI-fazoj.

La dua manifesto finiĝas kun strukturo enhavanta la IBB publikan ŝlosilon (kontrolitan per la SHA256 hash de la unua manifesto) kaj la subskribon de ĉi tiu manifesto:

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

Do, eĉ antaŭ la komenco de la ekzekuto de UEFI BIOS, la procesoro lanĉos ACM, kiu kontrolos la aŭtentikecon de la enhavo de sekcioj kun la fazokodo SEC kaj PEI. Poste, la procesoro forlasas la ACM, moviĝas laŭ la RESET-vektoro, kaj komencas ekzekuti la BIOS.

La PEI kontrolita sekcio devas enhavi modulon kiu kontrolos la reston de la BIOS (DXE-kodo). Ĉi tiu modulo jam estas disvolvita de IBV (Independent BIOS Vendor) aŭ la sistemvendisto mem. Ĉar Nur Lenovo kaj Gigabyte-sistemoj montriĝis je nia dispono kaj havante Intel BG-subtenon, ni konsideru la kodon ĉerpita el ĉi tiuj sistemoj.

UEFI BIOS-modulo LenovoVerifiedBootPei

En la kazo de Lenovo, ĝi montriĝis esti la modulo LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, evoluigita de Lenovo.

Ĝia tasko estas serĉi (per GUID) hashtabelon por la DXE kaj kontroli la 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-modulo BootGuardPei

En la kazo de Gigabyte, ĝi montriĝis esti la modulo BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, evoluigita de AMI, kaj do ĉeestas en iu ajn AMI-BIOS kun Intel BG-subteno.

Ĝia algoritmo de operacio estas iom malsama, tamen ĝi resumas al la 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;
}

La hashtabelo {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} kiun ĝi serĉas havas la jenan formaton:

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

Ni mallonge parolu pri alia efektivigo de Intel Boot Guard, kiu troviĝis en pli nova sistemo bazita sur Intel SoC kun mikroarkitekturo Apollo Lake - ASRock J4205-IT.

Kvankam ĉi tiu versio nur estos uzata en SoC-oj (novaj sistemoj kun mikroarkitekturo de procesoro Kaby Lake daŭre uzas Intel Boot Guard 1.x), ĝi estas de granda intereso esplori novan arkitekturopcion por platformoj bazitaj sur Intel SoC-oj, kiu vidis palpebla. ŝanĝoj, ekzemple:

BIOS kaj Intel ME-regionoj (aŭ pli ĝuste Intel TXE, laŭ Intel SoC-terminologio) nun estas unu IFWI-regiono;
kvankam Intel BG estis ebligita sur la platformo, strukturoj kiel ekzemple FIT, KEYM, IBBM ne estis trovitaj en fulmmemoro;
krom TXE kaj ISH-kernoj (x86), tria kerno (denove ARC, cetere) estis aldonita al la pecetaro - PMC (Power Management Controller), asociita kun certigado de la operaco de la potenca subsistemo kaj agado-monitorado.

La enhavo de la nova IFWI-regiono estas aro de la sekvaj moduloj:

Fiasko
nomo
Priskribo

0000 2000 h
SMIP
iu platforma agordo, subskribita de la vendisto

0000 6000 h
RBEP
Intel TXE-firmvarokodsekcio, x86, subskribita fare de Intel

0001 0000 h
PMCP
firmware-kodsekcio Intel PMC, ARC, subskribita fare de Intel

0002 0000 h
FTPR
Intel TXE-firmvarokodsekcio, x86, subskribita fare de Intel

0007B000h
UCOD
CPU-mikrokodaj ĝisdatigoj subskribitaj de Intel

0008 0000 h
IBBP
UEFI BIOS, SEC/PEI-fazoj, x86, vendisto subskribita

0021 8000 h
ISHC
kodsekcio de la Intel ISH-firmvaro, x86, subskribita de la vendisto

0025 8000 h
NFTP
Intel TXE-firmvarokodsekcio, x86, subskribita fare de Intel

0036 1000 h
IUNP
estas nekonata

0038 1000 h
OBBP
UEFI BIOS, DXE-fazo, x86, nesubskribita

Dum la analizo de la TXE-firmvaro, evidentiĝis, ke post RESET, TXE tenas la procesoron en ĉi tiu stato ĝis ĝi preparas la bazan enhavon de la adresspaco por la CPU (FIT, ACM, RESET-vektoro ...). Krome, TXE metas ĉi tiujn datumojn en sian SRAM, post kio ĝi provizore provizas la procesoron per aliro tie kaj "liberigas" ĝin de RESET.

Sur gardo de rootkits

Nu, nun ni transiru al la "varma". Ni iam malkovris, ke en multaj sistemoj, SPI-flash-priskribiloj havas permesojn aliri regionojn de SPI-flash-memoro tiel ke ĉiuj uzantoj de ĉi tiu memoro povas kaj skribi kaj legi ajnan regionon. Tiuj. neniel.

Post kontroli kun la utileco MEinfo (de Intel STK), ni vidis, ke la fabrikada reĝimo de ĉi tiuj sistemoj ne estis fermita, tial la chipset-fuzeoj (FPF) estis lasitaj en nedeterminita stato. Jes, Intel BG estas nek ebligita nek malŝaltita en tiaj kazoj.

Ni parolas pri la sekvaj sistemoj (koncerne Intel BG kaj kio estos priskribita poste en la artikolo, ni parolos pri sistemoj kun Haswell-procesora mikroarkitekturo kaj pli alta):

ĉiuj Gigabajtaj produktoj;
ĉiuj MSI-produktoj;
21 Lenovo-tekkomputilmodeloj kaj 4 Lenovo-servilmodeloj.

Kompreneble, ni raportis la trovon al ĉi tiuj vendistoj, same kiel al Intel.

Adekvata respondo sekvis nur el lenovokiu agnoskis la problemon kaj liberigis peceton.

Gigabajto Ŝajnas, ke ili akceptis informojn pri la vundebleco, sed neniel komentis.

Komunikado kun MSI tute haltis laŭ nia peto sendi nian publikan PGP-ŝlosilon (por sendi al ili ĉifritan sekurecan konsilon). Ili deklaris ke ili "estas hardvarproduktanto kaj ne produktas PGP-ŝlosilojn."

Sed pli al la punkto. Ĉar la fuzeoj estas lasitaj en nedifinita stato, la uzanto (aŭ atakanto) povas mem programi ilin (la plej malfacila estas trovi Intel STK). Ĉi tio postulas la sekvajn paŝojn.

1. Ŝarĉu en Windows OS (ĝenerale, la paŝoj priskribitaj malsupre ankaŭ povas esti faritaj de sub Linukso, se vi disvolvas analogon de Intel STK por la dezirata OS). Uzante la utilecon MEinfo, certigu, ke la fuzeoj de ĉi tiu sistemo ne estas programitaj.

2. Legu la enhavon de fulmmemoro uzante la Fulman Programadon.

3. Malfermu la legitan bildon per iu ajn UEFI-BIOS-redaktilo, faru la necesajn ŝanĝojn (efektivigu rootkit, ekzemple), kreu / redaktu la ekzistantajn KEYM kaj IBBM-strukturojn en la ME-regiono.

La publika parto de la RSA-ŝlosilo estas elstarigita en la bildo, kies hash estos programita en la pecetaj fuzeoj kune kun la resto de la Intel BG-agordo.

4. Uzante la Flash Image Tool, konstruu novan firmvarbildon (agordante la Intel BG-agordon).

5. Skribu novan bildon por ekbrili per la Flash-Programado, kontrolu per MEinfo, ke la ME-regiono nun enhavas la Intel BG-agordon.

6. Uzu la Fulman Programan Ilon por fermi la produktadreĝimon.

7. La sistemo rekomencos, post kio, uzante MEinfo, vi povas kontroli, ke la FPF-oj nun estas programitaj.

Ĉi tiuj agoj por ĉiam ebligu Intel BG sur ĉi tiu sistemo. Estos neeble malfari la agon, kio signifas:

nur la posedanto de la privata parto de la radika ŝlosilo (t.e. tiu, kiu ebligis Intel BG) povos ĝisdatigi la UEFI BIOS en ĉi tiu sistemo;
se vi resendas la originalan firmware al ĉi tiu sistemo, ekzemple, uzante programiston, ĝi eĉ ne ekŝaltos (sekvo de plenuma politiko en la okazo de konfirma eraro);
por forigi tian UEFI-BIOS, vi devas anstataŭigi la pecetaron per programitaj FPF-oj per "pura" unu (t.e. resolvi la pecetaron se vi havas aliron al infraruĝa lutstacio je la prezo de aŭto, aŭ simple anstataŭigi la baztablon. ).

Por kompreni, kion tia rootkit povas fari, vi devas taksi kio ebligas ekzekuti vian kodon en UEFI BIOS-medio. Diru, en la plej privilegia reĝimo de la procesoro - SMM. Tia rootkit povas havi la jenajn trajtojn:

esti ekzekutita paralele kun la OS (vi povas agordi prilaboradon generante SMI-interrompon, kiu estos ekigita de tempigilo);
havas ĉiujn avantaĝojn esti en SMM-reĝimo (plena aliro al la enhavo de RAM kaj aparataj rimedoj, sekreteco de la OS);
La rootkit-kodo povas esti ĉifrita kaj deĉifrita kiam lanĉita en SMM-reĝimo. Ĉiuj datumoj disponeblaj nur en SMM-reĝimo povas esti uzata kiel ĉifrada ŝlosilo. Ekzemple, hash de aro de adresoj en SMRAM. Por akiri ĉi tiun ŝlosilon, vi devos grimpi en la SMM. Kaj ĉi tio povas esti farita en du manieroj. Trovu la RCE en la SMM-kodo kaj ekspluatu ĝin, aŭ aldonu vian propran SMM-modulon al la BIOS, kio estas neebla, ĉar ni ebligis Boot Guard.

Tiel, ĉi tiu vundebleco permesas al atakanto:

krei kaŝitan, neforigeblan rootkit de nekonata celo en la sistemo;
ekzekuti vian kodon sur unu el la pecetaj kernoj ene de la Intel SoC, nome, sur la Intel ISH (rigardu pli detale la bildon).

Kvankam la kapabloj de la subsistemo Intel ISH ankoraŭ ne estis esploritaj, ĝi ŝajnas esti interesa atakvektoro kontraŭ Intel ME.

trovoj

La studo disponigis teknikan priskribon pri kiel funkcias la teknologio Intel Boot Guard. Minus kelkaj sekretoj en la sekureco de Intel per obskurecmodelo.
Atakoscenaro estas prezentita, kiu permesas krei neforigeblan rootkit en la sistemo.
Ni vidis, ke modernaj Intel-procesoroj kapablas efektivigi multe da proprieta kodo eĉ antaŭ ol la BIOS komenciĝas.
Platformoj kun arkitekturo Intel 64 iĝas ĉiam malpli taŭgaj por funkciigado de libera programaro: aparataro-konfirmo, kreskanta nombro da proprietaj teknologioj kaj subsistemoj (tri kernoj en la SoC-pecetaro: x86 ME, x86 ISH kaj ARC PMC).

Mildigoj

Vendistoj, kiuj intencite lasas fabrikan reĝimon malfermita, nepre devas fermi ĝin. Ĝis nun ili nur fermas la okulojn kaj la novaj sistemoj de Kaby Lake montras tion.

Uzantoj povas malŝalti Intel BG sur siaj sistemoj (kiuj estas tuŝitaj de la priskribita vundebleco) rulante la Fulman Programan Ilon kun la opcio -closemnf. Unue, vi devus certigi (uzante MEinfo) ke la agordo de Intel BG en la ME-regiono zorgas ĝuste malŝalti ĉi tiun teknologion post programado en FPF-oj.

fonto: www.habr.com

La fidinda boto de Schrödinger. Intel Boot Guard