🥇 Betrodd nedladdning av Schrödinger. Intel Boot Guard

Vi föreslår att gå ner till en låg nivå igen och prata om säkerheten för firmware för x86-kompatibla datorplattformar. Den här gången är huvudingrediensen i studien Intel Boot Guard (inte att förväxla med Intel BIOS Guard!) - en hårdvarustödd tillförlitlig BIOS-startteknik som datorsystemleverantören permanent kan aktivera eller inaktivera i produktionsskedet. Tja, forskningsreceptet är redan bekant för oss: skär implementeringen av denna teknik tunt med omvänd ingenjörskonst, beskriv dess arkitektur, fyll den med odokumenterade detaljer, krydda den med attackvektorer efter smak och blandning. Låt oss lägga bränsle till historien om hur en bugg som har klonats i flera år i produktionen av flera leverantörer tillåter en potentiell angripare att använda denna teknik för att skapa ett dolt rootkit i systemet som inte kan tas bort (även med en programmerare).

Artikeln är förresten baserad på rapporterna "On Guard of Rootkits: Intel BootGuard" från konferensen ZeroNights 2016 och 29:e mötet DefCon Ryssland (båda presentationerna här).

Firmware för en datorplattform med Intel 64-arkitektur

Låt oss först svara på frågan: vad är firmwaren för en modern datorplattform med Intel 64-arkitektur? Naturligtvis UEFI BIOS. Men ett sådant svar kommer inte att vara korrekt. Låt oss ta en titt på bilden, som visar skrivbordsversionen (bärbar dator) av denna arkitektur.

Grunden är länken:

Processor (CPU, Central Processing Unit), som förutom huvudkärnorna har en inbyggd grafikkärna (inte i alla modeller) och en minneskontroller (IMC, Integrated Memory Controller);
Chipset (PCH, Platform Controller Hub), som innehåller olika kontroller för att interagera med kringutrustning och hantera delsystem. Bland dem finns den välkända Intel Management Engine (ME), som också har firmware (Intel ME firmware).

Bärbara datorer, utöver ovanstående, kräver en inbyggd kontroller (ACPI EC, Advanced Control and Power Interface Embedded Controller), som är ansvarig för driften av strömundersystemet, pekplatta, tangentbord, Fn-tangenter (skärmens ljusstyrka, ljudvolym , tangentbordsbelysning, etc. ) och andra saker. Och den har också sin egen firmware.

Så, helheten av ovanstående firmware är den fasta programvaran för datorplattformen (systemfirmware), som lagras på ett gemensamt SPI-flashminne. För att användare av detta minne inte ska bli förvirrade över var det är, är innehållet i detta minne uppdelat i följande regioner (som visas i figuren):

UEFI BIOS;
ACPI EC firmware (en separat region dök upp med Skylake-processorns mikroarkitektur (2015), men i naturen har vi ännu inte sett några exempel på dess användning, så firmwaren för den inbyggda styrenheten ingår fortfarande i UEFI BIOS) ;
Intel ME firmware;
konfiguration (MAC-adress, etc.) av den inbyggda GbE-nätverksadaptern (Gigabit Ethernet);
Flash-beskrivningar är huvudregionen i flashminnet som innehåller pekare till andra regioner, samt behörigheter att komma åt dem.

SPI-bussmastern, en SPI-styrenhet inbyggd i chipsetet, genom vilken detta minne nås, ansvarar för att avgränsa åtkomst till regioner (i enlighet med de angivna behörigheterna). Om behörigheter är inställda på Intels rekommenderade (av säkerhetsskäl) värden, har varje SPI flash-användare full åtkomst (läs/skriv) endast till sin region. Och resten är antingen skrivskyddade eller otillgängliga. Ett välkänt faktum: på många system har processorn full tillgång till UEFI BIOS och GbE, läsbehörighet endast till flash-beskrivningar och ingen tillgång till Intel ME-regionen alls. Varför på många och inte på alla? Det som rekommenderas krävs inte. Vi kommer att berätta mer i detalj senare i artikeln.

Mekanismer för att skydda datorplattformens firmware från modifiering

Uppenbarligen bör den fasta programvaran på en datorplattform skyddas från möjliga kompromisser, vilket skulle tillåta en potentiell angripare att få fotfäste i den (överleva OS-uppdateringar/ominstallationer), exekvera sin kod i de mest privilegierade lägena, etc. Och att begränsa åtkomsten till SPI-flashminnesregioner är naturligtvis inte tillräckligt. Därför, för att skydda den fasta programvaran från modifieringar, används olika mekanismer som är specifika för varje driftsmiljö.

Således är Intel ME-firmware signerad för att kontrollera integritet och äkthet, och kontrolleras av ME-styrenheten varje gång den laddas in i ME UMA-minnet. Denna verifieringsprocess har redan diskuterats av oss i en av artiklar, tillägnad Intel ME-delsystemet.

Och ACPI EC-firmware kontrolleras som regel endast för integritet. Men på grund av det faktum att denna binär är inkluderad i UEFI BIOS, är den nästan alltid föremål för samma skyddsmekanismer som UEFI BIOS använder. Låt oss prata om dem.

Dessa mekanismer kan delas in i två kategorier.

Skrivskydd i UEFI BIOS-regionen

Fysiskt skydd av innehållet i SPI-flashminnet med en skrivskyddsbygel;
Skydda projektionen av UEFI BIOS-regionen i CPU-adressutrymmet med hjälp av PRx-kretsuppsättningsregister;
Blockera försök att skriva till UEFI BIOS-regionen genom att generera och bearbeta motsvarande SMI-avbrott genom att sätta BIOS_WE/BLE- och SMM_BWP-bitarna i chipsetregistren;
En mer avancerad version av detta skydd är Intel BIOS Guard (PFAT).

Utöver dessa mekanismer kan leverantörer utveckla och implementera sina egna säkerhetsåtgärder (till exempel signering av kapslar med UEFI BIOS-uppdateringar).

Det är viktigt att notera att på ett specifikt system (beroende på leverantör) kanske inte alla ovanstående skyddsmekanismer tillämpas, de kanske inte tillämpas alls, eller så kan de implementeras på ett sårbart sätt. Du kan läsa mer om dessa mekanismer och situationen med deras implementering i den här artikeln. För den som är intresserad rekommenderar vi att du läser hela serien av artiklar om UEFI BIOS-säkerhet från Coderush.

UEFI BIOS-autentisering

När vi pratar om pålitlig startteknik är det första som kommer att tänka på Secure Boot. Arkitektoniskt är det dock utformat för att verifiera äktheten av komponenter utanför UEFI BIOS (drivrutiner, bootloaders, etc.), och inte själva firmware.

Därför implementerade Intel, i SoCs med Bay Trail-mikroarkitektur (2012), en hårdvaruinaktiverad Secure Boot (Verified Boot), som inte har något gemensamt med den ovan nämnda Secure Boot-tekniken. Senare (2013) förbättrades denna mekanism och släpptes under namnet Intel Boot Guard för stationära datorer med Haswell-mikroarkitektur.

Innan vi beskriver Intel Boot Guard, låt oss titta på exekveringsmiljöerna i Intel 64-arkitekturen, som i kombination är rötterna till förtroende för denna pålitliga startteknik.

Intel CPU

Cap antyder att processorn är den huvudsakliga exekveringsmiljön i arkitekturen Intel 64. Varför är det roten till förtroende? Det visar sig att det som gör honom sådan är innehavet av följande element:

Microcode ROM är ett icke-flyktigt, icke-omskrivbart minne för lagring av mikrokod. Det antas att mikrokod är implementeringen av processorns kommandosystem med de enklaste instruktionerna. Händer i mikrokod också buggar. Så i BIOS kan du hitta binärfiler med mikrokoduppdateringar (överlagras under uppstart, eftersom ROM inte kan skrivas över). Innehållet i dessa binärer är krypterade, vilket i hög grad komplicerar analysen (därför är det specifika innehållet i mikrokoden endast känt för dem som utvecklar den), och signeras för att kontrollera integritet och äkthet;
AES-nyckel för att dekryptera innehållet i mikrokoduppdateringar;
hash för den publika RSA-nyckeln som används för att verifiera signaturen för mikrokoduppdateringar;
RSA public key hash, som verifierar signaturen för Intel-utvecklade ACM (Authenticated Code Module) kodmoduler, som processorn kan starta innan BIOS körning (hej mikrokod) eller under dess drift, när vissa händelser inträffar.

Intel ME

Vår blogg var tillägnad detta delsystem två Artikel. Låt oss komma ihåg att denna körbara miljö är baserad på en mikrokontroller inbyggd i chipsetet och är den mest dolda och privilegierade i systemet.

Trots sitt hemlighetsmakeri är Intel ME också en rot av förtroende eftersom det har:

ME ROM - icke-flyktigt, icke-omskrivbart minne (ingen uppdateringsmetod tillhandahålls) som innehåller startkoden, såväl som SHA256-hash för den publika RSA-nyckeln, som verifierar signaturen för Intel ME-firmware;
AES-nyckel för att lagra hemlig information;
tillgång till en uppsättning säkringar (FPF:er, fältprogrammerbara säkringar) integrerade i styrkretsen för permanent lagring av viss information, inklusive den som specificeras av datorsystemleverantören.

Intel Boot Guard 1.x

En liten ansvarsfriskrivning. Intel Boot Guard-teknikens versionsnummer som vi använder i den här artikeln är godtyckliga och kanske inte har något att göra med numreringen som används i Intels interna dokumentation. Dessutom erhölls informationen som tillhandahålls här om implementeringen av den här tekniken under reverse engineering och kan innehålla felaktigheter jämfört med specifikationen för Intel Boot Guard, som sannolikt inte kommer att publiceras någonsin.

Så, Intel Boot Guard (BG) är en maskinvarustödd UEFI BIOS-autentiseringsteknik. Att döma av dess korta beskrivning i boken [Platform Embedded Security Technology Revealed, kapitel Boot with Integrity, or Not Boot], fungerar den som en pålitlig startkedja. Och den första länken i den är startkoden (mikrokoden) inuti CPU:n, som utlöses av RESET-händelsen (inte att förväxla med RESET-vektorn i BIOS!). CPU:n hittar en kodmodul utvecklad och signerad av Intel (Intel BG startup ACM) på SPI-flashminnet, laddar den i sin cache, verifierar (det noterades redan ovan att CPU:n har en hash av den publika nyckeln som verifierar ACM:n signatur) och startar.

Denna kodmodul ansvarar för att verifiera en liten startdel av UEFI BIOS - Initial Boot Block (IBB), som i sin tur innehåller funktionalitet för att verifiera huvuddelen av UEFI BIOS. Således låter Intel BG dig verifiera äktheten av BIOS innan du laddar operativsystemet (vilket kan utföras under övervakning av Secure Boot-tekniken).

Intel BG-teknik tillhandahåller två driftslägen (och det ena stör inte det andra, dvs. båda lägena kan aktiveras på systemet eller båda kan inaktiveras).

Uppmätt stövel

I läget Measured Boot (MB) "mäter" varje startkomponent (som börjar med CPU-start-ROM) nästa med funktionerna i TPM (Trusted Platform Module). För de som inte vet, låt mig förklara.

TPM har PCR (Platform Configuration Registers), i vilka resultatet av hashoperationen skrivs in enligt formeln:

De där. det aktuella PCR-värdet beror på det föregående, och dessa register återställs endast när systemet är RESET.

Sålunda, i MB-läge, vid någon tidpunkt, återspeglar PCR:er en unik (inom kapaciteten för hashoperationen) identifierare för koden eller data som "mättes". PCR-värden kan användas i vissa datakryptering (TPM_Seal) operationer. Efter detta kommer deras dekryptering (TPM_Unseal) endast att vara möjlig om PCR-värdena inte ändrades som ett resultat av laddningen (dvs. inte en enda "uppmätt" komponent modifierades).

Verifierad start

Det värsta för dem som gillar att modifiera UEFI BIOS är läget Verified Boot (VB), där varje startkomponent kryptografiskt verifierar integriteten och äktheten hos nästa. Och i händelse av ett verifieringsfel händer (ett av):

avstängning med timeout från 1 minut till 30 minuter (så att användaren har tid att förstå varför hans dator inte startar och, om möjligt, försöker återställa BIOS);
omedelbar avstängning (så att användaren inte har tid att förstå, än mindre göra, någonting);
fortsätta arbeta med ett lugnt uttryck (det fallet när det inte finns tid för säkerhet, för det finns viktigare saker att göra).

Valet av åtgärd beror på den specificerade Intel BG-konfigurationen (nämligen på den så kallade enforcement policy), som registreras permanent av datorplattformsleverantören i en specialdesignad lagring - chipset säkringar (FPF). Vi kommer att uppehålla oss vid denna punkt mer i detalj senare.

Utöver konfigurationen genererar leverantören två RSA 2048-nycklar och skapar två datastrukturer (visas i figuren):

Säljarens rotnyckelmanifest (KEYM, OEM Root Key Manifest), som innehåller SVN (Security Version Number) för detta manifest, SHA256-hash för den publika nyckeln för nästa manifest, den offentliga RSA-nyckeln (dvs. den offentliga delen av leverantörens rotnyckel) för att verifiera signaturen för detta manifest och signaturen själv;
IBB Manifest (IBBM, Initial Boot Block Manifest), som innehåller SVN för detta manifest, SHA256-hash från IBB, den publika nyckeln för att verifiera signaturen för detta manifest och signaturen i sig.

SHA256-hash för den offentliga OEM Root Key-nyckeln registreras permanent i chipset-säkringar (FPF), precis som Intel BG-konfigurationen. Om Intel BG-konfigurationen tillåter inkludering av denna teknik, kan från och med nu endast ägaren av den privata delen av OEM Root Key uppdatera BIOS på detta system (dvs. kunna räkna om dessa manifest), dvs. Säljare.

När man tittar på bilden uppstår omedelbart tvivel om behovet av en så lång verifieringskedja - de kunde ha använt ett manifest. Varför komplicera saker och ting?

I själva verket ger Intel således leverantören möjlighet att använda olika IBB-nycklar för olika linjer av sina produkter och en som rotnyckel. Om den privata delen av IBB-nyckeln (med vilken det andra manifestet är signerat) läcker kommer incidenten endast att påverka en produktlinje och endast tills leverantören genererar ett nytt par och inkluderar de omräknade manifesten i nästa BIOS-uppdatering.

Men om rotnyckeln (med vilken det första manifestet är signerat) äventyras kommer det inte att vara möjligt att ersätta den, det finns ingen återkallelseprocedur. hashen för den offentliga delen av denna nyckel programmeras in i FPF en gång för alla.

Intel Boot Guard-konfiguration

Låt oss nu titta närmare på Intel BG-konfigurationen och processen för att skapa den. Om du tittar på motsvarande flik i GUI för Flash Image Tool-verktyget från Intel System Tool Kit (STK), kommer du att märka att Intel BG-konfigurationen inkluderar en hash av den offentliga delen av leverantörens rotnyckel, ett par oklara värden osv. Intel BG-profil.

Strukturen för denna profil:

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

Generellt sett är Intel BG-konfigurationen en mycket flexibel enhet. Tänk till exempel Force_Boot_Guard_ACM-flaggan. När den tas bort, om BG startup ACM-modulen på SPI-blixten inte hittas, kommer ingen betrodd uppstart att ske. Hon kommer att vara obetrodd.

Vi skrev redan ovan att tillämpningspolicyn för VB-läge kan konfigureras så att om det finns ett verifieringsfel kommer en otillförlitlig nedladdning att ske.

Lämna sådana saker efter försäljarnas gottfinnande...

GUI-verktyget tillhandahåller följande "färdiga" profiler:

Nej.
regim
beskrivning

0
Nej_FVME
Intel BG-teknik inaktiverad

1
VE
VB-läge är aktiverat, avstängning efter timeout

2
VME
båda lägena är aktiverade (VB och MB), avstängning efter timeout

3
VM
båda lägena är aktiverade, utan att stänga av systemet

4
FVE
VB-läge aktiverat, omedelbar avstängning

5
FVME
båda lägena aktiverade, omedelbar avstängning

Som redan nämnts måste Intel BG-konfigurationen skrivas en gång för alla av systemleverantören i chipset-säkringar (FPF) - en liten (enligt overifierad information, endast 256 byte) hårdvarulagring av information inuti chipsetet, som kan programmeras utanför Intels produktionsanläggningar (det är just därför Fältprogrammerbar Säkringar).

Det är bra för att lagra konfiguration eftersom:

har ett engångsprogrammerbart område för lagring av data (exakt där Intel BG-konfigurationen är skriven);
Endast Intel ME kan läsa och programmera den.

Så, för att ställa in konfigurationen för Intel BG-teknik på ett specifikt system, gör leverantören följande under produktionen:

Med hjälp av verktyget Flash Image Tool (från Intel STK) skapas en firmwarebild med en given Intel BG-konfiguration i form av variabler inom Intel ME-regionen (den så kallade temporära spegeln för FPFs);
Med hjälp av verktyget Flash Programming Tool (från Intel STK) skriver den denna bild till systemets SPI-flashminne och stänger den så kallade. tillverkningsläge (i detta fall skickas motsvarande kommando till Intel ME).

Som ett resultat av dessa operationer kommer Intel ME att överföra de angivna värdena från spegeln för FPFs i ME-regionen till FPFs, ställa in upplösningarna i SPI-blixtbeskrivningar till de värden som rekommenderas av Intel (beskrivna i början av artikel) och utför en systemåterställning.

Analys av implementeringen av Intel Boot Guard

För att analysera implementeringen av denna teknik med hjälp av ett specifikt exempel, kontrollerade vi följande system för spår av Intel BG-teknik:

System
Notera

Gigabyte GA-H170-D3H
Skylake, det finns stöd

Gigabyte GA-Q170-D3H
Skylake, det finns stöd

Gigabyte GA-B150-HD3
Skylake, det finns stöd

MSI H170A Gaming Pro
Skylake, inget stöd

Lenovo ThinkPad 460
Skylake, stöds, teknik aktiverad

Lenovo Yoga 2 Pro
Haswell, inget stöd

Lenovo U330p
Haswell, inget stöd

Med "support" menar vi närvaron av Intel BG startup ACM-modulen, manifesten som nämns ovan och motsvarande kod i BIOS, d.v.s. implementering för analys.

Som ett exempel, låt oss ta den som laddats ner från kontoret. leverantörens webbplatsbild av SPI-flashminne för Gigabyte GA-H170-D3H (version F4).

Intel CPU-start-ROM

Först och främst, låt oss prata om processorns åtgärder om Intel BG-tekniken är aktiverad.

Det var inte möjligt att hitta exempel på dekrypterad mikrokod, så hur de åtgärder som beskrivs nedan implementeras (i mikrokod eller hårdvara) är en öppen fråga. Det är dock ett faktum att moderna Intel-processorer "kan" utföra dessa åtgärder.

Efter att ha lämnat RESET-tillståndet hittar processorn (innehållet i flashminnet har redan mappats till adressutrymmet) tabellen FIT (Firmware Interface Table). Det är lätt att hitta; pekaren till det är skrivet på adressen FFFF FFC0h.

I det aktuella exemplet finns värdet FFD6 9500h på denna adress. Genom att komma åt denna adress ser processorn FIT-tabellen, vars innehåll är uppdelat i poster. Den första posten är rubriken för följande struktur:

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

Av någon okänd anledning beräknas inte alltid kontrollsumman i dessa tabeller (fältet lämnas noll).

De återstående posterna pekar på olika binärer som behöver tolkas/exekveras innan BIOS exekveras, d.v.s. innan du växlar till den äldre RESET-vektorn (FFFF FFF0h). Strukturen för varje sådan post är som följer:

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

Fältet EntryType talar om vilken typ av block som denna post pekar på. Vi känner till flera typer:

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

Nu är det uppenbart att en av posterna pekar på platsen för Intel BG-start ACM-binären. Rubrikstrukturen för denna binär är typisk för kodmoduler utvecklade av Intel (ACM, mikrokoduppdateringar, Intel ME-kodsektioner, ...).

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

Processorn laddar denna binära fil i sin cache, verifierar den och kör den.

Intel BG start ACM

Som ett resultat av analysen av denna ACM:s arbete blev det klart att den gör följande:

tar emot Intel BG-konfigurationen från Intel ME, inskriven i chipset-säkringar (FPFs);
hittar KEYM och IBBM manifesterar och verifierar dem.

För att hitta dessa manifest använder ACM även FIT-tabellen, som har två inmatningstyper för att indikera strukturdata (se FIT_ENTRY_TYPES ovan).

Låt oss ta en närmare titt på manifest. I strukturen för det första manifestet ser vi flera obskyra konstanter, en hash av den publika nyckeln från det andra manifestet och den offentliga OEM Root Key signerad som en kapslad struktur:

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

För att verifiera OEM Root Key offentliga nyckel minns vi att vi använder SHA256 hash av säkringar, som vid denna tidpunkt redan har tagits emot från Intel ME.

Låt oss gå vidare till det andra manifestet. Den består av tre strukturer:

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

Den första innehåller några konstanter:

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

Den andra innehåller SHA256-hash för IBB och antalet deskriptorer som beskriver innehållet i IBB (dvs vad hashen beräknas från):

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-deskriptorerna följer denna struktur, den ena efter den andra. Deras innehåll har följande format:

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

Det är enkelt: varje deskriptor innehåller adressen/storleken på IBB-biten. Sålunda är sammanlänkningen av blocken som pekas på av dessa deskriptorer (i ordningen för deskriptorerna själva) IBB. Och som regel är IBB samlingen av alla moduler i SEC- och PEI-faserna.

Det andra manifestet kompletteras av en struktur som innehåller IBB:s publika nyckel (verifierad av SHA256-hash från det första manifestet) och signaturen för detta manifest:

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

Så även innan UEFI BIOS börjar köras kommer processorn att starta ACM, som kommer att verifiera äktheten av innehållet i avsnitten med SEC- och PEI-faskoden. Därefter avslutar processorn ACM, följer RESET-vektorn och börjar köra BIOS.

Den verifierade PEI-partitionen måste innehålla en modul som kontrollerar resten av BIOS (DXE-kod). Denna modul utvecklas redan av IBV (Independent BIOS Vendor) eller systemleverantören själv. Därför att Endast Lenovo- och Gigabyte-system stod till vårt förfogande och hade Intel BG-stöd; låt oss titta på koden som extraherats från dessa system.

UEFI BIOS-modul LenovoVerifiedBootPei

När det gäller Lenovo visade det sig vara LenovoVerifiedBootPei-modulen {B9F2AC77-54C7-4075-B42E-C36325A9468D}, utvecklad av Lenovo.

Dess uppgift är att slå upp (genom GUID) hashtabellen för DXE och verifiera 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-modul BootGuardPei

När det gäller Gigabyte visade det sig vara BootGuardPei-modulen {B41956E1-7CA2-42DB-9562-168389F0F066}, utvecklad av AMI, och finns därför i alla AMI BIOS med Intel BG-stöd.

Dess operativa algoritm är något annorlunda, men det kokar ner till samma sak:

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

Hashtabellen {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} den letar efter har följande format:

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

Låt oss kort prata om en annan implementering av Intel Boot Guard, som hittades i ett nyare system baserat på Intel SoC med Apollo Lake mikroarkitektur - ASRock J4205-IT.

Även om den här versionen endast kommer att användas i SoCs (nya system med Kaby Lake-processormikroarkitektur fortsätter att använda Intel Boot Guard 1.x), är det av stort intresse att studera det nya arkitekturalternativet för Intel SoC-plattformar, som har sett betydande förändringar, till exempel:

BIOS- och Intel ME-regionerna (eller snarare Intel TXE, enligt terminologin för Intel SoC) är nu en IFWI-region;
även om Intel BG var aktiverat på plattformen, hittades inte strukturer som FIT, KEYM, IBBM i flashminnet;
förutom TXE- och ISH-kärnorna (x86) lades en tredje kärna till chipsetet (ARC igen, förresten) - PMC (Power Management Controller), förknippad med att säkerställa driften av kraftundersystemet och prestandaövervakning.

Innehållet i den nya IFWI-regionen är en uppsättning av följande moduler:

förskjutning
namn
beskrivning

0000 2000h
SMIP
en viss plattformskonfiguration, signerad av leverantören

0000 6000h
RBEP
Intel TXE firmware-kodsektion, x86, signerad Intel

0001 0000h
PMCP
Intel PMC firmware-kodsektion, ARC, signerad Intel

0002 0000h
FTPR
Intel TXE firmware-kodsektion, x86, signerad Intel

0007 B000h
UCOD
mikrokoduppdateringar för CPU, signerade av Intel

0008 0000h
IBBP
UEFI BIOS, SEC/PEI phases, x86, signerad av leverantören

0021 8000h
ISHC
Intel ISH firmware-kodsektion, x86, signerad av leverantören

0025 8000h
NFTP
Intel TXE firmware-kodsektion, x86, signerad Intel

0036 1000h
IUNP
okänt

0038 1000h
OBBP
UEFI BIOS, DXE phase, x86, osignerad

Under analysen av TXE-firmwaren blev det uppenbart att efter en RESET håller TXE processorn i detta tillstånd tills den förbereder det grundläggande innehållet i adressutrymmet för CPU:n (FIT, ACM, RESET-vektor ...). Dessutom placerar TXE denna data i sitt SRAM, varefter den tillfälligt ger processorn åtkomst dit och "släpper" den från RESET.

På vakt mot rootkits

Nåväl, låt oss nu gå vidare till de "heta" sakerna. Vi upptäckte en gång att på många system innehåller SPI-flash-deskriptorer behörigheter att komma åt regioner i SPI-flashminnet så att alla användare av detta minne kan skriva och läsa vilken region som helst. De där. aldrig.

Efter att ha kontrollerat med MEinfo-verktyget (från Intel STK) såg vi att tillverkningsläget på dessa system inte är stängt, därför lämnas chipset-säkringarna (FPF) i ett odefinierat tillstånd. Ja, Intel BG är varken på eller av i sådana fall.

Vi pratar om följande system (med avseende på Intel BG och vad som kommer att beskrivas senare i artikeln kommer vi att prata om system med Haswell-processormikroarkitektur och högre):

alla Gigabyte-produkter;
alla MSI-produkter;
21 modeller av Lenovo bärbara datorer och 4 modeller av Lenovo-servrar.

Naturligtvis rapporterade vi upptäckten till dessa leverantörer, såväl som till Intel.

En adekvat reaktion kom bara från lenovosom kände igen problemet och släppt en patch.

Gigabyte De verkade acceptera informationen om sårbarheten, men kommenterade inte på något sätt.

Kommunikation med MSI stannade helt på vår begäran om att skicka din offentliga PGP-nyckel (för att skicka dem en säkerhetsrådgivning i krypterad form). De uppgav att de "är en hårdvarutillverkare och inte producerar PGP-nycklar."

Men låt oss komma till saken. Eftersom säkringarna lämnas i ett ospecificerat tillstånd kan användaren (eller angriparen) programmera dem oberoende (det svåraste är hitta Intel STK). För att göra detta måste du slutföra följande steg.

1. Starta upp i Windows OS (i allmänhet kan åtgärderna som beskrivs nedan också göras under Linux, om du utvecklar en analog av Intel STK för önskat operativsystem). Med hjälp av MEinfo-verktyget, se till att säkringar inte är programmerade på detta system.

2. Läs innehållet i flashminnet med hjälp av Flash-programmeringsverktyget.

3. Öppna den lästa bilden med valfritt UEFI BIOS-redigeringsverktyg, gör nödvändiga ändringar (inför till exempel ett rootkit), skapa/redigera befintliga KEYM- och IBBM-strukturer i ME-regionen.

Bilden framhäver den offentliga delen av RSA-nyckeln, vars hash kommer att programmeras in i chipset-säkringarna tillsammans med resten av Intel BG-konfigurationen.

4. Använd Flash Image Tool, skapa en ny firmware-avbildning (genom att ställa in Intel BG-konfigurationen).

5. Skriv en ny bild till flashminnet med hjälp av Flash-programmeringsverktyget och verifiera med MEinfo att ME-regionen nu innehåller Intel BG-konfigurationen.

6. Använd Flash-programmeringsverktyget för att stänga tillverkningsläget.

7. Systemet kommer att starta om, varefter du kan använda MEinfo för att verifiera att FPF:erna nu är programmerade.

Dessa åtgärder evigt aktivera Intel BG på detta system. Åtgärden kan inte ångras, vilket betyder:

Endast ägaren av den privata delen av rotnyckeln (d.v.s. den som aktiverade Intel BG) kommer att kunna uppdatera UEFI BIOS på detta system;
om du returnerar den ursprungliga firmware till det här systemet, till exempel med hjälp av en programmerare, kommer den inte ens att slås på (en konsekvens av tillämpningspolicyn i händelse av ett verifieringsfel);
för att bli av med en sådan UEFI BIOS måste du byta ut chipsetet med programmerade FPF:er med en "ren" (dvs. löda om chipsetet om du har tillgång till en infraröd lödstation till priset för en bil, eller helt enkelt byta ut moderkortet ).

För att förstå vad ett sådant rootkit kan göra måste du utvärdera vad som gör det möjligt att exekvera din kod i UEFI BIOS-miljön. Låt oss säga, i det mest privilegierade processorläget - SMM. Ett sådant rootkit kan ha följande egenskaper:

exekveras parallellt med operativsystemet (du kan konfigurera bearbetning för att generera ett SMI-avbrott, som kommer att triggas av en timer);
har alla fördelar med att vara i SMM-läge (full tillgång till innehållet i RAM- och hårdvaruresurser, sekretess från OS);
Rootkittets programkod kan krypteras och dekrypteras när den startas i SMM-läge. All data som endast är tillgänglig i SMM-läge kan användas som en krypteringsnyckel. Till exempel en hash från en uppsättning adresser i SMRAM. För att få den här nyckeln måste du komma in i SMM. Och detta kan göras på två sätt. Hitta RCE i SMM-koden och utnyttja den, eller lägg till din egen SMM-modul i BIOS, vilket är omöjligt eftersom vi aktiverade Boot Guard.

Således tillåter denna sårbarhet en angripare att:

skapa ett dolt, outletbart rootkit av okänt syfte i systemet;
exekvera din kod på en av chipset-kärnorna inuti Intel SoC, nämligen på Intel ISH (ta en noggrann titt på bilden).

Även om funktionerna hos Intel ISH-delsystemet ännu inte har utforskats, verkar det vara en intressant attackvektor för Intel ME.

Resultat

Studien gjorde det möjligt att få en teknisk beskrivning av hur Intel Boot Guard-tekniken fungerar. Minus ett par hemligheter i Intels säkerhet genom obscurity-modell.
Ett attackscenario presenteras som låter dig skapa ett avinstallerbart rootkit i systemet.
Vi såg att moderna Intel-processorer kan exekvera mycket egen kod redan innan BIOS börjar köra.
Plattformar med Intel 64-arkitektur blir allt mindre lämpliga för att köra fri programvara: hårdvaruverifiering, ett ökande antal proprietära teknologier och delsystem (tre kärnor i SoC-kretsuppsättningen: x86 ME, x86 ISH och ARC PMC).

Lättnader

Leverantörer som avsiktligt lämnar tillverkningsläget öppet bör se till att stänga det. Än så länge är bara deras ögon stängda, och det visar de nya Kaby Lake-systemen.

Användare kan inaktivera Intel BG på sina system (som är mottagliga för den beskrivna sårbarheten) genom att köra Flash-programmeringsverktyget med parametern -closemnf. Först bör du se till (med MEinfo) att Intel BG-konfigurationen i ME-regionen ger möjlighet att stänga av denna teknik efter programmering i FPF.

Källa: will.com

Schrödingers betrodda nedladdning. Intel Boot Guard