Betrodd uppladdning av Schrödinger. Intel Boot Guard

Vi erbjuder att återigen dyka ner på en låg nivå och diskutera säkerheten för x86-kompatibla datorplattformars firmware. Denna gång är huvudingredienserna i undersökningen Intel Boot Guard (inte att förväxla med Intel BIOS Guard!) – en hårdvaruunderstödd teknik för betrodd BIOS-booting, som datorleverantören kan permanent aktivera eller inaktivera i tillverkningsskedet. Det bekanta receptet för undersökningen är att noggrant skiva med reverse engineering implementationen av denna teknik, beskriva dess arkitektur och fylla den med odocumenterade detaljer, samt krydda den med attackvektorer. Låt oss tända till med berättelsen om hur en felaktighet i produktionen som har klonats under många år tillåter en potentiell angripare att använda denna teknik för att skapa en osynlig (även för programmeraren) rootkit i systemet.

Förresten, grundvalen för artikeln är rapporter från "Vid rutkitens försvar: Intel BootGuard" från konferensen ZeroNights 2016 och det 29:e mötet DefCon Russia (båda presentationerna här).

Firmware för datorplattformar med Intel 64-arkitektur

För att börja med ska vi besvara frågan: vad utgör firmware för moderna datorplattformar med Intel 64-arkitektur? Självklart är svaret UEFI BIOS. Men det svaret skulle inte vara helt korrekt. Låt oss ta en titt på bilden, där en desktop- (eller laptop-)version av denna arkitektur visas.

Grunden är en kombination av:

• Processorn (CPU, Central Processing Unit), som, förutom huvudkärnorna, har en inbyggd grafikkärna (inte i alla modeller) och en inbyggd minneskontroller (IMC, Integrated Memory Controller);
• Chipsatsen (PCH, Platform Controller Hub), som innehåller olika kontroller för interaktion med perifera enheter och för att hantera subsystem. Bland dessa finns den inte så okända Intel Management Engine (ME), som också har firmware (Intel ME firmware).

Bärbara datorer, utöver ovanstående, förutsätter även att det finns en inbyggd kontroller (ACPI EC, Advanced Control and Power Interface Embedded Controller), som ansvarar för funktionen av strömhanteringssystemet, pekplattan, tangentbordet, Fn-tangenterna (skärmens ljusstyrka, ljudvolym, tangentbordsbelysning osv.) och mer. Och den har också sin egen firmware.

Så, sammanställningen av de ovan nämnda firmware är firmware för dataplattformen (system firmware), som lagras i gemensam SPI-flashminne. För att användarna av detta minne inte ska blanda ihop vad som tillhör vem, är innehållet i detta minne uppdelat i följande regioner (som visas i bilden):

• UEFI BIOS;
• firmware för ACPI EC (en separat region introducerades med processormikroarkitekturen Skylake (2015), men i verkliga användningsfall har vi hittills inte sett exempel på dess användning, så firmware för den inbyggda kontrolleraren ingår fortfarande i UEFI BIOS);
• firmware för Intel ME;
• konfiguration (MAC-adress osv.) för den inbyggda nätverksadaptern GbE (Gigabit Ethernet);
• Flash-beskrivare (Flash Descriptors) – den huvudsakliga regionen i flashminnet som innehåller pekare till de andra regionerna, samt åtkomstbehörigheter till dem.

Åtkomstbegränsningen till regionerna (enligt angivna behörigheter) hanteras av huvudkontrollenheten för SPI-bussen – en inbyggd SPI-kontroller i chipsetet, genom vilken åtkomsten till detta minne sker. Om behörigheterna är inställda på de rekommenderade (av säkerhetsskäl) värdena av Intel, har varje användare av SPI-flashminnet fullständig åtkomst (läsning/skrivning) endast till sin region. De andra – är antingen endast läsbara eller helt otillgängliga. En välkänd fakta: i många system har CPU:n fullständig åtkomst till UEFI BIOS och GbE, läsåtkomst till flash-beskrivarna, och det finns ingen åtkomst till regionen Intel ME. Varför i många fall, men inte alla? Vad som rekommenderas är inte nödvändigtvis obligatoriskt. Vi berättar mer om detta senare i artikeln.

Skyddsmekanismer för firmware för dataplattformen mot modifiering

Det är uppenbart att firmware för dataplattformen måste skyddas mot potentiell kompromiss som skulle möjliggöra en potentiell angripare att få fotfäste i den (överleva uppdateringar/installeringar av operativsystem), köra sin kod i de mest privilegierade lägena, etc. Och att begränsa åtkomst till regionerna i SPI-flashminnet är självklart inte tillräckligt. Därför används olika mekanismer, specifika för varje körningsmiljö, för att skydda firmware mot modifieringar.

Så, firmware för Intel ME är signerad för att säkerställa integritet och autenticitet, och kontrolleras av ME-kontrolleraren vid varje laddning i ME UMA-minnet. Denna verifieringsprocess har redan diskuterats av oss i en av artiklar, som handlar om Intel ME-systemet.

Firmware för ACPI EC kontrolleras vanligtvis bara för integritet. Men eftersom denna binärfil ingår i UEFI BIOS omfattas den nästan alltid av samma skyddsmekanismer som används av UEFI BIOS. Låt oss prata om dem.

Dessa mekanismer kan delas in i två kategorier.

Skrivskydd av UEFI BIOS-regionen

1. Fysisk skydd av SPI-flashminnets innehåll med en write-protect jumper;
2. Skydd av UEFI BIOS-regionens projektionsadress i CPU:s minnesutrymme med hjälp av PRx-register i chipsetet;
3. Blockering av skrivförsök i UEFI BIOS-regionen genom att generera och hantera en motsvarande SMI-avbrott genom att ställa in bios_WE/BLE och SMM_BWP-bitar i chipsetets register;
4. Ett mer avancerat alternativ till detta skydd är Intel BIOS Guard (PFAT).

Utöver dessa mekanismer kan leverantörerna utveckla och implementera 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ören) kanske inte alla ovanstående skyddsmekanismer tillämpas, kanske helt inte tillämpas, eller kanske är sårbart implementerade. Mer om dessa mekanismer och deras implementation kan läsas i denna artikel. För den intresserade rekommenderar vi att läsa hela artikelserien om säkerheten hos UEFI BIOS från CodeRush.

Verifiering av UEFI BIOS-autenticitet

När vi pratar om teknologier för pålitlig uppstart är det första som kommer i åtanke Secure Boot. Men arkitektoniskt är det avsett för att verifiera autentiteten hos externa komponenter relativt UEFI BIOS (drivrutiner, boot loaders etc.), inte själva firmware.

Därför införde Intel i SoC:er med Bay Trail-mikroarkitektur (2012) en hårdvaru-icke-avstängningsbar Secure Boot (Verified Boot), som inte har något att göra med den tidigare nämnda Secure Boot-teknologin. 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 samtidigt är grundläggande för denna teknik för pålitlig uppstart.

Intel CPU

Käppe säger att processorn är den primära exekveringsmiljön i Intel 64-arkitekturen. Varför är den också grundstenen? Det visar sig att detta är fallet på grund av att den har följande element:

• Mikrokod ROM — icke-flyktig, icke-överskrivbar minne för lagring av mikrokod. Man anser att mikrokod är implementeringen av processorns instruktionsuppsättning på grundläggande instruktioner. Det kan också uppstå buggar. Så i BIOS kan man hitta binärer med uppdateringar av mikrokod (de tillämpas under uppstart, eftersom ROM inte kan överskrivas). Innehållet i dessa binärer är krypterat, vilket betydligt komplicerar analysen (därför är det specifika innehållet i mikrokoden känt endast av dem som utvecklar det), och signerat för integritets- och äkthetskontroll;
• AES nyckel för avkryptering av innehållet i mikrokodsuppdateringarna;
• hash av RSA offentliga nyckeln, som används för att verifiera signaturen av mikrokodsuppdateringar;
• hash av RSA offentliga nyckeln, som används för att verifiera signaturen av de av företaget Intel utvecklade kodmodulerna ACM (Authenticated Code Module), som CPU kan köra innan BIOS exekvering (hejdå mikrokod) eller under dess drift, vid uppkomsten av vissa händelser.

Intel ME

Denna subsystem har varit dedikerad i vår blogg i hela två artiklar. Låt oss påminna om att denna körbara miljö är baserad på en mikrocontroller inbäddad i chipsettet och är den mest dolda och privilegierade i systemet.

Trots sin dolda natur är Intel ME också en förtroendebas, eftersom den har:

• ME ROM — icke-flyktig, icke-överskrivbar minne (det finns ingen möjlighet till uppdatering), som innehåller startkod samt en SHA256 hash av RSA offentliga nyckeln, som används för att verifiera signaturen av Intel ME-firmware;
• AES nyckel för lagring av hemlig information;
• åtkomst till den inbäddade chipsets uppsättning av fusions (FPFs, Field Programmable Fuses) för permanent lagring av viss information, inklusive den som anges av datorleverantören.

Intel Boot Guard 1.x

En liten avskylning. Versionsnumren för Intel Boot Guard-teknologin som vi hanterar i denna artikel är konditionella och kanske inte har något att göra med numreringen som används i Interna dokumentationen hos Intel. Dessutom har informationen här om implementeringen av denna teknologi erhållits genom omvänd teknik och kan innehålla oegentligheter jämfört med specifikationen för Intel Boot Guard, som knappast någonsin kommer att publiceras.

Så, Intel Boot Guard (BG) är en hårdvarustödd teknik för autentisering av UEFI BIOS. Enligt dess korta beskrivning i boken [Platform Embedded Security Technology Revealed, kapitel Boot with Integrity, or Not Boot], fungerar den som en kedja av betrodd bootning. Det första ledet i denna kedja är bootkoden (mikrokoden) inuti CPU:n, som aktiveras vid RESET (inte att förväxla med RESET-vektorn i BIOS!). CPU:n hittar en utvecklad och signerad kodmodul (Intel BG startup ACM) i SPI-flashminnet, laddar ner den till sin cache, verifierar (det har tidigare nämnts att CPU:n har en hash av den offentliga nyckeln som används för att kontrollera signaturen på ACM) 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. På så sätt gör Intel BG det möjligt att säkerställa BIOS:s äkthet innan operativsystemet laddas (som kan köras under övervakning av teknologin Secure Boot).

Intel BG-teknologin har två driftslägen (och det ena stör inte det andra, det vill säga att båda lägena kan vara aktiverade i systemet, eller båda kan vara avstängda).

Measured Boot

I läget Measured Boot (MB) "mäter" varje bootkomponent (från och med CPU boot ROM) den nästa, med hjälp av TPM (Trusted Platform Module). För de som inte är bekanta med detta, låt oss förklara.

TPM har PCR:er (Platform Configuration Registers), där resultatet av hashoperationen skrivs in enligt formeln:

Det vill säga det aktuella värdet på PCR beror på det föregående, medan dessa register endast återställs vid systemets RESET.

Således reflekterar PCR:erna i läget MB vid en viss tidpunkt en unik (inom ramen för hashoperationens möjligheter) identifierare av den kod eller data som har "mätts". Värdena på PCR kan användas vid kryptering av vissa data (TPM_Seal). Efter detta kan deras avkryptering (TPM_Unseal) endast ske om värdena på PCR inte har förändrats som ett resultat av bootningen (det vill säga att ingen "mätt" komponent har modifierats).

Verified Boot

Det mest skrämmande för dem som älskar att modifiera UEFI BIOS är läget Verified Boot (VB), där varje bootkomponent kryptografiskt verifierar integriteten och äktheten av nästa. Och i händelse av verifieringsfel inträffar (ett av):

• timeout av 1 minut till 30 minuter (för att användaren ska hinna förstå varför datorn inte startar och, om möjligt, försöka återställa BIOS);
• omedelbar avstängning (för att användaren inte ska hinna förstå något och, ännu mer, göra något);
• fortsatt arbete med ostörd uppsyn (det tillfället när säkerhet inte är en prioritet, då det finns viktigare saker att göra).

Valet av åtgärd beror på den angivna konfigurationen av Intel BG (det vill säga, den så kallade enforcement policy), som ständigt skrivs in av plattformsleverantören i ett speciellt avsett lagringsutrymme – chipsets fusing (FPF). Vi kommer att gå vidare med detta ämne senare.

Utöver konfigurationen genererar leverantören två RSA 2048 nycklar och skapar två datastrukturer (visas på bilden):

1. Manifest för leverantörens rotnyckel (KEYM, OEM Root Key Manifest), i vilket den lägger SVN (Security Version Number) för detta manifest, SHA256 hash av den offentliga nyckeln för nästa manifest, den offentliga RSA-nyckeln (dvs. den offentliga delen av leverantörens rotnyckel) för att verifiera signaturen av detta manifest och själva signaturen;
2. Manifest för IBB (IBBM, Initial Boot Block Manifest), i vilket den lägger SVN för detta manifest, SHA256 hash av IBB, den offentliga nyckeln för verifikation av signaturen av detta manifest och själva signaturen.

SHA256 hash av den offentliga nyckeln för OEM Root Key skrivs permanent in i chipsets fusing (FPF), precis som konfigurationen av Intel BG. Om konfigurationen av Intel BG tillåter aktivering av denna teknologi, kan på denna system BIOS (dvs. ha möjlighet att räkna om dessa manifester) endast uppdateras av ägaren av den privata delen av OEM Root Key, det vill säga leverantören.

Vid en blick på bilden uppstår genast tvivel om behovet av en så lång verifieringskedja – skulle man inte kunna använda ett enda manifest? Varför komplicera?

I själva verket ger Intel på detta sätt leverantören möjlighet att använda olika IBB-nycklar för olika produktlinjer och en som rotnyckel. Om den privata delen av IBB-nyckeln (som signerar det andra manifestet) läcker, kommer incidenten endast att påverka en produktlinje och bara tills leverantören skapar ett nytt nyckelpar och inkluderar de omräknade manifesten i nästa BIOS-uppdatering.

Men om den rotade nyckeln (som signerar den första manifestfilen) komprometteras kan den inte bytas ut, eftersom det inte finns någon återkallande procedur; hashen av den offentliga delen av denna nyckel programmeras i FPF:erna en gång för alla.

Konfiguration av Intel Boot Guard

Låt oss nu titta närmare på konfigurationen av Intel BG och processen för dess skapande. Om man ser på den relevanta fliken i GUI-verktyget Flash Image Tool från Intel System Tool Kit (STK) kan man notera att konfigurationen av Intel BG inkluderar hashen av den offentliga delen av rotnyckeln från leverantören, ett par otydliga värden och så kallad 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 – gör ingenting
                                              // 01b – stäng av med timeout
                                              // 11b – omedelbar avstängning
	unsigned long : 26;
};

Generellt sett är konfigurationen av Intel BG en mycket flexibel entitet. Låt oss ta en titt på flaggan Force_Boot_Guard_ACM, till exempel. När den är avstängd, om BG startup ACM-modulen på SPI-flashminnet inte hittas, kommer ingen säker uppstart att ske. Det blir en osäker uppstart.

Vi har redan nämnt ovan att efterlevnadspolicyn för VB-läget kan ställas in så att en verifieringsmiss gör att osäker uppstart inträffar igen.

Att lämna sådana saker till leverantörernas bedömning…

GUI-verktyget förutsätter följande 'klara' profiler:

Nummer
Läge
Beskrivning

0
No_FVME
Intel BG-teknik är avstängd

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

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

3
VM
Båda lägena är aktiverade, utan avstängning av systemet

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

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

Som redan nämnts bör konfigurationen av Intel BG en gång för alla skrivas av systemleverantören i chipsetets fuser (FPF:erna) – en liten (enligt obekräftade uppgifter, endast 256 byte) hårdvarulagring för information inom chipsetet, som kan programmeras utanför tillverkningsanläggningarna hos Intel (därför, specifikt Field Programmable Fuses).

Det passar utmärkt för att lagra konfigurationen eftersom:

• det har ett engångsprogrammerbart område för datalagring (precis dit konfigurationen av Intel BG skrivs);
• det kan endast läsas och programmeras av Intel ME.

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

1. Med hjälp av Flash Image Tool (från Intel STK) skapas en firmware-avbild med den angivna konfigurationen av Intel BG i form av variabler inom Intel ME-regionen (det så kallade temporära spegeln för FPF:er);
2. Med hjälp av Flash Programming Tool (från Intel STK) skrivs denna avbild till SPI-flashminnet för systemet och det så kallade manufacturing mode stängs (samtidigt skickas motsvarande kommando till Intel ME).

Som ett resultat av dessa operationer kommer Intel ME att kommitta de angivna värdena från spegeln för FPF:er i ME-regionen, ställa in behörigheterna i SPI-flashdeskriptorerna till de rekommenderade värdena från Intel (som beskrevs i början av artikeln) och utföra en RESET av systemet.

Analys av implementering av Intel Boot Guard

För att analysera implementeringen av denna teknologi på ett specifikt exempel har vi kontrollerat följande system för spår av Intel BG-teknologin:

Systemet
Anmärkning

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

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

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

MSI H170A Gaming Pro
Skylake, inget stöd

Lenovo ThinkPad 460
Skylake, stöd finns, teknologin är aktiverad

Lenovo Yoga 2 Pro
Haswell, inget stöd

Lenovo U330p
Haswell, inget stöd

Med 'stöd' avses förekomsten av Intel BG startup ACM-modulen, de nämnda manifesten och motsvarande kod i BIOS, det vill säga implementeringar för analys.

Som exempel, låt oss ta den nedladdade SPI-flashminnesavbilden för Gigabyte GA-H170-D3H (version F4) från tillverkarens officiella webbplats.

Intel CPU boot ROM

Först och främst, låt oss tala om processorernas handlingar om Intel BG-teknologin är aktiverad.

Exempel på avkrypterad mikrokod har inte kunnat hittas, så hur de följande handlingarna genomförs (i mikrokoden eller hårdvaran) är en öppen fråga. Ändå är det ett faktum att moderna Intel-processorer "kan" utföra dessa handlingar.

Efter att ha gått ur RESET tillståndet hittar processorn (vars adresseringsområde redan är mappat med innehållet i flashminnet) FIT-tabellen (Firmware Interface Table). Det är enkelt att hitta den, pekaren på den är lagrad på adressen FFFF FFC0h.

I det aktuella exemplet ligger värdet FFD6 9500h på denna adress. Genom att adressera denna plats ser processorn FIT-tabellen, vars innehåll är uppdelat i poster. Den första posten är en rubrik av följande struktur:

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_   ’
	unsigned long  NumEntries; // inklusive FIT rubrikpost
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

Av okända skäl beräknas checksumma inte alltid i dessa tabeller (fältet lämnas null).

Övriga poster anger olika binärer som måste parseas/exekveras innan BIOS-exekveringen, det vill säga innan övergången till legacy RESET-vektor (FFFF FFF0h). Strukturen för varje sådan post är följande:

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

Det är nu uppenbart att en av posterna pekar på platsen för binären Intel BG startup ACM. Strukturen för huvudet av denna binär är typisk för de kodmoduler som utvecklas av Intel (ACM:er, mikrokodsuppdateringar, kodsektioner för Intel ME, …).

typedef struct BG_ACM_HEADER
{
	unsigned short ModuleType;     // 2
	unsigned short ModuleSubType;  // 3
	unsigned long  HeaderLength;   // i dwords
	unsigned long  : 32;
	unsigned long  : 32;
	unsigned long  ModuleVendor;   // 8086h
	unsigned long  Date;           // i BCD-format
	unsigned long  TotalSize;      // i dwords
	unsigned long  unknown1[6];
	unsigned long  EntryPoint;
	unsigned long  unknown2[16];
	unsigned long  RsaKeySize;     // i dwords
	unsigned long  ScratchSize;    // i dwords
	unsigned char  RsaPubMod[256];
	unsigned long  RsaPubExp;
	unsigned char  RsaSig[256];
};

Processorn laddar denna binär i sin cache, verifierar och startar.

Intel BG startup ACM

Genom analys av arbetet med denna ACM blev det klart att den gör följande:

• hämtar konfigurationen för Intel BG från Intel ME, skriven i chipsetets fuser (FPF);
• hittar manifester KEYM och IBBM, verifierar dem.

För att hitta dessa manifester använder ACM också FIT-tabellen, där två typer av poster är avsatta för att peka på datatyper (se FIT_ENTRY_TYPES ovan).

Låt oss titta närmare på manifesten. I strukturen för den första manifestet ser vi flera oklara konstanter, hash av den offentliga nyckeln från den andra manifestet och den offentliga nyckeln för OEM Root Key med en signatur i form av en inbäddad 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 av en IBBM publik nyckel
	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 den offentliga nyckeln OEM Root Key, påminner vi om att SHA256-hashen från fuse har använts, vilken redan har erhållits från Intel ME.

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

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

I den första – 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
};

I den andra finns SHA256-hashen av IBB och antalet beskrivare som beskriver innehållet i IBB (dvs. det som hash 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 av en IBB
	unsigned char  NumIbbDescriptors;
};

IBB-beskrivarna följer efter denna struktur, en efter en. Deras innehåll har följande format:

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

Det är enkelt: varje beskrivare innehåller adress/size av en del av IBB. Således är sammankopplingen av blocken, som dessa beskrivare pekar på (i ordningen som beskrivarna själva finns), IBB. Och vanligtvis är IBB en samling av alla modulerna i faserna SEC och PEI.

Den andra manifestet avslutas med en struktur som innehåller den offentliga nyckeln för IBB (som verifieras med SHA256-hashen från den första manifestet) och signaturen för denna manifest:

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

Innan UEFI BIOS börjar genomföra sitt arbete kommer processorn att starta ACM, som kontrollerar autentiteten av innehållet i sektionerna med SEC- och PEI-kod. Därefter går processorn ur ACM, går till RESET-värdet och börjar köra BIOS.

Den verifierade PEI-sektionen måste innehålla en modul som kontrollerar resten av BIOS (DXE-kod). Denna modul utvecklas av antingen IBV (Independent BIOS Vendor) eller av systemleverantören själv. Eftersom vi endast hade system från Lenovo och Gigabyte som stöder Intel BG, kommer vi att titta på koden som extraherats från just dessa system.

UEFI BIOS-modul LenovoVerifiedBootPei

I fallet med Lenovo visade det sig vara modulen LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, utvecklad av Lenovo.

Dess funktion är att söka (via GUID) hash-tabellen 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;
}

Hash-tabellen {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} har följande format:

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

I fallet med Gigabyte visade det sig vara modulen BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, utvecklad av AMI, och därav finns i varje AMI BIOS som stöder Intel BG.

Dess arbetsalgoritm är något annorlunda, men den syftar 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;
}

Hash-tabellen {389CC6F2-1EA8-467B-AB8A-78E769AE2A15}, som den söker 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 diskutera en annan implementering av Intel Boot Guard som har hittats i ett nyare system baserat på Intel SoC med mikroarkitekturen Apollo Lake – ASRock J4205-IT.

Även om denna version endast kommer att användas i SoC:er (nya system med processorarkitekturen Kaby Lake fortsätter att använda Intel Boot Guard 1.x), är den av stort intresse för att studera det nya arkitekturalternativet för plattformar på Intel SoC, där betydande förändringar har inträffat, till exempel:

• BIOS-regioner och Intel ME (snarare Intel TXE, enligt terminologin för Intel SoC) har nu blivit en enda IFWI-region;
• Även om Intel BG var aktiverat på plattformen, hittades inga strukturer som FIT, KEYM, IBBM i flashminnet;
• Förutom TXE- och ISH-kärnorna (x86) har chipsetet fått en tredje kärna (återigen ARC, förresten) – PMC (Power Management Controller), som är kopplad till att säkerställa driftsäkerheten för strömförsörjningssystemet och övervakningen av prestanda.

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

Avstånd
Namn
Beskrivning

0000 2000h
SMIP
någon plattformsconfiguration, signerad av leverantören

0000 6000h
RBEP
kodavsnitt för firmware Intel TXE, x86, signerad av Intel

0001 0000h
PMCP
kodavsnitt för firmware Intel PMC, ARC, signerad av Intel

0002 0000h
FTPR
kodavsnitt för firmware Intel TXE, x86, signerad av Intel

0007 B000h
UCOD
mikrocodeuppdateringar för CPU, signerad av Intel

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

0021 8000h
ISHC
kodavsnitt för firmware Intel ISH, x86, signerad av leverantören

0025 8000h
NFTP
kodavsnitt för firmware Intel TXE, x86, signerad av Intel

0036 1000h
IUNP
Okänt

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

Under analysen av TXE-firmwaren blev det uppenbart att efter en RESET håller TXE processorn i detta tillstånd tills den har förberett en grundläggande innehåll för CPU:ns adresseringsutrymme (FIT, ACM, RESET-vektor …). TXE placerar dessa data i sin egen SRAM och ger tillfälligt processorn tillgång till dem och "frigör" den från RESET.

Håller rötterkit på avstånd

Nu över till det "heta". En gång upptäckte vi att på många system i SPI-flashbeskrivningar fanns behörigheter för åtkomst till SPI-flashminnesregioner så att alla användare av detta minne kan läsa och skriva till vilken region som helst. Dvs. ingenting.

Efter att ha verifierat med hjälp av verktyget MEinfo (från Intel STK) såg vi att manufacturing mode på dessa system inte var stängt, vilket innebär att chipsetets fus inte var i ett definierat tillstånd. Ja, Intel BG var varken aktiverat eller inaktiverat i sådana fall.

Det handlar om följande system (vad gäller Intel BG och det som kommer att framställas senare i artikeln, pratar vi om system med processormikroarkitektur Haswell och uppåt):

• alla produkter från Gigabyte;
• alla produkter från MSI;
• 21 modeller av Lenovo-bärbara datorer och 4 modellt av Lenovo-servrar.

Självklart rapporterade vi vår upptäckte till dessa leverantörer samt till Intel.

Ett adekvat svar kom endast från Lenovo, som erkände problemet och släppte en patch.

Gigabyte verkade ha tagit informationen om sårbarheten, men kommenterade ingenting.

Kommunikationen med MSI det har helt stagnerat på vår begäran att skicka sin öppna PGP-nyckel (för att skicka dem säkerhetsmeddelandet i krypterad form). De hävdade att "de är tillverkare av hårdvara, och PGP-nycklar tillverkas inte."

Men till saken. Eftersom fusen lämnas i odefinierat skick kan användaren (eller en angripare) programmera dem själv (det mest komplicerade är att hitta Intel STK). För detta krävs följande steg.

1. Ladda in i Windows OS (i allmänhet kan de efterföljande åtgärderna även göras under Linux, om en motsvarande Intel STK utvecklas för det aktuella operativsystemet). Använda verktyget MEinfo, se till att fusen på detta system inte är programmerade.

2. Läsa innehållet i flashminnet med hjälp av Flash Programming Tool.

3. Öppna den lästa bilden med hjälp av vilket verktyg som helst för att redigera UEFI BIOS, göra nödvändiga ändringar (infoga en rootkit, till exempel), skapa/redigera befintliga strukturer KEYM och IBBM i ME-regionen.

I bilden är den offentliga delen av RSA-nyckeln markerad, vars hash kommer att programmeras i chipsetets fus samt övrig konfiguration av Intel BG.

4. Använda Flash Image Tool för att samla en ny firmwareavbildning (genom att ange Intel BG-konfigurationen).

5. Skriva den nya bilden till flashminnet med hjälp av Flash Programming Tool, och med hjälp av MEinfo bekräfta att ME-regionen nu innehåller Intel BG-konfigurationen.

6. Med hjälp av Flash Programming Tool stänga av tillverkningsläget.

7. Systemet kommer att starta om, varefter man med MEinfo kan bekräfta att FPF:erna nu är programmerade.

Dessa åtgärder kommer förevigt att aktivera Intel BG på detta system. Åtgärderna kan inte återkallas, vilket innebär:

• att uppdatera UEFI BIOS på detta system kan endast göras av den som har den privata delen av rotnyckeln (dvs. den som aktiverade Intel BG);
• om man återställer systemet till den ursprungliga firmware, till exempel med en programmerare, kommer det inte ens att starta (konsekvens av enforcement policy vid verifieringsfel);
• för att bli av med sådan UEFI BIOS krävs att chipsetet med programmerade FPF:er byts till ett "rent" (dvs. lödas om chipsetet, om du har tillgång till en infraröd lödstation som kostar som en bil, eller helt enkelt byta moderkortet).

För att förstå vad en sådan rootkit kan åstadkomma, måste man bedöma möjligheten att köra sin kod i miljön för UEFI BIOS. Låt oss säga, i den mest privilegierade processorläget – SMM. En sådan rootkit kan ha följande egenskaper:

• kunna köras parallellt med OS (kan ställas in för att aktiveras via generering av SMI-interruption, som triggas av en timer);
• ha alla fördelar av att befinna sig i SMM-läget (full tillgång till innehållet i arbetsminnet och hårdvaruresurser, osynlighet för OS);
• programkoden för rootkit kan finnas i krypterad form och avkodas vid körning i SMM-läget. Som nyckel för krypteringen kan man använda vilken data som helst som endast är tillgänglig i SMM-läget. Till exempel, en hash av en uppsättning adresser i SMRAM. För att få denna nyckel krävs det att man tar sig in i SMM. Och detta kan göras på två sätt. Hitta RCE i SMM-koden och exploatera den, eller lägga till sin egen SMM-modul i BIOS, vilket inte är möjligt eftersom vi har aktiverat Boot Guard.

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

• skapa en dold, oupptäckbar rootkit av okänt syfte i systemet;
• kör sin kod på ett av kärnorna i chipsets inuti Intel SoC, nämligen på Intel ISH (titta noga på bilden).

Även om möjligheterna för subsystems Intel ISH ännu inte har utforskats, framstår den som en intressant angreppsväg på Intel ME.

Slutsatser

1. Undersökningen har lett till en teknisk beskrivning av hur teknologin Intel Boot Guard fungerar. Minus ett par hemligheter i Intels modell security through obscurity.
2. Ett angreppsscenario har presenterats som möjliggör skapandet av en oupptäckbar rootkit i systemet.
3. Vi har sett att moderna Intel-processorer kan köra mycket proprietär kod innan BIOS börjar arbeta.
4. Plattformar med Intel 64-arkitektur blir allt mindre lämpliga för att köra fri programvara: hårdvaruvalidering, det ökande antalet proprietära teknologier och subsystems (tre kärnor i SoC-chipsetet: x86 ME, x86 ISH och ARC PMC).

Mildrande åtgärder

Leverantörer som avsiktligt lämnar manufacturing mode öppet bör stänga det. Hittills blundar man bara och nya Kaby Lake-system visar detta.

Användare kan själva stänga av Intel BG på sina system (som är utsatta för den beskrivna sårbarheten) genom att köra verktyget Flash Programming Tool med parametern -closemnf. Först bör man kontrollera (med hjälp av MEinfo) att konfigurationen av Intel BG i regionen ME faktiskt tillåter att denna teknik stängs av efter programmering i FPF:er.

Källa: habr.com