Schrödingers betroede opstart. Intel Boot Guard

Lad os dykke ned på et lavere niveau og tale om sikkerheden ved firmware til x86-kompatible computerplatforme. Denne gang er hovedingredienserne i undersøgelsen Intel Boot Guard (ikke at forveksle med Intel BIOS Guard!) – en hardware-understøttet teknologi til betroet opstart af BIOS, som producenten af computersystemet kan aktivere eller deaktivere permanent under produktionen. Og opskriften for undersøgelsen kender vi allerede: vi skal finstudere implementeringen af denne teknologi gennem reverse engineering, beskrive dens arkitektur med ikke-dokumenterede detaljer, krydre med angrebsvinkler og blande det hele godt sammen. Lad os øge temperaturen med historien om, hvordan en årevis klonet produktionsfejl hos flere producenter tillader potentielle angribere at udnytte denne teknologi til at oprette en ufortrydelig (selv for programmereren) skjult rootkit i systemet.

For øvrigt er artiklen baseret på præsentationer fra "På vagt mod rootkits: Intel BootGuard" fra konferencen ZeroNights 2016 og det 29. møde DefCon Russia (begge præsentationer her).

Firmware til computerplatforme med Intel 64-arkitektur

Lad os først besvare spørgsmålet: hvad er firmware til en moderne computerplatform med Intel 64-arkitektur? Svaret er naturligvis UEFI BIOS. Men dette svar ville ikke være helt præcist. Lad os tage et kig på billedet, som viser desktop (eller laptop) versionen af denne arkitektur.

Grundlaget er et bundt:

• Processor (CPU, Central Processing Unit), som udover de grundlæggende kerner har en indbygget grafisk kerne (ikke i alle modeller) og en integreret hukommelseskontroller (IMC, Integrated Memory Controller);
• Chipsæt (PCH, Platform Controller Hub), der indeholder forskellige controllere til interaktion med perifere enheder og styring af undersystemer. Blandt dem er den velkendte Intel Management Engine (ME), som også har firmware (Intel ME firmware).

Bærbare computere forventer, ud over det ovenstående, at der er en indbygget controller (ACPI EC, Advanced Control and Power Interface Embedded Controller), der ansvarer for driften af strømsystemet, touchpad, tastatur, Fn-taster (skærmens lysstyrke, lydstyrke, tastaturbelysning osv.) og meget mere. Og den har også sin egen firmware.

Således er summen af de ovenfor nævnte firmware-versioner firmware til computerplatformen (system firmware), som gemmes i den delte SPI flash-hukommelse. For at brugerne af denne hukommelse ikke skal blive forvirrede over, hvem der ejer hvad, er indholdet af denne hukommelse opdelt i følgende regioner (som vist på billedet):

• UEFI BIOS;
• firmware ACPI EC (en separat region dukkede op med mikroarkitekturen Skylake (2015), men i praksis har vi endnu ikke set eksempler på dets anvendelse, så firmware til den indbyggede controller er stadig en del af UEFI BIOS);
• firmware Intel ME;
• konfiguration (MAC-adresse osv.) af den indbyggede GbE (Gigabit Ethernet) netværksadapter;
• flash-deskriptorer (Flash Descriptors) – den primære region af flash-hukommelsen, der indeholder referencer til de andre regioner samt adgangstilladelser til dem.

Adgangsbegrænsningen til regionerne (i overensstemmelse med de angivne tilladelser) styres af SPI-bus-masteren – den indbyggede SPI-controller i chipsettet, som bruges til at tilgå denne hukommelse. Hvis tilladelserne er indstillet til de anbefalede (af sikkerhedshensyn) værdier af Intel, har hver bruger af SPI flash-hukommelsen fuld adgang (læsning/skrivning) kun til sin egen region. De andre er enten kun tilgængelige for læsning eller helt utilgængelige. Det er godt kendt, at CPU'en i mange systemer har fuld adgang til UEFI BIOS og GbE, læsetilgang til flash-deskriptorerne, men ingen adgang til regionen Intel ME. Hvorfor på mange, men ikke på alle? Hvad der anbefales, er ikke nødvendigvis obligatorisk. Vi vil uddybe dette senere i artiklen.

Mekanismer til beskyttelse af firmware på computerplatformen mod modificering

Det er tydeligt, at firmware på computerplatformen skal beskyttes mod potentielle kompromitteringer, som ville give en potentiel angriber mulighed for at etablere sig i den (overleve opdateringer/geninstallationer af OS), køre sin kode i de mest privilegerede tilstande osv. Og adgangsbegrænsninger til regionerne i SPI flash-hukommelsen er selvfølgelig ikke tilstrækkelige. Derfor bruges forskellige mekanismer, der er specifikke for hvert udførelsesmiljø, til at beskytte firmwaren mod modificeringer.

Således er firmware Intel ME signeret for at kontrollere integritet og ægthed og bliver verificeret af ME-controlleren ved hver indlæsning i ME UMA-hukommelsen. Denne verifikationsproces er allerede blevet drøftet i en af vores tidligere artikler. artikler, dedikeret til Intel ME-systemet.

Men ACPI EC firmwaren kontrolleres normalt kun for integritet. Dog, da denne binærfil er inkluderet i UEFI BIOS, gælder de samme beskyttelsesmekanismer, som anvendes af UEFI BIOS, i næsten alle tilfælde for den. Lad os tale om dem.

Disse mekanismer kan opdeles i to kategorier.

Beskyttelse mod skrivning til UEFI BIOS-regionen

1. Fysisk beskyttelse af indholdet af SPI flash-hukommelsen med et write-protect jumper;
2. Beskyttelse af projektionen af UEFI BIOS-regionen i CPU'ens adresserum ved hjælp af PRx registre fra chipsettet;
3. Blokering af skriveforsøg i UEFI BIOS-regionen ved at generere og behandle den relevante SMI afbrydelse ved at sætte BIOS_WE/BLE og SMM_BWP bits i chipsets registrene;
4. En mere avanceret variant af denne beskyttelse er Intel BIOS Guard (PFAT).

Ud over disse mekanismer kan leverandører udvikle og anvende deres egne sikkerhedsforanstaltninger (f.eks. signering af kapsler med UEFI BIOS-opdateringer).

Det er vigtigt at bemærke, at ikke alle de ovennævnte beskyttelsesmekanismer nødvendigvis anvendes på et bestemt system (afhænger af leverandøren), de kan slet ikke anvendes, eller de kan være utilstrækkeligt implementeret. Læs mere om disse mekanismer og situationen omkring deres implementering i denne artikel. Vi anbefaler interesserede at gennemgå hele artiklen om UEFI BIOS-sikkerhed fra CodeRush.

Verifikation af UEFI BIOS autencitet

Når vi taler om teknologier til betroet opstart, er det første, der kommer i tankerne, – Secure Boot. Arkitektonisk er det imidlertid designet til at kontrollere autenciteten af eksterne komponenter i forhold til UEFI BIOS (drivere, bootloadere osv.), og ikke selve firmware.

Derfor implementerede Intel i SoC'er med Bay Trail mikroarkitektur (2012) en hardware Secure Boot (Verified Boot), der ikke har noget at gøre med den ovennævnte Secure Boot-teknologi. Senere (2013) blev denne mekanisme forbedret og udgivet under navnet Intel Boot Guard til desktops med Haswell mikroarkitektur.

Før vi beskriver Intel Boot Guard, lad os se på udførelsesmiljøerne i Intel 64 arkitekturen, som også er tillidens rod for denne teknologi til betroet opstart.

Intel CPU

Kaptajnen fortæller, at processoren er det primære udførelsesmiljø i Intel 64 arkitekturen. Hvorfor er det også tillidens rod? Det viser sig, at det skyldes besiddelse af følgende elementer:

• Microcode ROM — en ikke-ændrbar, ikke-flygtig hukommelse til lagring af mikrokode. Mikrokoden anses for at være implementeringen af processorens kommando system i de mest basale instruktioner. Der kan også opstå fejl. Så i BIOS kan man finde binærer med opdateringer af mikrokoden (de anvendes under opstart, da ROM ikke kan ændres). Indholdet af disse binærer er krypteret, hvilket væsentligt komplicerer analysen (derfor kender kun dem, der udvikler dem, det specifikke indhold af mikrokoden), og de er underskrevet for at kontrollere integriteten og ægtheden;
• AES-nøgle til dekryptering af indholdet af mikrouppdateringer;
• hash af den offentlige RSA-nøgle, der bruges til at verificere underskriften af mikrouppdateringer;
• hash af den offentlige RSA-nøgle, der bruges til at verificere underskriften af de af Intel udviklede kodelag (Authenticated Code Module), som CPU'en kan eksekvere inden begyndelsen af BIOS-kørsel (goddag mikrokode) eller under dets drift, når visse hændelser opstår.

Intel ME

Denne underkomponent er blevet nævnt i vores blog hele to artikler. Husk, at dette eksekverbare miljø er baseret på en mikrocontroller indbygget i chipsættet og er det mest skjulte og privilegerede i systemet.

På trods af sin skjulthed er Intel ME også roden til tillid, da den har:

• ME ROM — en ikke-ændrbar, ikke-flygtig hukommelse (der er ingen opdateringsmetode), der indeholder startkode, samt en SHA256-hash af den offentlige RSA-nøgle, der bruges til at verificere underskriften af Intel ME-firmware;
• AES-nøgle til opbevaring af hemmelige oplysninger;
• adgang til det indbyggede chipsæts feltprogrammérbare sikringer (FPFs, Field Programmable Fuses) til permanent opbevaring af visse oplysninger, herunder dem angivet af systemleverandøren.

Intel Boot Guard 1.x

En lille ansvarsfraskrivelse. Versionsnumrene på Intel Boot Guard-teknologien, som vi arbejder med i denne artikel, er betingede og kan ikke have noget tilfælles med den nummerering, der anvendes i Intels interne dokumentation. Desuden er oplysningerne her om implementeringen af denne teknologi opnået gennem reverse engineering, og kan indeholde unøjagtigheder i forhold til specifikationen for Intel Boot Guard, som det næppe nogensinde vil blive offentliggjort.

Så, Intel Boot Guard (BG) er en hardware-understøttet teknologi til autentificering af UEFI BIOS. Ifølge den korte beskrivelse i bogen [Platform Embedded Security Technology Revealed, kapitel Boot with Integrity, or Not Boot] fungerer den som en kæde af betroet opstart. Det første led i den kæde er opstartskoden (mikrokoden) inden i CPU'en, som aktiveres ved RESET-hændelsen (ikke forveksles med RESET-vektoren i BIOS!). CPU'en finder en kode moduleret og signeret af Intel i SPI-flashhukommelsen (Intel BG startup ACM), indlæser det i sin cache, verificerer (det er nævnt ovenfor, at CPU'en har hash af den offentlige nøgle, der bruges til at kontrollere signaturen af ACM) og starter det.

Dette kode moduler er ansvarligt for at verificere den lille startdel af UEFI BIOS — Initial Boot Block (IBB), som igen indeholder funktionalitet til at verificere hoveddelen af UEFI BIOS. Dermed tillader Intel BG at sikre BIOS' ægthed, inden operativsystemet indlæses (som kan køre under overvågning af Secure Boot teknologien).

Intel BG teknologien tilbyder to driftsindstillinger (hvoraf den ene ikke hindrer den anden, dvs. begge indstillinger kan være aktiveret på systemet, eller ingen af dem kan være aktiveret).

Measured Boot

I Measured Boot (MB) tilstanden "måler" hver opstartskomponent (begyndende med CPU boot ROM) den næste ved hjælp af TPM (Trusted Platform Module) funktionalitet. For dem, der ikke er bekendt med det, lad os uddybe.

TPM har PCR'er (Platform Configuration Registers), hvor resultatet af hash-operationen gemmes ved hjælp af formlen:

Det vil sige, at det nuværende PCR-værdi afhænger af det tidligere, hvor disse registre kun nulstilles ved system RESET.

Dermed afspejler PCR'erne i MB-tilstanden på et givet tidspunkt en unik (inden for rammerne af hash-operationen) identifikator for den kode eller de data, der er "målt". PCR-værdierne kan anvendes ved krypteringsoperationen af nogle data (TPM_Seal). Derefter vil deres dekryptering (TPM_Unseal) kun være mulig, hvis PCR-værdierne efter opstart ikke er ændret (dvs. ingen "målte" komponenter er blevet modificeret).

Verified Boot

Det værste for dem, der elsker at modificere UEFI BIOS, er Verified Boot (VB) tilstanden, hvor hver opstartskomponent kryptografisk kontrollerer integriteten og autenticiteten af den næste. I tilfælde af en verificeringsfejl, sker der (et af):

• timeout fra 1 minut til 30 minutter (for at brugeren får mulighed for at forstå årsagen til, at computeren ikke starter, og om muligt forsøger at gendanne BIOS);
• øjeblikkelig slukning (så brugeren ikke når at forstå noget og slet ikke gøre noget);
• fortsætte arbejdet med en upartisk mine (den situation, hvor sikkerhed ikke er en prioritet, for der er vigtigere ting).

Valget af handling afhænger af den angivne Intel BG-konfiguration (mere præcist den såkaldte enforcement policy), som vedligeholdes af leverandøren af den computerplatform, der permanent skrivs til et specielt lager - chipset-fusible (FPF'er). Vi vil uddybe dette punkt senere.

Udover konfigurationen genererer leverandøren to RSA 2048 nøgler og skaber to datastrukturer (vist på billedet):

1. Leverandørens rodnøglemanifest (KEYM, OEM Root Key Manifest), hvori der inkluderes SVN (Security Version Number) for dette manifest, en SHA256 hash af den offentlige nøgle for det næste manifest, den offentlige RSA-nøgle (dvs. den offentlige del af leverandørens rodnøgle) til verifikation af signaturen af dette manifest og selve signaturen;
2. IBB-manifestet (IBBM, Initial Boot Block Manifest), hvori der inkluderes SVN for dette manifest, SHA256 hash af IBB, den offentlige nøgle til verifikation af signaturen af dette manifest og selve signaturen.

SHA256 hash af den offentlige OEM Root Key skrives permanent til chipset-fusible (FPF'er), ligesom konfigurationen af Intel BG. Hvis Intel BG-konfigurationen tillader denne teknologi, kan BIOS (dvs. opdatering af disse manifester) fra dette tidspunkt kun opdateres af indehaveren af den private del af OEM Root Key, dvs. leverandøren.

Når man ser på billedet, opstår der straks tvivl om nødvendigheden af sådan en lang verificeringskæde - man kunne have brugt et enkelt manifest. Hvorfor gøre det mere kompliceret?

Faktisk giver Intel på denne måde leverandøren mulighed for at bruge forskellige IBB-nøgler til forskellige produktserier og en som rodnøgle. Hvis den private del af IBB-nøglen (som bruges til at signere det andet manifest) lækkes, vil hændelsen kun påvirke en produktserie og kun indtil leverandøren genererer et nyt nøglepar og inkluderer de genberegnede manifester i den næste BIOS-opdatering.

Men hvis rodnøglen (som underskriver det første manifest) bliver kompromitteret, kan den ikke ændres, der findes ingen tilbagekaldelsesprocedurer, da hash-værdien af den offentlige del af denne nøgle programmeres i FPF'erne én gang for alle.

Intel Boot Guard-konfiguration

Lad os nu se nærmere på konfigurationen af Intel BG og processen for dens oprettelse. Hvis man ser på den relevante fane i GUI-værktøjet Flash Image Tool fra Intel System Tool Kit (STK), kan man bemærke, at Intel BG-konfigurationen inkluderer hash-værdien af den offentlige del af rodnøglen fra producenten, et par uklare værdier samt den såkaldte Intel BG-profil.

Strukturen af denne 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 – luk ned med timeout
                                              	// 11b – øjeblikkelig lukning
	unsigned long : 26;
};

Generelt er Intel BG-konfiguration en meget fleksibel entitet. Lad os tage flaget Force_Boot_Guard_ACM som eksempel. Når det er afbrudt, hvis BG startup ACM-modulet ikke findes i SPI-flashhukommelsen, vil der ikke være nogen betroet opstart. Der vil være en ubetrustet opstart.

Tidligere har vi nævnt, at enforcement policy for VB-tilstand kan indstilles sådan, at der ved verifikationsfejl igen vil ske en ubetrustet opstart.

At overlade sådanne ting til producenternes skøn...

GUI-værktøjet tilbyder følgende "færdige" profiler:

Nummer
Tilstand
Description

0
No_FVME
Intel BG-teknologi er deaktiveret

1
VE
VB-tilstand aktiveret, lukning ved timeout

2
VME
Begge tilstande (VB og MB) aktiveret, lukning ved timeout

3
VM
Begge tilstande aktiveret, ingen systemlukning

4
FVE
VB-tilstand aktiveret, øjeblikkelig lukning

5
FVME
Begge tilstande aktiveret, øjeblikkelig lukning

Som nævnt, skal Intel BG-konfigurationen for en gang skyld være skrevet af systemproducenten i chipsets fuser (FPF'erne) - et lille (ifølge uofficielle kilder, kun 256 byte) hardwarelager af information inden i chipsettet, der kan programmeres uden for virksomhedens produktionsfaciliteter (derfor, netop Field Programmable Fuses).

Det er velegnet til at gemme konfigurationen, da det:

• har et one-time-programmable område til lagring af data (præcis der, hvor Intel BG-konfigurationen skrives);
• kun Intel ME kan læse og programmere det.

For at angive konfigurationen for Intel BG-teknologien på et bestemt system, foretager leverandøren under produktionen følgende:

1. Ved hjælp af Flash Image Tool (fra Intel STK) oprettes et firmwarebillede med den specificerede Intel BG-konfiguration som variabler i Intel ME-regionen (den såkaldte midlertidige spejling for FPF'er);
2. Ved hjælp af Flash Programming Tool (fra Intel STK) skrives dette billede til SPI flash-hukommelsen i systemet, og den såkaldte manufacturing mode lukkes (hvorved den relevante kommando sendes til Intel ME).

Som resultat af disse operationer vil Intel ME forpligte de angivne værdier fra spejlingen for FPF'er i ME-regionen, indstille tilladelser i SPI flash-deskriptorerne til de anbefalede værdier fra Intel (som beskrevet i begyndelsen af artiklen) og udføre en RESET af systemet.

Analyse af implementeringen af Intel Boot Guard

For at analysere implementeringen af denne teknologi på et konkret eksempel har vi tjekket følgende systemer for forekomster af Intel BG-teknologien:

System
Bemærk

Gigabyte GA-H170-D3H
Skylake, understøttelse findes

Gigabyte GA-Q170-D3H
Skylake, understøttelse findes

Gigabyte GA-B150-HD3
Skylake, understøttelse findes

MSI H170A Gaming Pro
Skylake, ingen understøttelse

Lenovo ThinkPad 460
Skylake, understøttelse findes, teknologi er aktiveret

Lenovo Yoga 2 Pro
Haswell, ingen understøttelse

Lenovo U330p
Haswell, ingen understøttelse

Med 'understøttelse' forstås tilstedeværelsen af Intel BG startup ACM-modulet, de nævnte manifests og den relevante kode i BIOS, dvs. implementeringen til analysen.

Som eksempel tager vi det downloadede firmwarebillede til SPI flash-hukommelsen for Gigabyte GA-H170-D3H (version F4) fra producentens officielle hjemmeside.

Intel CPU boot ROM

Lad os først tale om processorens handlinger, hvis Intel BG-teknologien er aktiveret.

Det er ikke lykkedes at finde eksempler på dekrypteret mikrokode, så hvordan de nævnte handlinger er implementeret (i mikrokode eller hardware) er et åbent spørgsmål. Ikke desto mindre er det et faktum, at moderne Intel-processorer 'kan' udføre disse handlinger.

Efter at have forladt RESET-tilstanden finder processoren (hvis adresseområde allerede er mappet til indholdet af flash-hukommelsen) FIT-tabellen (Firmware Interface Table). Det er nemt at finde den, da dens adresse er gemt ved adressen FFFF FFC0h.

I dette eksempel ligger værdien FFD6 9500h på denne adresse. Når processoren besøger denne adresse, ser den FIT-tabellen, hvis indhold er opdelt i poster. Den første post er en overskrift af følgende struktur:

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

Af en ukendt årsag er checksum'en langt fra altid beregnet i disse tabeller (feltet er ladt nul).

De øvrige poster henviser til forskellige binarer, som skal parses/udføres, før BIOS eksekveres, dvs. før overgangen til legacy RESET-vektor (FFFF FFF0h). Strukturen af hver sådan post er som følger:

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

Feltet EntryType angiver typen af blokken, som denne post henviser til. Vi kender flere 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 er nu åbenlyst, at en af posterne henviser til placeringen af binæren Intel BG startup ACM. Strukturen af overskriften til denne binær er typisk for de kodemoduler, der udvikles af Intel (ACM'er, microcode-opdateringer, kode-sektioner 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];
};

Processoren indlæser denne binar i sin cache, verificerer og starter den.

Intel BG startup ACM

Som et resultat af analysen af dette ACM blev det klart, at det udfører følgende:

• modtager fra Intel ME konfigurationen af Intel BG, indspillet i chipset-fusene (FPF'erne);
• finder manifests af KEYM og IBBM, verificerer dem.

For at finde disse manifests bruger ACM også FIT-tabellen, hvor der er dedikeret to typer poster til at referere til dataene i strukturen (se FIT_ENTRY_TYPES ovenfor).

Lad os se nærmere på manifests. I strukturen af den første manifest ser vi flere uklare konstanter, hash af den offentlige nøgle fra den anden manifest og den offentlige nøgle OEM Root Key med en signatur i form af en indlejret 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 af en IBBM offentlig nøgle
	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];
};

For at verificere den offentlige nøgle OEM Root Key, skal vi minde om, at der anvendes en SHA256 hash fra fuserne, som allerede er modtaget fra Intel ME.

Lad os gå videre til den anden manifest. Den består af tre strukturer:

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

I den første – nogle 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 anden findes SHA256 hash af IBB samt antallet af deskriptorer, som beskriver indholdet af IBB (dvs. det, som hash beregnes fra):

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 af en IBB
	unsigned char  NumIbbDescriptors;
};

IBB deskriptorerne følger efter denne struktur, én efter én. Deres indhold har følgende format:

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

Det er simpelt: hver deskriptor indeholder adresse/størrelse af en del af IBB. Således er konkateneringen af de blokke, som disse deskriptorer peger på (i den rækkefølge, som deskriptorerne selv er placeret i), IBB. Og som regel er IBB en samling af alle moduler i sekvenserne SEC og PEI.

Den anden manifest afslutter en struktur, der indeholder den offentlige nøgle IBB (verificeres med en SHA256 hash fra den første manifest) og signaturen på denne manifest:

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

Så før UEFI BIOS' udførelse starter, vil processoren aktivere ACM, som vil kontrollere ægtheden af indholdet i sektionerne med SEC- og PEI-koden. Derefter forlader processoren ACM, går til RESET-vektoren og begynder at udføre BIOS.

Den verificerede PEI-sektion skal indeholde en modul, der vil kontrollere resten af BIOS (DXE-koden). Denne modul udvikles af en IBV (Independent BIOS Vendor) eller systemets leverandør. Da de systemer, vi har til rådighed og som understøtter Intel BG, kun er fra Lenovo og Gigabyte, vil vi se på koden, udtrukket fra netop disse systemer.

UEFI BIOS-modul LenovoVerifiedBootPei

I tilfælde af Lenovo viser det sig at være modulet LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, udviklet af Lenovo.

Dets arbejde består i at søge (via GUID) efter en hash-tabel for DXE og verificere 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ølgende 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 tilfældet med Gigabyte viser det sig at være modulet BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, udviklet af AMI, og derfor til stede i enhver AMI BIOS, der understøtter Intel BG.

Dets algoritme er lidt anderledes, men går ud på det samme:

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øger efter, har følgende 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

Lad os kort tale om en anden implementering af Intel Boot Guard, som blev fundet i et nyere system baseret på Intel SoC med Apollo Lake mikroarkitektur — ASRock J4205-IT.

Selv om denne version kun vil blive anvendt i SoC'er (nye systemer med Kaby Lake mikroarkitektur fortsætter med at bruge Intel Boot Guard 1.x), er den af stor interesse for at studere den nye arkitekturs variant for platforme på Intel SoC, hvor der er sket betydelige ændringer, for eksempel:

• BIOS-områderne og Intel ME (mere præcist Intel TXE, ifølge terminologien for Intel SoC) er nu ét område IFWI;
• Selv om Intel BG var aktiveret på platformen, blev der ikke fundet strukturer som FIT, KEYM, IBBM i flashhukommelsen;
• Udover TXE og ISH kernerne (x86) blev der til chipset tilføjet en tredje kerne (for resten ARC) – PMC (Power Management Controller), som er relateret til drift af strømforsyningssystemet og overvågning af ydeevne.

Indholdet af den nye IFWI-region består af et sæt følgende moduler:

Offset
Navn
Description

0000 2000h
SMIP
en konfiguration af platformen, signeret af leverandøren

0000 6000h
RBEP
kodeafsnit af Intel TXE firmware, x86, signeret af Intel

0001 0000h
PMCP
kodeafsnit af Intel PMC firmware, ARC, signeret af Intel

0002 0000h
FTPR
kodeafsnit af Intel TXE firmware, x86, signeret af Intel

0007 B000h
UCOD
mikrokodeopdateringer til CPU, signeret af Intel

0008 0000h
IBBP
UEFI BIOS, SEC/PEI faser, x86, signeret af leverandøren

0021 8000h
ISHC
kodeafsnit af Intel ISH firmware, x86, signeret af leverandøren

0025 8000h
NFTP
kodeafsnit af Intel TXE firmware, x86, signeret af Intel

0036 1000h
IUNP
ukendt

0038 1000h
OBBP
UEFI BIOS, DXE fase, x86, ikke signeret

Under analysen af TXE-firmwaren blev det tydeligt, at efter RESET holder TXE processorens tilstand, indtil den forbereder det grundlæggende indhold af adresseområdet til CPU'en (FIT, ACM, RESET-vektor ...). TXE placerer disse data i sin SRAM, hvorefter den midlertidigt giver beskyttelse til processoren og "frigiver" den fra RESET.

Beskyttelse mod rootkits

Men nu over til det "varme" emne. En gang opdagede vi, at på mange systemer er der skrevet adgangstilladelser til SPI flashdeskriptorerne, så alle brugere af denne hukommelse kan både skrive til og læse fra enhver region. Det vil sige, at der ikke er nogen restriktioner.

Efter at have kontrolleret med MEinfo-værktøjet (fra Intel STK) så vi, at manufacturing mode på disse systemer ikke var lukket, hvilket betyder, at chipsets fuser (FPF'er) var efterladt i usikker tilstand. Ja, Intel BG er i sådanne tilfælde hverken aktiveret eller deaktiveret.

Det gælder følgende systemer (vedrørende Intel BG og det, der vil blive beskrevet videre i artiklen, taler vi om systemer med Haswell mikroarkitektur og højere):

• alle produkter fra Gigabyte;
• alle produkter fra MSI;
• 21 modeller af Lenovo bærbare computere og 4 modeller af Lenovo servere.

Selvfølgelig informerede vi disse leverandører samt Intel om vores opdagelse.

Den passende reaktion kom kun fra Lenovo, som anerkendte problemet og udsendte en patch.

Gigabyte selvom de tilsyneladende modtog informationen om sårbarheden, kommenterede de det på ingen måde.

Kommunikation med MSI det stoppede helt op på vores anmodning om at sende deres offentlige PGP-nøgle (for at sende dem sikkerhedsanbefalinger i krypteret form). De erklærede, at de «er en hardwareproducent, og de producerer ikke PGP-nøgler».

Men tilbage til sagen. Da fuserne er efterladt i en ubestemt tilstand, kan brugeren (eller en ondsindet aktør) programmere dem selv (det sværeste er - at finde Intel STK). For dette kræves det, at følgende trin udføres.

1. Boote op i Windows OS (de senere beskrevne handlinger kan faktisk også udføres fra Linux, hvis der udvikles en tilsvarende Intel STK til det ønskede OS). Ved at bruge værktøjet MEinfo, skal du bekræfte, at fuserne på dette system ikke er programmeret.

2. Læs indholdet af flash-hukommelsen ved hjælp af Flash Programming Tool.

3. Åbn det læste billede med ethvert værktøj til redigering af UEFI BIOS, foretag nødvendige ændringer (fx indsætte en rootkit), opret/rediger eksisterende KEYM og IBBM strukturer i ME-regionen.

På billedet er den offentlige del af RSA-nøglen udskilt, hvis hash vil blive programmeret i fuserne i chipset'et sammen med den øvrige konfiguration af Intel BG.

4. Ved hjælp af Flash Image Tool skal du samle et nyt firmwarebillede (ved at angive konfigurationen af Intel BG).

5. Skriv det nye billede til flash-hukommelsen ved hjælp af Flash Programming Tool, og bekræft ved hjælp af MEinfo, at ME-regionen nu indeholder konfigurationen af Intel BG.

6. Brug Flash Programming Tool til at lukke manufacturing mode.

7. Systemet genstarter, hvorefter du kan bekræfte med MEinfo, at FPF'erne nu er programmeret.

Disse handlinger vil for evigt aktivere Intel BG på dette system. Det vil ikke være muligt at annullere handlingen, hvilket betyder:

• at opdatere UEFI BIOS på dette system kun vil være muligt for den, der ejer den private del af rodnøglen (det vil sige den, der aktiverede Intel BG);
• hvis du geninstallerer den oprindelige firmware på dette system, for eksempel ved hjælp af en programmer, vil det endda ikke starte (konsekvensen af enforcement policy i tilfælde af valideringsfejl);
• for at slippe af med sådan UEFI BIOS, kræves det at udskifte chipset'et med programmerede FPF'er til en «ren» (det vil sige, lodde chipset'et, hvis du har adgang til en infrarød lodde station, der koster som en bil, eller bare erstatte bundkortet).

For understanding what such a rootkit can do, it is necessary to assess what allows executing its code in the UEFI BIOS environment. Let's say, in the most privileged mode of the processor – SMM. Such a rootkit can have the following properties:

• execute parallel to the OS (it can be configured to trigger execution by generating an SMI interrupt, which will be triggered by a timer);
• have all the advantages of being in SMM mode (full access to the contents of RAM and hardware resources, stealth from the OS);
• the rootkit's code may be encrypted and decrypted upon launching in SMM mode. Any data accessible only in SMM can be used as the encryption key. For example, a hash of a set of addresses in SMRAM. To obtain this key, one would need to get into SMM. This can be done in two ways: find an RCE in the SMM code and exploit it, or add your own SMM module to the BIOS, which is impossible since we have enabled Boot Guard.

Thus, this vulnerability allows an attacker to:

• create a hidden, undeletable rootkit of unknown purpose in the system;
• execute their code on one of the chipset cores inside an Intel SoC, specifically, on Intel ISH (let's take a closer look at the picture).

Although the capabilities of Intel ISH subsystem have not yet been studied, it appears to be an interesting attack vector on Intel ME.

Konklusioner

1. The research has provided a technical description of how Intel Boot Guard technology works. A downside of a couple of secrets in Intel's security through obscurity model.
2. An attack scenario has been presented that allows creating an undeletable rootkit in the system.
3. We have seen that modern Intel processors are capable of executing a lot of proprietary code even before the BIOS starts running.
4. Platforms with Intel 64 architecture are becoming less suitable for running free software: hardware verification, an increasing number of proprietary technologies and subsystems (three cores in the SoC chipset: x86 ME, x86 ISH, and ARC PMC).

Mitigations

Vendors who intentionally leave the manufacturing mode open should definitely close it. So far, only eyes are being closed, and new Kaby Lake systems are showing this.

Brugere kan selv deaktivere Intel BG på deres systemer (som er udsat for den beskrevne sårbarhed) ved at køre Flash Programming Tool med parameteren -closemnf. Først bør man sikre sig (ved hjælp af MEinfo), at Intel BG-konfigurationen i ME-regionen specifikt muliggør deaktivering af denne teknologi efter programmering til FPF-erne.

Kilde: habr.com