🥇Schrödinger betroubare aflaai. Intel Boot Guard

Ons stel voor om weer na die lae vlak te gaan en te praat oor die sekuriteit van firmware x86-versoenbare rekenaarplatforms. Hierdie keer is die hoofbestanddeel van die studie Intel Boot Guard (moet nie verwar word met Intel BIOS Guard nie!) - 'n hardeware-ondersteunde BIOS-betroubare selflaaitegnologie wat 'n rekenaarstelselverskaffer permanent in die produksiestadium kan aan- of afskakel. Wel, ons ken reeds die navorsingsresep: sny die implementering van hierdie tegnologie fyn deur omgekeerde ingenieurswese, beskryf die argitektuur daarvan, vul dit met ongedokumenteerde besonderhede, geur dit met aanvalsvektore na smaak en meng dit op. Kom ons voeg vuur by met 'n storie oor hoe 'n gekloonde fout in die produksie van verskeie verskaffers vir jare 'n potensiële aanvaller toelaat om hierdie tegnologie te gebruik om 'n versteekte rootkit te skep wat nie (selfs deur 'n programmeerder) in die stelsel verwyder kan word nie.

Terloops, die artikel is gebaseer op die verslae "On Guard for Rootkits: Intel BootGuard" van die konferensie ZeroNights 2016 en 29ste vergadering DefCon Rusland (albei aanbiedings hier).

Firmware vir 'n rekenaarplatform met Intel 64-argitektuur

Om mee te begin, laat ons die vraag beantwoord: wat is die firmware van 'n moderne rekenaarplatform met die Intel 64-argitektuur? Natuurlik, UEFI BIOS. Maar hierdie antwoord sal nie akkuraat wees nie. Kom ons kyk na die figuur wat die rekenaarweergawe (skootrekenaar) van hierdie argitektuur toon.

Die basis is die skakel:

Verwerker (CPU, Sentrale Verwerkingseenheid), wat, benewens die hoofkerne, 'n ingeboude grafiese kern het (nie in alle modelle nie) en 'n geheuebeheerder (IMC, Integrated Memory Controller);
Chipset (PCH, Platform Controller Hub), wat verskeie beheerders bevat vir interaksie met perifere toestelle en die bestuur van substelsels. Onder hulle is die berugte Intel Management Engine (ME), wat ook 'n firmware (Intel ME-firmware) het.

Skootrekenaars benodig, benewens bogenoemde, 'n geïntegreerde kontroleerder (ACPI EC, Advanced Control and Power Interface Embedded Controller), wat verantwoordelik is vir die werking van die kragsubstelsel, raakpaneel, sleutelbord, Fn-sleutels (skermhelderheid, klankvolume, sleutelbord) agtergrondlig, ens.).) en meer. En hy het ook sy eie firmware.

Dus, die kombinasie van bogenoemde firmware is die firmware van die rekenaarplatform (stelselfirmware), wat op 'n algemene SPI-flitsgeheue gestoor word. Sodat gebruikers van hierdie geheue nie deurmekaar raak waar iemand lê nie, word die inhoud van hierdie geheue in die volgende streke verdeel (soos in die figuur getoon):

UEFI BIOS;
ACPI EC-firmware ('n aparte streek het verskyn met die Skylake-verwerker-mikro-argitektuur (2015), maar in-die-wild het ons nog nie voorbeelde van die gebruik daarvan gesien nie, so die ingeboude kontroleerderfirmware is steeds deel van die UEFI BIOS);
Intel ME-firmware;
konfigurasie (MAC-adres, ens.) van die ingeboude GbE (Gigabit Ethernet) netwerkadapter;
flitsbeskrywings - die hoofstreek van flitsgeheue, wat wysers na ander streke bevat, sowel as toestemmings om toegang daartoe te verkry.

Differensiasie van toegang tot streke (in ooreenstemming met die gespesifiseerde toestemmings) word deur die SPI-busmeester hanteer - die SPI-beheerder wat in die skyfiestel ingebou is, waardeur toegang tot hierdie geheue verkry word. As die toestemmings ingestel is op die waardes wat (om sekuriteitsredes) deur Intel aanbeveel word, dan het elke gebruiker van die SPI-flits slegs volle toegang (lees/skryf) tot hul streek. Die res is óf leesalleen óf ontoeganklik. Bekende feit: op baie stelsels het die SVE volle toegang tot die UEFI BIOS en GbE, leestoegang slegs tot flitsbeskrywings, en glad nie toegang tot die Intel ME-streek nie. Hoekom baie en nie almal nie? Wat aanbeveel word, is opsioneel. Ons sal jou later in die artikel meer vertel.

Meganismes om die firmware van 'n rekenaarplatform teen verandering te beskerm

Uiteraard moet die firmware van 'n rekenaarplatform beskerm word teen moontlike kompromie, wat 'n potensiële aanvaller sal toelaat om 'n vastrapplek daarin te kry (oorleef OS-opdaterings / herinstallasies), hul kode in die mees bevoorregte modusse uit te voer, ens. En die afbakening van toegang tot SPI-flitsgeheuestreke is natuurlik nie genoeg nie. Daarom word verskeie meganismes spesifiek vir elke uitvoeringsomgewing gebruik om die firmware teen wysigings te beskerm.

Dus, die Intel ME-firmware is onderteken vir integriteit- en egtheidbeheer, en word deur die ME-beheerder nagegaan elke keer as dit in die ME UMA-geheue gelaai word. Hierdie verifikasieproses is reeds deur ons bespreek in een van die artikelstoegewy aan die Intel ME-substelsel.

En ACPI EC-firmware word as 'n reël slegs vir integriteit nagegaan. As gevolg van die feit dat hierdie binêre by die UEFI BIOS ingesluit is, is dit egter byna altyd onderhewig aan dieselfde beskermingsmeganismes wat die UEFI BIOS gebruik. Kom ons praat oor hulle.

Hierdie meganismes kan in twee kategorieë verdeel word.

Skryfbeskerming na UEFI BIOS-streek

Fisiese beskerming van die inhoud van die SPI-flitsgeheue met 'n skryfbeskermende springer;
Beskerming van die projeksie van die UEFI BIOS-streek in die SVE-adresruimte deur gebruik te maak van die skyfiestel se PRx-registers;
Blokkeer pogings om na die UEFI BIOS-streek te skryf deur die ooreenstemmende SMI-onderbreking te genereer en te verwerk deur die BIOS_WE / BLE- en SMM_BWP-bisse in die skyfiestelregisters in te stel;
'n Meer gevorderde weergawe van hierdie beskerming is Intel BIOS Guard (PFAT).

Benewens hierdie meganismes, kan verskaffers hul eie sekuriteitsmaatreëls ontwikkel en implementeer (byvoorbeeld die ondertekening van kapsules met UEFI BIOS-opdaterings).

Dit is belangrik om daarop te let dat op 'n spesifieke stelsel (afhangende van die verkoper), nie al die bogenoemde beskermingsmeganismes toegepas kan word nie, hulle mag glad nie toegepas word nie, of hulle kan op 'n kwesbare manier geïmplementeer word. Jy kan meer lees oor hierdie meganismes en die situasie met die implementering daarvan in Hierdie artikel. Vir diegene wat belangstel, beveel ons aan dat u die hele reeks artikels oor UEFI BIOS-sekuriteit lees vanaf CodeRush.

UEFI BIOS-verifikasieverifikasie

As ons praat oor betroubare selflaai-tegnologieë, is die eerste ding wat by ons opkom Secure Boot. Argitektonies is dit egter ontwerp om komponente buite die UEFI BIOS (bestuurders, laaiers, ens.) te verifieer en nie die firmware self nie.

Daarom het Intel in SoC's met die Bay Trail-mikro-argitektuur (2012) 'n hardeware nie-wisselbare Secure Boot (Verified Boot) geïmplementeer, wat niks te doen het met die voorgenoemde Secure Boot-tegnologie nie. Later (2013) is hierdie meganisme verbeter en is onder die naam Intel Boot Guard vrygestel vir rekenaars met die Haswell-mikroargitektuur.

Voordat ons Intel Boot Guard beskryf, kom ons kyk na die uitvoeringsomgewings in die Intel 64-argitektuur, wat in kombinasie die wortels van vertroue vir hierdie betroubare selflaaitegnologie is.

Intel CPU

Cap stel voor dat die verwerker die belangrikste uitvoeringsomgewing in die Intel 64-argitektuur is. Hoekom is dit ook die wortel van vertroue? Dit blyk dat dit die besit van die volgende elemente is wat dit so maak:

Mikrokode ROM is 'n nie-vlugtige, nie-herskryfbare geheue vir die stoor van mikrokode. Daar word geglo dat mikrokode die implementering van die verwerker-instruksiestelsel volgens die eenvoudigste instruksies is. Gebeur ook in mikrokode goggas. So in die BIOS kan jy binaries met mikrokode-opdaterings vind (hulle word tydens selflaaityd oorgeplaas, omdat die ROM nie oorskryf kan word nie). Die inhoud van hierdie binaries word geïnkripteer, wat analise baie bemoeilik (daarom is die spesifieke inhoud van die mikrokode slegs bekend aan diegene wat dit ontwikkel), en onderteken om die integriteit en egtheid te beheer;
AES-sleutel om die inhoud van mikrokode-opdaterings te dekripteer;
'n hash van die RSA publieke sleutel wat die handtekening van mikrokode-opdaterings verifieer;
RSA publieke sleutel hash, wat die handtekening van Intel-ontwikkelde ACM (Authenticated Code Module) kode modules nagaan, wat die SVE kan laat loop voordat die BIOS begin (hallo mikrokode) of tydens die werking daarvan, wanneer sommige gebeure plaasvind.

Intel ME

Hierdie substelsel in ons blog is gewy aan twee Artikel. Onthou dat hierdie uitvoerbare omgewing gebaseer is op die mikrobeheerder wat in die skyfiestel ingebou is en die mees versteekte en bevoorregte in die stelsel is.

Ten spyte van die stealth, is Intel ME ook die wortel van vertroue, want dit het:

ME ROM - nie-vlugtige, nie-herskryfbare geheue (geen opdateringsmetode verskaf nie), wat die beginkode bevat, sowel as die SHA256-hash van die RSA publieke sleutel, wat die handtekening van die Intel ME-firmware nagaan;
AES-sleutel vir die stoor van geheime inligting;
toegang tot 'n stel sekerings (FPF's, Field Programmable Fuses) geïntegreer in die skyfiestel vir permanente berging van sekere inligting, insluitend inligting gespesifiseer deur die rekenaarstelselverskaffer.

Intel Boot Guard 1.x

Klein vrywaring. Die weergawenommers van Intel Boot Guard-tegnologie wat ons in hierdie artikel gebruik, is arbitrêr en het dalk niks te doen met die nommering wat in interne Intel-dokumentasie gebruik word nie. Daarbenewens is die inligting oor die implementering van hierdie tegnologie wat hier gegee word tydens omgekeerde ingenieurswese verkry, en kan dit onakkuraathede bevat in vergelyking met die spesifikasie vir Intel Boot Guard, wat waarskynlik nie ooit gepubliseer sal word nie.

Dus, Intel Boot Guard (BG) is 'n hardeware-ondersteunde UEFI BIOS-verifikasietegnologie. Te oordeel aan sy klein beskrywing in die boek [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], werk dit as 'n betroubare selflaaiketting. En die eerste skakel daarin is die selflaaikode (mikrokode) binne die SVE, wat deur die RESET-gebeurtenis geaktiveer word (nie te verwar met die RESET-vektor in die BIOS nie!). Die SVE vind 'n kodemodule (Intel BG opstart ACM) ontwikkel en onderteken deur Intel op die SPI-flitsgeheue, laai dit in sy kas, verifieer dit (daar is reeds hierbo opgemerk dat die SVE 'n publieke sleutelhash het wat die ACM-handtekening verifieer ) en begin.

Hierdie kodemodule is verantwoordelik vir die verifikasie van 'n klein begindeel van die UEFI BIOS - Initial Boot Block (IBB), wat op sy beurt die funksionaliteit bevat om die hoofgedeelte van die UEFI BIOS te verifieer. Dus, Intel BG laat jou toe om die egtheid van die BIOS te verifieer voordat jy die bedryfstelsel begin (wat onder toesig van Secure Boot-tegnologie uitgevoer kan word).

Intel BG-tegnologie bied twee werkingsmodusse (en die een meng nie met die ander in nie, dit wil sê beide modusse kan op die stelsel geaktiveer word, en albei kan gedeaktiveer word).

Gemeet Boot

In Measured Boot (MB)-modus, "meet" elke opstartkomponent (begin met die CPU-boot ROM) die volgende een deur die vermoëns van die Trusted Platform Module (TPM) te gebruik. Vir die wat nie weet nie, laat ek verduidelik.

TPM het PCR's (Platform Configuration Registers), wat die resultaat van die hashing-bewerking volgens die formule aanteken:

Dié. die huidige PCR-waarde hang af van die vorige een, en hierdie registers word slegs teruggestel wanneer die stelsel TERUGSTEL.

Dus, in MB-modus, op 'n sekere tydstip, weerspieël PCR's 'n unieke (binne die vermoëns van die hash-operasie) identifiseerder van die kode of data wat "gemeet" is. Die PCR-waardes kan gebruik word in die enkripsie van sommige data (TPM_Seal) operasie. Daarna sal hul dekripsie (TPM_Unseal) slegs moontlik wees as die PCR-waardes nie verander het as gevolg van die laai nie (d.w.s. nie 'n enkele "gemeet" komponent is gewysig nie).

Geverifieerde laars

Die skrikwekkendste ding vir diegene wat daarvan hou om die UEFI BIOS te verander, is die Verified Boot (VB) -modus, waarin elke opstartkomponent kriptografies die integriteit en egtheid van die volgende een verifieer. En in die geval van 'n verifikasiefout, vind (een van die volgende) plaas:

afskakel deur tydsverloop van 1 minuut tot 30 minute (sodat die gebruiker tyd het om te verstaan hoekom sy rekenaar nie selflaai nie, en, indien moontlik, sou probeer om die BIOS te herstel);
onmiddellike afsluiting (sodat die gebruiker nie tyd het om te verstaan en boonop te doen nie);
voortsetting van werk met 'n reguit gesig (die geval wanneer daar nie tyd vir veiligheid is nie, want daar is belangriker dinge om te doen).

Die keuse van aksie hang af van die gespesifiseerde Intel BG-konfigurasie (naamlik op die sogenaamde afdwingingsbeleid), wat permanent deur die rekenaarplatformverkoper in 'n spesiaal ontwerpte stoorplek aangeteken word - skyfiestelversmeltings (FPF's). Ons sal later in meer besonderhede by hierdie punt stilstaan.

Benewens die konfigurasie, genereer die verkoper twee RSA 2048-sleutels en skep twee datastrukture (getoon in die figuur):

Die verkoper se wortelsleutelmanifes (KEYM, OEM Root Key Manifest), wat die SVN (Sekuriteitsweergawenommer) van hierdie manifes plaas, die SHA256-hash van die publieke sleutel van die volgende manifes, die RSA publieke sleutel (d.w.s. die publieke deel van die verkoper se wortelsleutel) om die handtekening van hierdie manifes en die handtekening self te verifieer;
Die IBB-manifes (IBBM, Initial Boot Block Manifest), wat die SVN van hierdie manifes, die SHA256-hash van die IBB, die publieke sleutel om die handtekening van hierdie manifes te verifieer, en die handtekening self plaas.

Die SHA256-hash van die OEM-wortelsleutel word permanent na skyfiestel-versmeltings (FPF's) geskryf, net soos die Intel BG-konfigurasie. As die Intel BG-konfigurasie voorsiening maak vir die insluiting van hierdie tegnologie, dan kan hierdie stelsel van nou af net die eienaar van die private deel van die OEM-wortelsleutel die BIOS opdateer (d.w.s. in staat wees om hierdie manifeste te herbereken), d.w.s. verkoper.

As jy na die prentjie kyk, ontstaan daar dadelik twyfel oor die behoefte aan so 'n lang verifikasieketting – jy kon een manifes gebruik het. Hoekom kompliseer?

Trouens, Intel bied dus die verkoper die geleentheid om verskillende IBB-sleutels vir verskillende produklyne en een as die wortel te gebruik. As die private deel van die IBB-sleutel (wat die tweede manifes teken) uitgelek word, sal die voorval slegs een produklyn affekteer en slegs totdat die verkoper 'n nuwe paar genereer en die herberekende manifeste in die volgende BIOS-opdatering aktiveer.

Maar as die wortelsleutel gekompromitteer word (waarmee die eerste manifes onderteken is), sal dit nie moontlik wees om dit te vervang nie, die herroepingsprosedure word nie verskaf nie. die hash van die publieke deel van hierdie sleutel word eens en vir altyd in FPF's geprogrammeer.

Intel Boot Guard-konfigurasie

Kom ons kyk nou van naderby na die Intel BG-konfigurasie en die proses van die skepping daarvan. As jy na die ooreenstemmende oortjie in die GUI van die Flash Image Tool van die Intel System Tool Kit (STK) kyk, sal jy sien dat die Intel BG-konfigurasie 'n hash van die publieke deel van die verkoper se wortelsleutel insluit, 'n paar obskure waardes, ensovoorts. Intel BG-profiel.

Die struktuur van hierdie profiel:

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

Oor die algemeen is die Intel BG-konfigurasie 'n baie buigsame entiteit. Oorweeg byvoorbeeld die Force_Boot_Guard_ACM-vlag. Wanneer dit uitgevee is, as die BG-opstart-ACM-module op die SPI-flits nie gevind word nie, sal geen betroubare selflaai plaasvind nie. Dit sal onbetroubaar wees.

Ons het reeds hierbo geskryf dat die afdwingingsbeleid vir die VB-modus so opgestel kan word dat as verifikasie misluk, weer 'n onbetroubare aflaai sal plaasvind.

Laat dinge soos hierdie aan die verkopers oor...

Die GUI van die hulpprogram verskaf die volgende "gereedgemaakte" profiele:

Nee
regime
Beskrywing

0
Nee_FVME
Intel BG-tegnologie gedeaktiveer

1
VE
VB-modus geaktiveer, afskakel deur uitteltyd

2
VME
beide modusse is geaktiveer (VB en MB), afgesluit deur uitteltyd

3
VM
beide modusse is geaktiveer, sonder om die stelsel af te skakel

4
FVE
VB-modus geaktiveer, onmiddellike afsluiting

5
FVME
beide modusse geaktiveer, onmiddellike afsluiting

Soos reeds genoem, moet die Intel BG-konfigurasie eens en vir altyd deur die stelselverkoper in skyfiestelversmeltings (FPF's) geskryf word - 'n klein (volgens ongeverifieerde inligting, slegs 256 grepe) hardeware-inligtingberging binne die skyfiestel, wat buite geprogrammeer kan word van Intel se produksiefasiliteite (dus dit is hoekom Veldprogrammeerbaar versmeltings).

Dit is ideaal vir die stoor van konfigurasie omdat:

het 'n eenmalige programmeerbare databergingsarea (net waar die Intel BG-konfigurasie geskryf is);
net Intel ME kan dit lees en programmeer.

Dus, om die konfigurasie vir Intel BG-tegnologie op 'n spesifieke stelsel te stel, doen die verkoper die volgende tydens produksie:

Deur die Flash Image Tool (van Intel STK) te gebruik, skep 'n firmware-beeld met 'n gegewe Intel BG-konfigurasie as veranderlikes binne die Intel ME-streek (die sogenaamde tydelike spieël vir FPF's);
Met behulp van die Flash Programming Tool (van Intel STK), skryf hierdie beeld na die SPI flash geheue van die stelsel en sluit die sogenaamde. vervaardigingsmodus (in hierdie geval word die ooreenstemmende opdrag na Intel ME gestuur).

As gevolg van hierdie bewerkings sal Intel ME die gegewe waardes van die spieël vir FPF's in die ME-streek aan FPF's verbind, die toestemmings in SPI-flitsbeskrywings stel na die waardes wat deur Intel aanbeveel word (beskryf aan die begin van die artikel) en voer 'n stelsel-TERUGSTEL uit.

Intel Boot Guard-implementeringsanalise

Om die implementering van hierdie tegnologie op 'n spesifieke voorbeeld te analiseer, het ons die volgende stelsels nagegaan vir spore van Intel BG-tegnologie:

System
Let daarop

Gigabyte GA-H170-D3H
Skylake, daar is ondersteuning

Gigabyte GA-Q170-D3H
Skylake, daar is ondersteuning

Gigabyte GA-B150-HD3
Skylake, daar is ondersteuning

MSI H170A Gaming Pro
Skylake, geen ondersteuning nie

Lenovo ThinkPad 460
Skylake, ondersteuning beskikbaar, tegnologie geaktiveer

Lenovo Joga 2 Pro
Haswell, geen ondersteuning nie

Lenovo U330p
Haswell, geen ondersteuning nie

"Ondersteuning" beteken die teenwoordigheid van die Intel BG opstart ACM-module, die manifeste hierbo genoem en die ooreenstemmende kode in die BIOS, d.w.s. implementering vir analise.

As voorbeeld, kom ons neem die een wat van die kantoor afgelaai is. verkoper webwerf beeld van SPI flash geheue vir Gigabyte GA-H170-D3H (weergawe F4).

Intel CPU selflaai ROM

Eerstens, kom ons praat oor die aksies van die verwerker as Intel BG-tegnologie geaktiveer is.

Dit was nie moontlik om voorbeelde van die gedekripteerde mikrokode te vind nie, daarom is hoe die aksies wat hieronder beskryf word geïmplementeer word (in mikrokode of in hardeware) 'n oop vraag. Nietemin is die feit dat moderne Intel-verwerkers hierdie aksies "kan" uitvoer, 'n feit.

Nadat die RESET-toestand verlaat is, vind die verwerker (in wie se adresruimte die inhoud van die flitsgeheue reeds gekarteer is) die FIT (Firmware Interface Table). Om dit maklik te vind, is die wyser daarna geskryf by die adres FFFF FFC0h.

In hierdie voorbeeld bevat hierdie adres die waarde FFD6 9500h. As u na hierdie adres kyk, sien die verwerker die FIT-tabel, waarvan die inhoud in rekords verdeel is. Die eerste inskrywing is die opskrif van die volgende struktuur:

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

Om een of ander onbekende rede word die kontrolesom nie altyd in hierdie tabelle bereken nie (die veld word nul gelaat).

Die oorblywende inskrywings wys na verskeie binaries wat ontleed / uitgevoer moet word voordat die BIOS uitgevoer word, d.w.s. voordat jy oorskakel na die verouderde RESET-vektor (FFFF FFF0h). Die struktuur van elke sodanige inskrywing is soos volg:

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

Die EntryType-veld dui die tipe blok aan waarna hierdie inskrywing verwys. Ons ken verskeie tipes:

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

Nou is dit duidelik dat een van die inskrywings dui op die ligging van die Intel BG-opstart ACM-binêre. Die kopstruktuur van hierdie binêre is tipies vir kodemodules wat deur Intel ontwikkel is (ACM's, mikrokode-opdaterings, Intel ME-kode-afdelings, ...).

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

Die verwerker laai hierdie binêre in sy kas, verifieer en begin.

Intel BG opstart ACM

As gevolg van die ontleding van die werk van hierdie ACM, het dit duidelik geword dat dit die volgende doen:

ontvang van Intel ME die Intel BG-konfigurasie wat na die skyfiestelversekerings (FPF's) geskryf is;
vind KEYM en IBBM manifeste, verifieer hulle.

Om hierdie manifeste te vind, gebruik ACM ook die FIT-tabel, wat twee tipes inskrywings het om na hierdie strukture te wys (sien FIT_ENTRY_TYPES hierbo).

Kom ons kyk van naderby na die manifeste. In die struktuur van die eerste manifes sien ons 'n paar obskure konstantes, 'n hash van die publieke sleutel van die tweede manifes, en 'n publieke OEM-wortelsleutel wat as 'n geneste struktuur onderteken is:

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

Om die publieke sleutel van die OEM-wortelsleutel te verifieer, onthou ons dat die SHA256-hash van die versmeltings gebruik word, wat op hierdie oomblik reeds van Intel ME ontvang is.

Kom ons gaan aan na die tweede manifes. Dit bestaan uit drie strukture:

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

Die eerste een bevat 'n paar konstantes:

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

Die tweede bevat die SHA256-hash van die IBB en die aantal beskrywers wat die inhoud van die IBB beskryf (d.w.s. waaruit die hash bereken word):

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

Die IBB-beskrywers volg hierdie struktuur, een na die ander. Hul inhoud het die volgende formaat:

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

Dit is eenvoudig: elke beskrywer bevat die adres/grootte van 'n IBB-stuk. Dus, die samevoeging van die blokke waarna deur hierdie beskrywers (in die volgorde van die beskrywers self) gewys word, is IBB. En as 'n reël is IBB 'n kombinasie van alle modules van die SEC- en PEI-fases.

Die tweede manifes eindig met 'n struktuur wat die IBB publieke sleutel bevat (geverifieer deur die SHA256 hash vanaf die eerste manifes) en die handtekening van hierdie manifes:

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

Dus, selfs voor die aanvang van die UEFI BIOS-uitvoering, sal die verwerker ACM begin, wat die egtheid van die inhoud van afdelings met die SEC- en PEI-fasekode sal verifieer. Vervolgens verlaat die verwerker die ACM, beweeg langs die RESET-vektor en begin die BIOS uitvoer.

Die PEI-geverifieerde partisie moet 'n module bevat wat die res van die BIOS (DXE-kode) sal kontroleer. Hierdie module word reeds ontwikkel deur IBV (Independent BIOS Vendor) of die stelselverskaffer self. Omdat Slegs Lenovo- en Gigabyte-stelsels het geblyk tot ons beskikking te wees en met Intel BG-ondersteuning, kom ons kyk na die kode wat uit hierdie stelsels onttrek is.

UEFI BIOS-module LenovoVerifiedBootPei

In die geval van Lenovo, het dit geblyk die LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}-module te wees, ontwikkel deur Lenovo.

Sy taak is om 'n hash-tabel vir die DXE op te soek (deur GUID) en die DXE te verifieer.

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-module BootGuardPei

In die geval van Gigabyte, het dit geblyk die BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}-module te wees, ontwikkel deur AMI, en dus teenwoordig in enige AMI BIOS met Intel BG-ondersteuning.

Die algoritme van werking is ietwat anders, maar dit kom op dieselfde neer:

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

Die hash-tabel {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} wat dit naslaan, het die volgende formaat:

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

Kom ons praat kortliks oor 'n ander implementering van Intel Boot Guard, wat gevind is in 'n nuwer stelsel gebaseer op Intel SoC met Apollo Lake mikroargitektuur - ASRock J4205-IT.

Alhoewel hierdie weergawe slegs in SoC's gebruik sal word (nuwe stelsels met Kaby Lake-verwerkermikroargitektuur gebruik steeds Intel Boot Guard 1.x), is dit van groot belang om 'n nuwe argitektuuropsie vir platforms gebaseer op Intel SoC's te ondersoek, wat tasbaar gesien het veranderinge, byvoorbeeld:

BIOS- en Intel ME-streke (of eerder Intel TXE, volgens Intel SoC-terminologie) is nou een IFWI-streek;
alhoewel Intel BG op die platform geaktiveer is, is strukture soos FIT, KEYM, IBBM nie in flitsgeheue gevind nie;
bykomend tot TXE- en ISH-kerns (x86), is 'n derde kern (terloops weer ARC) by die skyfiestel gevoeg - PMC (Power Management Controller), wat verband hou met die versekering van die werkbaarheid van die kragsubstelsel en prestasiemonitering.

Die inhoud van die nuwe IFWI-streek is 'n stel van die volgende modules:

Vooroordeel
naam
Beskrywing

0000 2000 uur
SMIP
een of ander platformkonfigurasie, onderteken deur die verkoper

0000 6000 uur
RBEP
Intel TXE-firmwarekode-afdeling, x86, onderteken deur Intel

0001 0000 uur
PMCP
fermware-kode afdeling Intel PMC, ARC, onderteken deur Intel

0002 0000 uur
FTPR
Intel TXE-firmwarekode-afdeling, x86, onderteken deur Intel

0007B000h
UCOD
CPU-mikrokode-opdaterings onderteken deur Intel

0008 0000 uur
IBBP
UEFI BIOS, SEC/PEI-fases, x86, verkoper onderteken

0021 8000 uur
ISHC
kode-afdeling van die Intel ISH-firmware, x86, onderteken deur die verkoper

0025 8000 uur
NFTP
Intel TXE-firmwarekode-afdeling, x86, onderteken deur Intel

0036 1000 uur
IUNP
is onbekend

0038 1000 uur
OBBP
UEFI BIOS, DXE-fase, x86, ongetekende

Tydens die ontleding van die TXE-firmware het dit duidelik geword dat na RESET, TXE die verwerker in hierdie toestand hou totdat dit die basiese inhoud van die adresspasie vir die SVE voorberei (FIT, ACM, RESET vektor ...). Boonop plaas TXE hierdie data in sy SRAM, waarna dit die verwerker tydelik toegang daartoe gee en dit van RESET "vrystel".

Op die hoede van rootkits

Wel, kom ons gaan nou oor na die "warm". Ons het eenkeer ontdek dat SPI-flitsbeskrywers op baie stelsels toestemmings het om toegang tot streke van SPI-flitsgeheue te verkry sodat alle gebruikers van hierdie geheue enige streek kan skryf en lees. Dié. glad nie.

Nadat ons met die MEinfo-hulpprogram (van Intel STK) gekontroleer het, het ons gesien dat die vervaardigingsmodus op hierdie stelsels nie gesluit was nie, daarom is die skyfiestel-versekerings (FPF's) in 'n onbepaalde toestand gelaat. Ja, Intel BG is nie in sulke gevalle geaktiveer of gedeaktiveer nie.

Ons praat oor die volgende stelsels (met betrekking tot Intel BG en wat later in die artikel beskryf sal word, ons sal praat oor stelsels met Haswell-verwerker mikroargitektuur en hoër):

alle Gigabyte-produkte;
alle MSI produkte;
21 Lenovo-skootrekenaarmodelle en 4 Lenovo-bedienermodelle.

Natuurlik het ons die vonds aan hierdie verkopers gerapporteer, sowel as aan Intel.

Voldoende reaksie het slegs gevolg van Lenovowat die probleem erken het en 'n pleister vrygestel.

Gigabyte Dit blyk dat hulle inligting oor die kwesbaarheid aanvaar het, maar geensins kommentaar gelewer het nie.

Kommunikasie met MSI heeltemal vasgeval op ons versoek om ons publieke PGP-sleutel te stuur (om vir hulle 'n geënkripteerde sekuriteitsadvies te stuur). Hulle het gesê dat hulle "'n hardeware vervaardiger is en nie PGP-sleutels vervaardig nie."

Maar meer tot die punt. Aangesien die lont in 'n ongedefinieerde toestand gelaat word, kan die gebruiker (of aanvaller) dit self programmeer (die moeilikste is vind Intel STK). Dit vereis die volgende stappe.

1. Begin in Windows OS (in die algemeen kan die stappe wat hieronder beskryf word ook onder Linux gedoen word, as jy 'n analoog van Intel STK vir die verlangde bedryfstelsel ontwikkel). Deur die MEinfo-nutsmiddel te gebruik, maak seker dat die versmeltings op hierdie stelsel nie geprogrammeer is nie.

2. Lees die inhoud van flitsgeheue met behulp van die Flash-programmeerinstrument.

3. Maak die leesbeeld oop met enige UEFI BIOS-redigeerinstrument, maak die nodige veranderinge (implementeer byvoorbeeld 'n rootkit), skep / wysig die bestaande KEYM- en IBBM-strukture in die ME-streek.

Die publieke deel van die RSA-sleutel word in die prentjie uitgelig, waarvan die hash in die skyfiestel-versmeltings geprogrammeer sal word saam met die res van die Intel BG-konfigurasie.

4. Gebruik die Flash Image Tool, bou 'n nuwe firmware-beeld (deur die Intel BG-konfigurasie op te stel).

5. Skryf 'n nuwe prent om te flits met behulp van die Flash Programming Tool, verifieer met MEinfo dat die ME-streek nou die Intel BG-konfigurasie bevat.

6. Gebruik die Flash Programming Tool om die vervaardigingsmodus te sluit.

7. Die stelsel sal herlaai, waarna jy met MEinfo kan verifieer dat die FPF's nou geprogrammeer is.

Hierdie aksies vir ewig aktiveer Intel BG op hierdie stelsel. Dit sal onmoontlik wees om die aksie ongedaan te maak, wat beteken:

slegs die eienaar van die private deel van die wortelsleutel (d.w.s. die een wat Intel BG geaktiveer het) sal die UEFI BIOS op hierdie stelsel kan opdateer;
as u die oorspronklike firmware na hierdie stelsel terugstuur, byvoorbeeld deur 'n programmeerder te gebruik, sal dit nie eers aanskakel nie ('n gevolg van toepassingsbeleid in die geval van 'n verifikasiefout);
om van so 'n UEFI BIOS ontslae te raak, moet jy die skyfiestel met geprogrammeerde FPF's vervang met 'n "skoon" een (d.w.s. hersoldeer die skyfiestel as jy toegang het tot 'n infrarooi soldeerstasie teen die prys van 'n motor, of vervang net die moederbord ).

Om te verstaan wat so 'n rootkit kan doen, moet jy evalueer wat dit moontlik maak om jou kode in 'n UEFI BIOS-omgewing uit te voer. Sê, in die mees bevoorregte modus van die verwerker - SMM. So 'n wortelstel kan die volgende eienskappe hê:

parallel met die bedryfstelsel uitgevoer word (jy kan verwerking konfigureer deur 'n SMI-onderbreking te genereer, wat deur 'n timer geaktiveer sal word);
het al die voordele om in SMM-modus te wees (volledige toegang tot die inhoud van RAM- en hardewarehulpbronne, geheimhouding van die bedryfstelsel);
Die rootkit-kode kan geïnkripteer en gedekripteer word wanneer dit in SMM-modus bekendgestel word. Enige data wat slegs in SMM-modus beskikbaar is, kan as 'n enkripsiesleutel gebruik word. Byvoorbeeld, 'n hash van 'n stel adresse in SMRAM. Om hierdie sleutel te kry, sal jy in die SMM moet klim. En dit kan op twee maniere gedoen word. Vind die RCE in die SMM-kode en ontgin dit, of voeg jou eie SMM-module by die BIOS, wat onmoontlik is, aangesien ons Boot Guard geaktiveer het.

Dus, hierdie kwesbaarheid laat 'n aanvaller toe om:

skep 'n verborge, onverwyderbare rootkit van onbekende doel in die stelsel;
voer jou kode uit op een van die skyfiestelkerne binne die Intel SoC, naamlik op die Intel ISH (kyk die prentjie van naderby).

Alhoewel die vermoëns van die Intel ISH-substelsel nog nie ondersoek is nie, blyk dit 'n interessante aanvalsvektor teen Intel ME te wees.

Bevindinge

Die studie het 'n tegniese beskrywing verskaf van hoe Intel Boot Guard-tegnologie werk. Minus 'n paar geheime in Intel se sekuriteit deur obscurity model.
'n Aanvalscenario word aangebied wat dit moontlik maak om 'n onverwyderbare rootkit in die stelsel te skep.
Ons het gesien dat moderne Intel-verwerkers in staat is om baie eie kode uit te voer selfs voordat die BIOS begin.
Platforms met Intel 64-argitektuur word al hoe minder geskik vir die gebruik van gratis sagteware: hardeware-verifikasie, 'n toenemende aantal eie tegnologieë en substelsels (drie kerne in die SoC-skyfiestel: x86 ME, x86 ISH en ARC PMC).

Versagtings

Verkopers wat die vervaardigingsmodus doelbewus oop laat, moet dit beslis toemaak. Tot dusver maak hulle net hul oë toe en die nuwe Kaby Lake-stelsels wys dit.

Gebruikers kan Intel BG op hul stelsels deaktiveer (wat deur die beskryfde kwesbaarheid geraak word) deur die Flash Programming Tool met die -closemnf opsie uit te voer. Eerstens moet jy seker maak (met MEinfo) dat die konfigurasie van Intel BG in die ME-streek voorsiening maak vir die presiese afskakeling van hierdie tegnologie na programmering in FPF's.

Bron: will.com

Schrödinger se betroubare stewel. Intel Boot Guard