Schrödingers pålitelige nedlasting. Intel Boot Guard

Vi foreslår å gå ned til et lavt nivå igjen og snakke om sikkerheten til fastvare for x86-kompatible dataplattformer. Denne gangen er hovedingrediensen i studien Intel Boot Guard (må ikke forveksles med Intel BIOS Guard!) - en maskinvarestøttet pålitelig BIOS-oppstartsteknologi som datasystemleverandøren kan aktivere eller deaktivere permanent på produksjonsstadiet. Vel, forskningsoppskriften er allerede kjent for oss: skjær implementeringen av denne teknologien i tynne skiver ved å bruke omvendt utvikling, beskriv arkitekturen, fyll den med udokumenterte detaljer, krydre den med angrepsvektorer etter smak og blanding. La oss legge bensin til historien om hvordan en feil som har blitt klonet i årevis i produksjonen av flere leverandører, lar en potensiell angriper bruke denne teknologien til å lage et skjult rootkit i systemet som ikke kan fjernes (selv med en programmerer).

Artikkelen er forresten basert på rapportene «On Guard of Rootkits: Intel BootGuard» fra konferansen ZeroNights 2016 og 29. møte DefCon Russland (begge presentasjoner her).

Fastvare for en datamaskinplattform med Intel 64-arkitektur

Først, la oss svare på spørsmålet: hva er fastvaren til en moderne datamaskinplattform med Intel 64-arkitektur? Selvfølgelig, UEFI BIOS. Men et slikt svar vil ikke være nøyaktig. La oss ta en titt på bildet, som viser skrivebordsversjonen (bærbar) av denne arkitekturen.

Grunnlaget er lenken:

• Prosessor (CPU, Central Processing Unit), som i tillegg til hovedkjernene har en innebygd grafikkkjerne (ikke i alle modeller) og en minnekontroller (IMC, Integrated Memory Controller);
• Chipset (PCH, Platform Controller Hub), som inneholder ulike kontrollere for samhandling med perifere enheter og administrasjon av undersystemer. Blant dem er den velkjente Intel Management Engine (ME), som også har fastvare (Intel ME firmware).

Bærbare datamaskiner, i tillegg til det ovennevnte, krever en innebygd kontroller (ACPI EC, Advanced Control and Power Interface Embedded Controller), som er ansvarlig for driften av strømundersystemet, pekeplaten, tastaturet, Fn-tastene (skjermens lysstyrke, lydvolum). , tastaturbakgrunnsbelysning osv. ) og andre ting. Og den har også sin egen firmware.

Så helheten av fastvaren ovenfor er fastvaren til datamaskinplattformen (systemfastvaren), som er lagret på et vanlig SPI-flashminne. For at brukere av dette minnet ikke skal bli forvirret over hvor det er, er innholdet i dette minnet delt inn i følgende regioner (som vist i figuren):

• UEFI BIOS;
• ACPI EC-fastvare (en egen region dukket opp med Skylake-prosessormikroarkitekturen (2015), men i naturen har vi ennå ikke sett eksempler på bruken, så fastvaren til den innebygde kontrolleren er fortsatt inkludert i UEFI BIOS) ;
• Intel ME firmware;
• konfigurasjon (MAC-adresse, etc.) av den innebygde GbE (Gigabit Ethernet) nettverksadapteren;
• Flash-beskrivelser er hovedregionen i flash-minnet som inneholder pekere til andre regioner, samt tillatelser for å få tilgang til dem.

SPI-bussmasteren, en SPI-kontroller innebygd i brikkesettet, som dette minnet får tilgang til, er ansvarlig for å avgrense tilgang til regioner (i samsvar med de spesifiserte tillatelsene). Hvis tillatelsene er satt til Intels anbefalte (av sikkerhetsgrunner) verdier, har hver SPI flash-bruker full tilgang (lese/skrive) kun til sin region. Og resten er enten skrivebeskyttet eller utilgjengelig. Et velkjent faktum: på mange systemer har CPU full tilgang til UEFI BIOS og GbE, lesetilgang kun til flash-beskrivelser og ingen tilgang til Intel ME-regionen i det hele tatt. Hvorfor på mange, og ikke på alle? Det som anbefales er ikke nødvendig. Vi vil fortelle deg mer i detalj senere i artikkelen.

Mekanismer for å beskytte datamaskinplattformens fastvare mot endringer

Åpenbart bør fastvaren til en dataplattform beskyttes mot mulig kompromittering, noe som vil tillate en potensiell angriper å få fotfeste i den (overleve OS-oppdateringer/reinstallasjoner), utføre koden deres i de mest privilegerte modusene, etc. Og å begrense tilgangen til SPI-flashminneregioner er selvfølgelig ikke nok. Derfor, for å beskytte fastvaren mot modifikasjoner, brukes ulike mekanismer som er spesifikke for hvert driftsmiljø.

Dermed er Intel ME-fastvaren signert for å kontrollere integritet og autentisitet, og kontrolleres av ME-kontrolleren hver gang den lastes inn i ME UMA-minnet. Denne bekreftelsesprosessen har allerede blitt diskutert av oss i en av Artikkel, dedikert til Intel ME-delsystemet.

Og ACPI EC-firmware kontrolleres som regel bare for integritet. Men på grunn av det faktum at denne binære filen er inkludert i UEFI BIOS, er den nesten alltid underlagt de samme beskyttelsesmekanismene som UEFI BIOS bruker. La oss snakke om dem.

Disse mekanismene kan deles inn i to kategorier.

Skrivebeskyttelse i UEFI BIOS-regionen

1. Fysisk beskyttelse av innholdet i SPI-flashminne med en skrivebeskyttende jumper;
2. Beskyttelse av projeksjonen av UEFI BIOS-regionen i CPU-adresserommet ved hjelp av PRx brikkesettregistre;
3. Blokkering av forsøk på å skrive til UEFI BIOS-regionen ved å generere og behandle det tilsvarende SMI-avbruddet ved å sette BIOS_WE/BLE- og SMM_BWP-bitene i brikkesettregistrene;
4. En mer avansert versjon av denne beskyttelsen er Intel BIOS Guard (PFAT).

I tillegg til disse mekanismene kan leverandører utvikle og implementere sine egne sikkerhetstiltak (for eksempel signering av kapsler med UEFI BIOS-oppdateringer).

Det er viktig å merke seg at på et spesifikt system (avhengig av leverandøren), kan ikke alle de ovennevnte beskyttelsesmekanismene brukes, de kan ikke brukes i det hele tatt, eller de kan implementeres på en sårbar måte. Du kan lese mer om disse mekanismene og situasjonen med deres implementering i denne artikkelen. For de som er interessert, anbefaler vi at du leser hele serien med artikler om UEFI BIOS-sikkerhet fra CodeRush.

UEFI BIOS-autentisering

Når vi snakker om pålitelige oppstartsteknologier, er det første som kommer til tankene Secure Boot. Arkitektonisk er den imidlertid utformet for å verifisere ektheten til komponenter utenfor UEFI BIOS (drivere, bootloadere, etc.), og ikke selve fastvaren.

Derfor implementerte Intel, i SoCs med Bay Trail-mikroarkitektur (2012), en maskinvare ikke-deaktivert Secure Boot (Verified Boot), som ikke har noe til felles med den ovennevnte Secure Boot-teknologien. Senere (2013) ble denne mekanismen forbedret og utgitt under navnet Intel Boot Guard for stasjonære datamaskiner med Haswell-mikroarkitektur.

Før vi beskriver Intel Boot Guard, la oss se på utførelsesmiljøene i Intel 64-arkitekturen, som i kombinasjon er røttene til tillit for denne pålitelige oppstartsteknologien.

Intel CPU

Cap antyder at prosessoren er hovedutførelsesmiljøet i Intel 64-arkitekturen. Hvorfor er det roten til tillit? Det viser seg at det som gjør ham slik er besittelsen av følgende elementer:

• Microcode ROM er et ikke-flyktig, ikke-overskrivbart minne for lagring av mikrokode. Det antas at mikrokode er implementeringen av prosessorkommandosystemet ved å bruke de enkleste instruksjonene. Skjer også i mikrokode feil. Så i BIOS kan du finne binærfiler med mikrokodeoppdateringer (overlagt under oppstart, siden ROM ikke kan overskrives). Innholdet i disse binære filene er kryptert, noe som i stor grad kompliserer analysen (derfor er det spesifikke innholdet i mikrokoden bare kjent for de som utvikler den), og signert for å kontrollere integritet og autentisitet;
• AES-nøkkel for å dekryptere innholdet i mikrokodeoppdateringer;
• hash av den offentlige RSA-nøkkelen som brukes til å bekrefte signaturen til mikrokodeoppdateringer;
• RSA public key hash, som verifiserer signaturen til Intel-utviklede ACM (Authenticated Code Module) kodemoduler, som CPU kan starte før BIOS-kjøring (hei mikrokode) eller under driften, når visse hendelser inntreffer.

Intel ME

Bloggen vår var dedikert til dette undersystemet две artikler. La oss huske at dette kjørbare miljøet er basert på en mikrokontroller innebygd i brikkesettet og er det mest skjulte og privilegerte i systemet.

Til tross for hemmelighold, er Intel ME også en rot av tillit fordi den har:

• ME ROM - ikke-flyktig, ikke-omskrivbart minne (ingen oppdateringsmetode er gitt) som inneholder startkoden, samt SHA256-hashen til den offentlige RSA-nøkkelen, som bekrefter signaturen til Intel ME-fastvaren;
• AES-nøkkel for lagring av hemmelig informasjon;
• tilgang til et sett med sikringer (FPF-er, feltprogrammerbare sikringer) integrert i brikkesettet for permanent lagring av noe informasjon, inkludert den som er spesifisert av datasystemleverandøren.

Intel Boot Guard 1.x

En liten ansvarsfraskrivelse. Versjonsnumrene for Intel Boot Guard-teknologien vi bruker i denne artikkelen er vilkårlige og kan ikke ha noe å gjøre med nummereringen som brukes i Intels interne dokumentasjon. I tillegg ble informasjonen som er gitt her om implementeringen av denne teknologien innhentet under omvendt utvikling, og kan inneholde unøyaktigheter sammenlignet med spesifikasjonen for Intel Boot Guard, som neppe noen gang vil bli publisert.

Så Intel Boot Guard (BG) er en maskinvarestøttet UEFI BIOS-autentiseringsverifiseringsteknologi. Etter den korte beskrivelsen i boken [Platform Embedded Security Technology Revealed, kapittel Boot with Integrity, or Not Boot], fungerer den som en pålitelig oppstartskjede. Og den første lenken i den er oppstartskoden (mikrokoden) inne i CPUen, som utløses av RESET-hendelsen (ikke å forveksle med RESET-vektoren i BIOS!). CPUen finner en kodemodul utviklet og signert av Intel (Intel BG oppstart ACM) på SPI-flashminnet, laster den inn i hurtigbufferen, verifiserer (det ble allerede bemerket ovenfor at CPUen har en hash av den offentlige nøkkelen som bekrefter ACM signatur) og lanseringer.

Denne kodemodulen er ansvarlig for å verifisere en liten startdel av UEFI BIOS - Initial Boot Block (IBB), som igjen inneholder funksjonalitet for å verifisere hoveddelen av UEFI BIOS. Dermed lar Intel BG deg verifisere autentisiteten til BIOS før du laster inn operativsystemet (som kan utføres under tilsyn av Secure Boot-teknologi).

Intel BG-teknologi gir to driftsmoduser (og den ene forstyrrer ikke den andre, dvs. begge modusene kan aktiveres på systemet, eller begge kan deaktiveres).

Målt støvel

I Measured Boot (MB)-modus "måler" hver oppstartskomponent (som starter med CPU-oppstarts-ROMen) den neste ved å bruke egenskapene til TPM (Trusted Platform Module). For de som ikke vet, la meg forklare.

TPM har PCR-er (Platform Configuration Registers), som resultatet av hashing-operasjonen skrives inn i i henhold til formelen:

De. gjeldende PCR-verdi avhenger av den forrige, og disse registrene tilbakestilles kun når systemet er RESET.

I MB-modus reflekterer PCR-er på et eller annet tidspunkt en unik (innenfor mulighetene for hashing-operasjonen) identifikator for koden eller dataene som ble "målt". PCR-verdier kan brukes i enkelte datakryptering (TPM_Seal) operasjoner. Etter dette vil dekrypteringen deres (TPM_Unseal) bare være mulig hvis PCR-verdiene ikke endret seg som et resultat av lasting (dvs. ikke en eneste "målt" komponent ble modifisert).

Verifisert oppstart

Det verste for de som liker å endre UEFI BIOS er Verified Boot (VB)-modus, der hver oppstartskomponent kryptografisk verifiserer integriteten og autentisiteten til den neste. Og i tilfelle en bekreftelsesfeil skjer (en av):

• avslutning etter tidsavbrudd fra 1 minutt til 30 minutter (slik at brukeren har tid til å forstå hvorfor datamaskinen ikke starter opp, og om mulig prøver å gjenopprette BIOS);
• umiddelbar avslutning (slik at brukeren ikke har tid til å forstå, langt mindre gjøre, noe);
• fortsette å jobbe med et rolig uttrykk (det tilfellet når det ikke er tid til sikkerhet, fordi det er viktigere ting å gjøre).

Valget av handling avhenger av den spesifiserte Intel BG-konfigurasjonen (nemlig på den såkalte håndhevingspolicyen), som registreres permanent av datamaskinplattformleverandøren i en spesialdesignet lagring - brikkesettsikringer (FPFs). Vi vil dvele ved dette punktet mer detaljert senere.

I tillegg til konfigurasjonen, genererer leverandøren to RSA 2048-nøkler og oppretter to datastrukturer (vist i figuren):

1. Leverandørens rotnøkkelmanifest (KEYM, OEM Root Key Manifest), som inneholder SVN (sikkerhetsversjonsnummer) til dette manifestet, SHA256-hashen til den offentlige nøkkelen til det neste manifestet, den offentlige RSA-nøkkelen (dvs. den offentlige delen av leverandørens rotnøkkel) for å bekrefte signaturen til dette manifestet og selve signaturen;
2. IBB Manifest (IBBM, Initial Boot Block Manifest), som inneholder SVN til dette manifestet, SHA256-hashen til IBB, den offentlige nøkkelen for å bekrefte signaturen til dette manifestet og selve signaturen.

SHA256-hashen til OEM Root Key offentlige nøkkel registreres permanent i brikkesettsikringer (FPF-er), akkurat som Intel BG-konfigurasjonen. Hvis Intel BG-konfigurasjonen sørger for inkludering av denne teknologien, kan fra nå av bare eieren av den private delen av OEM Root Key oppdatere BIOS på dette systemet (dvs. være i stand til å beregne disse manifestene på nytt), dvs. Leverandør.

Når man ser på bildet, oppstår det umiddelbart tvil om behovet for en så lang verifiseringskjede - de kunne ha brukt ett manifest. Hvorfor komplisere ting?

Faktisk gir Intel dermed leverandøren muligheten til å bruke forskjellige IBB-nøkler for forskjellige linjer av sine produkter og en som rotnøkkel. Hvis den private delen av IBB-nøkkelen (som det andre manifestet er signert) lekker, vil hendelsen påvirke bare én produktlinje og bare inntil leverandøren genererer et nytt par og inkluderer de omkalkulerte manifestene i neste BIOS-oppdatering.

Men hvis rotnøkkelen (som det første manifestet er signert) er kompromittert, vil det ikke være mulig å erstatte den; det er ingen tilbakekallingsprosedyre. hashen til den offentlige delen av denne nøkkelen programmeres inn i FPF en gang for alle.

Intel Boot Guard-konfigurasjon

La oss nå se nærmere på Intel BG-konfigurasjonen og prosessen med å lage den. Hvis du ser på den tilsvarende fanen i GUI-en til Flash Image Tool-verktøyet fra Intel System Tool Kit (STK), vil du legge merke til at Intel BG-konfigurasjonen inkluderer en hash av den offentlige delen av leverandørens rotnøkkel, et par uklare verdier osv. Intel BG-profil.

Strukturen til denne profilen:

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

Generelt er Intel BG-konfigurasjonen en veldig fleksibel enhet. Tenk for eksempel på Force_Boot_Guard_ACM-flagget. Når den fjernes, hvis BG-oppstarts-ACM-modulen på SPI-flashen ikke blir funnet, vil ingen pålitelig oppstart forekomme. Hun vil ikke stole på.

Vi skrev allerede ovenfor at håndhevelsespolicyen for VB-modus kan konfigureres slik at hvis det er en bekreftelsesfeil, vil en upålitelig nedlasting skje.

La slike ting stå etter leverandørenes skjønn...

GUI-verktøyet gir følgende "ferdige" profiler:

Nei.
regime
beskrivelse

0
No_FVME
Intel BG-teknologi deaktivert

1
VE
VB-modus er aktivert, avstengning etter tidsavbrudd

2
VME-utvidelse
begge modusene er aktivert (VB og MB), avstengning etter tidsavbrudd

3
VM
begge modusene er aktivert, uten å slå av systemet

4
FVE
VB-modus aktivert, umiddelbar avslutning

5
FVME
begge modusene aktivert, umiddelbar avstengning

Som allerede nevnt, må Intel BG-konfigurasjonen skrives en gang for alle av systemleverandøren i brikkesettsikringer (FPFs) - en liten (ifølge uverifisert informasjon, kun 256 byte) maskinvarelagring av informasjon inne i brikkesettet, som kan programmeres utenfor Intels produksjonsanlegg (det er nettopp derfor Feltprogrammerbar Sikringer).

Den er flott for å lagre konfigurasjon fordi:

• har et engangsprogrammerbart område for lagring av data (akkurat der Intel BG-konfigurasjonen er skrevet);
• Bare Intel ME kan lese og programmere den.

Så for å sette konfigurasjonen for Intel BG-teknologi på et spesifikt system, gjør leverandøren følgende under produksjonen:

1. Ved å bruke Flash Image Tool-verktøyet (fra Intel STK) lager det et fastvarebilde med en gitt Intel BG-konfigurasjon i form av variabler innenfor Intel ME-regionen (det såkalte midlertidige speilet for FPF-er);
2. Ved å bruke Flash Programming Tool-verktøyet (fra Intel STK), skriver den dette bildet til systemets SPI-flashminne og lukker den såkalte. produksjonsmodus (i dette tilfellet sendes den tilsvarende kommandoen til Intel ME).

Som et resultat av disse operasjonene vil Intel ME forplikte de angitte verdiene fra speilet for FPF-er i ME-regionen til FPF-er, sette oppløsningene i SPI-flash-beskrivelser til verdiene anbefalt av Intel (beskrevet i begynnelsen av artikkel) og utfør en systemtilbakestilling.

Analyse av Intel Boot Guard-implementering

For å analysere implementeringen av denne teknologien ved å bruke et spesifikt eksempel, sjekket vi følgende systemer for spor av Intel BG-teknologi:

System
Note

Gigabyte GA-H170-D3H
Skylake, det er støtte

Gigabyte GA-Q170-D3H
Skylake, det er støtte

Gigabyte GA-B150-HD3
Skylake, det er støtte

MSI H170A Gaming Pro
Skylake, ingen støtte

Lenovo ThinkPad 460
Skylake, støttet, teknologi aktivert

Lenovo Yoga 2 Pro
Haswell, ingen støtte

Lenovo U330p
Haswell, ingen støtte

Med "støtte" mener vi tilstedeværelsen av Intel BG oppstart ACM-modulen, manifestene nevnt ovenfor og den tilsvarende koden i BIOS, dvs. implementering for analyse.

Som et eksempel, la oss ta den som er lastet ned fra kontoret. leverandørens nettstedsbilde av SPI-flashminne for Gigabyte GA-H170-D3H (versjon F4).

Intel CPU boot ROM

Først av alt, la oss snakke om handlingene til prosessoren hvis Intel BG-teknologi er aktivert.

Det var ikke mulig å finne eksempler på dekryptert mikrokode, så hvordan handlingene beskrevet nedenfor er implementert (i mikrokode eller maskinvare) er et åpent spørsmål. Imidlertid er det et faktum at moderne Intel-prosessorer "kan" utføre disse handlingene.

Etter å ha gått ut av RESET-tilstanden, finner prosessoren (innholdet i flashminnet er allerede kartlagt i adresserommet) FIT-tabellen (Firmware Interface Table). Det er lett å finne; pekeren til det er skrevet på adressen FFFF FFC0h.

I eksemplet under vurdering er verdien FFD6 9500h plassert på denne adressen. Ved å få tilgang til denne adressen ser prosessoren FIT-tabellen, hvis innhold er delt inn i poster. Den første oppføringen er overskriften til følgende 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 en eller annen ukjent grunn beregnes ikke alltid kontrollsummen i disse tabellene (feltet står null igjen).

De resterende oppføringene peker på ulike binærfiler som må analyseres/utføres før BIOS kjøres, dvs. før du bytter til den eldre RESET-vektoren (FFFF FFF0h). Strukturen for hver slik oppføring 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;
};

EntryType-feltet forteller deg hvilken type blokk denne oppføringen peker til. Vi kjenner 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
};

Nå er det åpenbart at en av oppføringene peker på plasseringen av Intel BG oppstart ACM binær. Overskriftsstrukturen til denne binære filen er typisk for kodemoduler utviklet av Intel (ACM-er, mikrokodeoppdateringer, Intel ME-kodeseksjoner, ...).

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

Prosessoren laster denne binære filen inn i cachen sin, verifiserer den og kjører den.

Intel BG oppstart ACM

Som et resultat av å analysere arbeidet til denne ACM, ble det klart at den gjør følgende:

• mottar Intel BG-konfigurasjonen fra Intel ME, skrevet inn i brikkesettsikringer (FPFer);
• finner KEYM og IBBM manifesterer og verifiserer dem.

For å finne disse manifestene bruker ACM også FIT-tabellen, som har to oppføringstyper for å indikere strukturdata (se FIT_ENTRY_TYPES ovenfor).

La oss se nærmere på manifester. I strukturen til det første manifestet ser vi flere obskure konstanter, en hash av den offentlige nøkkelen fra det andre manifestet, og den offentlige OEM Root Key signert som en nestet 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];
};

For å verifisere den offentlige OEM Root Key-nøkkelen husker vi at vi bruker SHA256-hash av sikringer, som på dette tidspunktet allerede er mottatt fra Intel ME.

La oss gå videre til det andre 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ørste inneholder noen 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 andre inneholder SHA256-hashen til IBB og antall beskrivelser som beskriver innholdet i IBB (dvs. hva hashen beregnes ut 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 of an IBB
	unsigned char  NumIbbDescriptors;
};

IBB-beskrivelsene følger denne strukturen, den ene etter den andre. Innholdet deres har følgende format:

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

Det er enkelt: hver deskriptor inneholder adressen/størrelsen til IBB-delen. Sammenkoblingen av blokkene pekt på av disse deskriptorene (i rekkefølgen av deskriptorene selv) er derfor IBB. Og som regel er IBB samlingen av alle moduler i SEC- og PEI-fasene.

Det andre manifestet fullføres av en struktur som inneholder den offentlige IBB-nøkkelen (verifisert av SHA256-hashen fra det første manifestet) og signaturen til dette manifestet:

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

Så selv før UEFI BIOS begynner å kjøre, vil prosessoren starte ACM, som vil bekrefte ektheten av innholdet i seksjonene med SEC- og PEI-fasekoden. Deretter går prosessoren ut av ACM, følger RESET-vektoren og begynner å kjøre BIOS.

Den bekreftede PEI-partisjonen må inneholde en modul som vil sjekke resten av BIOS (DXE-kode). Denne modulen er allerede under utvikling av IBV (Independent BIOS Vendor) eller systemleverandøren selv. Fordi Bare Lenovo- og Gigabyte-systemer sto til vår disposisjon og hadde Intel BG-støtte; la oss se på koden hentet fra disse systemene.

UEFI BIOS-modul LenovoVerifiedBootPei

Når det gjelder Lenovo, viste det seg å være LenovoVerifiedBootPei-modulen {B9F2AC77-54C7-4075-B42E-C36325A9468D}, utviklet av Lenovo.

Dens jobb er å slå opp (ved GUID) hash-tabellen for DXE og verifisere 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 gjelder Gigabyte, viste det seg å være BootGuardPei-modulen {B41956E1-7CA2-42DB-9562-168389F0F066}, utviklet av AMI, og derfor til stede i enhver AMI BIOS med Intel BG-støtte.

Driftsalgoritmen er noe annerledes, men den koker ned til 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} den leter etter 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

La oss kort snakke om en annen implementering av Intel Boot Guard, som ble funnet i et nyere system basert på Intel SoC med Apollo Lake mikroarkitektur - ASRock J4205-IT.

Selv om denne versjonen bare vil bli brukt i SoC-er (nye systemer med Kaby Lake-prosessormikroarkitektur fortsetter å bruke Intel Boot Guard 1.x), er det av stor interesse å studere det nye arkitekturalternativet for Intel SoC-plattformer, som har sett betydelige endringer, for eksempel:

• BIOS- og Intel ME-regionene (eller snarere Intel TXE, ifølge terminologien for Intel SoC) er nå én IFWI-region;
• Selv om Intel BG var aktivert på plattformen, ble strukturer som FIT, KEYM, IBBM ikke funnet i flash-minnet;
• i tillegg til TXE- og ISH-kjernene (x86), ble en tredje kjerne lagt til brikkesettet (ARC igjen, forresten) - PMC (Power Management Controller), assosiert med å sikre driften av kraftundersystemet og ytelsesovervåking.

Innholdet i den nye IFWI-regionen er et sett med følgende moduler:

Partiskhet
navn
beskrivelse

0000 2000 timer
SMIP
en bestemt plattformkonfigurasjon, signert av leverandøren

0000 6000 timer
RBEP
Intel TXE-fastvarekodedel, x86, signert Intel

0001 0000 timer
PMCP
Intel PMC firmware kodeseksjon, ARC, signert Intel

0002 0000 timer
FTPR
Intel TXE-fastvarekodedel, x86, signert Intel

0007 B000h
UCOD
mikrokodeoppdateringer for CPU, signert av Intel

0008 0000 timer
IBBP
UEFI BIOS, SEC/PEI-faser, x86, signert av leverandøren

0021 8000 timer
ISHC
Intel ISH-fastvarekodedel, x86, signert av leverandøren

0025 8000 timer
NFTP
Intel TXE-fastvarekodedel, x86, signert Intel

0036 1000 timer
IUNP
ukjent

0038 1000 timer
OBBP
UEFI BIOS, DXE phase, x86, usignert

Under analysen av TXE-fastvaren ble det åpenbart at etter en RESET holder TXE prosessoren i denne tilstanden til den forbereder det grunnleggende innholdet i adresserommet for CPU (FIT, ACM, RESET vektor ...). Dessuten plasserer TXE disse dataene i sin SRAM, hvoretter den midlertidig gir prosessoren tilgang der og "frigir" dem fra RESET.

På vakt mot rootkits

Vel, la oss nå gå videre til de "varme" tingene. Vi oppdaget en gang at på mange systemer inneholder SPI-flash-beskrivelser tillatelser til å få tilgang til områder av SPI-flashminne, slik at alle brukere av dette minnet kan skrive og lese hvilken som helst region. De. aldri.

Etter å ha sjekket med MEinfo-verktøyet (fra Intel STK), så vi at produksjonsmodusen på disse systemene ikke er lukket, derfor er brikkesettsikringene (FPF-er) i en udefinert tilstand. Ja, Intel BG er verken slått på eller av i slike tilfeller.

Vi snakker om følgende systemer (med hensyn til Intel BG og det som vil bli beskrevet senere i artikkelen, vil vi snakke om systemer med Haswell-prosessormikroarkitektur og høyere):

• alle Gigabyte produkter;
• alle MSI-produkter;
• 21 modeller av Lenovo bærbare datamaskiner og 4 modeller av Lenovo-servere.

Selvfølgelig rapporterte vi oppdagelsen til disse leverandørene, så vel som til Intel.

En tilstrekkelig reaksjon kom bare fra Lenovosom kjente igjen problemet og har gitt ut en patch.

Gigabyte De så ut til å akseptere informasjonen om sårbarheten, men kommenterte ikke på noen måte.

Kommunikasjon med MSI stoppet fullstendig på vår forespørsel om å sende din offentlige PGP-nøkkel (for å sende dem en sikkerhetsinformasjon i kryptert form). De uttalte at de "er en maskinvareprodusent og produserer ikke PGP-nøkler."

Men la oss komme til poenget. Siden sikringene blir stående i en uspesifisert tilstand, kan brukeren (eller angriperen) programmere dem uavhengig (det vanskeligste er finn Intel STK). For å gjøre dette, må du fullføre følgende trinn.

1. Start opp i Windows OS (vanligvis kan handlingene beskrevet nedenfor også gjøres under Linux, hvis du utvikler en analog av Intel STK for ønsket OS). Ved å bruke MEinfo-verktøyet, sørg for at sikringer ikke er programmert på dette systemet.

2. Les innholdet i flash-minnet ved å bruke Flash-programmeringsverktøyet.

3. Åpne lesebildet ved å bruke et hvilket som helst UEFI BIOS-redigeringsverktøy, gjør de nødvendige endringene (introduser for eksempel et rootkit), lag/rediger eksisterende KEYM- og IBBM-strukturer i ME-regionen.

Bildet fremhever den offentlige delen av RSA-nøkkelen, hvis hash vil bli programmert inn i brikkesettets sikringer sammen med resten av Intel BG-konfigurasjonen.

4. Bruk Flash Image Tool, bygg et nytt fastvarebilde (ved å angi Intel BG-konfigurasjonen).

5. Skriv et nytt bilde til flash-minnet ved hjelp av Flash-programmeringsverktøyet, kontroller ved hjelp av MEinfo at ME-regionen nå inneholder Intel BG-konfigurasjonen.

6. Bruk Flash-programmeringsverktøyet for å lukke produksjonsmodus.

7. Systemet vil starte på nytt, hvoretter du kan bruke MEinfo for å bekrefte at FPF-ene nå er programmert.

Disse handlingene for alltid aktiver Intel BG på dette systemet. Handlingen kan ikke angres, noe som betyr:

• Bare eieren av den private delen av rotnøkkelen (dvs. den som aktiverte Intel BG) vil kunne oppdatere UEFI BIOS på dette systemet;
• hvis du returnerer den originale fastvaren til dette systemet, for eksempel ved hjelp av en programmerer, vil den ikke en gang slå seg på (en konsekvens av håndhevelsespolicyen i tilfelle en verifikasjonsfeil);
• for å bli kvitt en slik UEFI BIOS, må du bytte ut brikkesettet med programmerte FPF-er med en "ren" (dvs. omlodde brikkesettet hvis du har tilgang til en infrarød loddestasjon til prisen for en bil, eller ganske enkelt bytte ut hovedkortet ).

For å forstå hva et slikt rootkit kan gjøre, må du vurdere hva som gjør det mulig å kjøre koden din i UEFI BIOS-miljøet. La oss si, i den mest privilegerte prosessormodus - SMM. Et slikt rootkit kan ha følgende egenskaper:

• utføres parallelt med OS (du kan konfigurere behandling for å generere et SMI-avbrudd, som vil bli utløst av en timer);
• har alle fordelene ved å være i SMM-modus (full tilgang til innholdet i RAM og maskinvareressurser, hemmelighold fra OS);
• Rootkittets programkode kan krypteres og dekrypteres når den startes i SMM-modus. Alle data som bare er tilgjengelige i SMM-modus kan brukes som en krypteringsnøkkel. For eksempel en hash fra et sett med adresser i SMRAM. For å få denne nøkkelen, må du gå inn i SMM. Og dette kan gjøres på to måter. Finn RCE i SMM-koden og utnytte den, eller legg til din egen SMM-modul i BIOS, noe som er umulig siden vi aktiverte Boot Guard.

Dermed lar denne sårbarheten en angriper:

• lage et skjult, uutlettbart rootkit med ukjent formål i systemet;
• kjør koden din på en av brikkesettkjernene inne i Intel SoC, nemlig på Intel ISH (ta en nøye titt på bildet).

Selv om egenskapene til Intel ISH-delsystemet ennå ikke er utforsket, ser det ut til å være en interessant angrepsvektor for Intel ME.

Funn

1. Studien gjorde det mulig å få en teknisk beskrivelse av driften av Intel Boot Guard-teknologi. Minus et par hemmeligheter i Intels sikkerhet gjennom obscurity-modell.
2. Et angrepsscenario presenteres som lar deg lage et avinstallerbart rootkit i systemet.
3. Vi så at moderne Intel-prosessorer er i stand til å kjøre mye proprietær kode selv før BIOS begynner å kjøre.
4. Plattformer med Intel 64-arkitektur blir mindre og mindre egnet for å kjøre gratis programvare: maskinvareverifisering, et økende antall proprietære teknologier og undersystemer (tre kjerner i SoC-brikkesettet: x86 ME, x86 ISH og ARC PMC).

Begrensninger

Leverandører som med vilje lar produksjonsmodus være åpen, bør sørge for å lukke den. Foreløpig er det bare øynene deres som er lukket, og det viser de nye Kaby Lake-systemene.

Brukere kan deaktivere Intel BG på systemene sine (som er utsatt for den beskrevne sårbarheten) ved å kjøre Flash-programmeringsverktøyet med parameteren -closemnf. Først bør du sørge for (ved å bruke MEinfo) at Intel BG-konfigurasjonen i ME-regionen sørger for å slå av denne teknologien etter programmering i FPF-er.

Kilde: www.habr.com