Schrödinger's vertrouwde download. Intel Bootguard

We stellen voor om weer naar een laag niveau te gaan en te praten over de beveiliging van firmware voor x86-compatibele computerplatforms. Deze keer is het belangrijkste ingrediënt van het onderzoek Intel Boot Guard (niet te verwarren met Intel BIOS Guard!) - een door hardware ondersteunde vertrouwde BIOS-opstarttechnologie die de leverancier van het computersysteem tijdens de productiefase permanent kan in- of uitschakelen. Welnu, het onderzoeksrecept is ons al bekend: snijd de implementatie van deze technologie in dunne plakjes met behulp van reverse engineering, beschrijf de architectuur ervan, vul deze met ongedocumenteerde details, breng hem op smaak met aanvalsvectoren om te proeven en te mixen. Laten we brandstof toevoegen aan het verhaal over hoe een bug die jarenlang is gekloond in de productie van verschillende leveranciers, een potentiële aanvaller in staat stelt deze technologie te gebruiken om een ​​verborgen rootkit in het systeem te creëren die niet kan worden verwijderd (zelfs niet met een programmeur).

Het artikel is overigens gebaseerd op de rapporten “On Guard of Rootkits: Intel BootGuard” van de conferentie ZeroNights 2016 en 29e bijeenkomst DefCon Rusland (beide presentaties hier).

Firmware voor een computerplatform met Intel 64-architectuur

Laten we eerst de vraag beantwoorden: wat is de firmware van een modern computerplatform met Intel 64-architectuur? Natuurlijk, UEFI BIOS. Maar zo'n antwoord zal niet accuraat zijn. Laten we eens kijken naar de afbeelding, die de desktopversie (laptop) van deze architectuur laat zien.

De basis is de link:

• Processor (CPU, Central Processing Unit), die naast de hoofdkernen een ingebouwde grafische kern heeft (niet in alle modellen) en een geheugencontroller (IMC, Integrated Memory Controller);
• Chipset (PCH, Platform Controller Hub), met daarin verschillende controllers voor interactie met randapparatuur en het beheren van subsystemen. Daaronder bevindt zich de bekende Intel Management Engine (ME), die ook over firmware beschikt (Intel ME-firmware).

Laptops hebben, naast het bovenstaande, een ingebouwde controller nodig (ACPI EC, Advanced Control en Power Interface Embedded Controller), die verantwoordelijk is voor de werking van het voedingssubsysteem, touchpad, toetsenbord, Fn-toetsen (schermhelderheid, geluidsvolume , toetsenbordverlichting, enz.) en andere dingen. En het heeft ook zijn eigen firmware.

Het geheel van de bovenstaande firmware is dus de firmware van het computerplatform (systeemfirmware), die is opgeslagen op een gemeenschappelijk SPI-flashgeheugen. Om ervoor te zorgen dat gebruikers van dit geheugen niet in verwarring raken over waar het zich bevindt, is de inhoud van dit geheugen verdeeld in de volgende regio's (zoals weergegeven in de afbeelding):

• UEFI BIOS;
• ACPI EC-firmware (een aparte regio verscheen met de Skylake-processormicroarchitectuur (2015), maar in het wild hebben we nog geen voorbeelden van het gebruik ervan gezien, dus de firmware van de ingebouwde controller is nog steeds opgenomen in het UEFI BIOS) ;
• Intel ME-firmware;
• configuratie (MAC-adres, etc.) van de ingebouwde GbE (Gigabit Ethernet) netwerkadapter;
• Flash-descriptors zijn de belangrijkste regio van het flash-geheugen die verwijzingen naar andere regio's bevatten, evenals machtigingen om deze te openen.

De SPI-busmaster, een in de chipset ingebouwde SPI-controller waarmee toegang wordt verkregen tot dit geheugen, is verantwoordelijk voor het afbakenen van de toegang tot regio's (in overeenstemming met de opgegeven machtigingen). Als de machtigingen zijn ingesteld op de door Intel aanbevolen (om veiligheidsredenen) waarden, heeft elke SPI-flashgebruiker alleen volledige toegang (lezen/schrijven) tot zijn regio. En de rest is alleen-lezen of ontoegankelijk. Een bekend feit: op veel systemen heeft de CPU volledige toegang tot het UEFI BIOS en GbE, alleen leestoegang tot flash-descriptors en helemaal geen toegang tot de Intel ME-regio. Waarom bij velen, en niet bij allemaal? Wat wordt aanbevolen, is niet vereist. We zullen u verderop in het artikel meer in detail vertellen.

Mechanismen voor het beschermen van computerplatformfirmware tegen wijziging

Het is duidelijk dat de firmware van een computerplatform moet worden beschermd tegen mogelijke compromissen, waardoor een potentiële aanvaller er voet aan de grond kan krijgen (OS-updates/herinstallaties kan overleven), zijn code in de meest bevoorrechte modi kan uitvoeren, enz. En het beperken van de toegang tot SPI-flashgeheugenregio's is uiteraard niet voldoende. Om de firmware tegen wijzigingen te beschermen, worden daarom verschillende mechanismen gebruikt die specifiek zijn voor elke besturingsomgeving.

De Intel ME-firmware is dus ondertekend om de integriteit en authenticiteit te controleren, en wordt door de ME-controller gecontroleerd telkens wanneer deze in het ME UMA-geheugen wordt geladen. Dit verificatieproces is door ons al besproken in een van artikels, speciaal voor het Intel ME-subsysteem.

En ACPI EC-firmware wordt in de regel alleen op integriteit gecontroleerd. Omdat dit binaire bestand echter is opgenomen in het UEFI BIOS, is het vrijwel altijd onderworpen aan dezelfde beveiligingsmechanismen die het UEFI BIOS gebruikt. Laten we over hen praten.

Deze mechanismen kunnen in twee categorieën worden verdeeld.

Schrijfbeveiliging in de UEFI BIOS-regio

1. Fysieke bescherming van de inhoud van SPI-flashgeheugen met een schrijfbeveiligingsjumper;
2. Bescherming van de projectie van de UEFI BIOS-regio in de CPU-adresruimte met behulp van PRx-chipsetregisters;
3. Het blokkeren van pogingen om naar de UEFI BIOS-regio te schrijven door de overeenkomstige SMI-interrupt te genereren en te verwerken door de BIOS_WE/BLE- en SMM_BWP-bits in de chipsetregisters in te stellen;
4. Een meer geavanceerde versie van deze bescherming is Intel BIOS Guard (PFAT).

Naast deze mechanismen kunnen leveranciers hun eigen beveiligingsmaatregelen ontwikkelen en implementeren (bijvoorbeeld het ondertekenen van capsules met UEFI BIOS-updates).

Het is belangrijk op te merken dat op een specifiek systeem (afhankelijk van de leverancier) mogelijk niet alle bovengenoemde beschermingsmechanismen worden toegepast, dat ze helemaal niet worden toegepast, of dat ze op een kwetsbare manier worden geïmplementeerd. U kunt meer lezen over deze mechanismen en de situatie bij de implementatie ervan in dit artikel. Voor geïnteresseerden raden we u aan de hele reeks artikelen over UEFI BIOS-beveiliging te lezen CodeRush.

UEFI BIOS-authenticatie

Als we het hebben over vertrouwde opstarttechnologieën, is Secure Boot het eerste dat in ons opkomt. Architectonisch gezien is het echter ontworpen om de authenticiteit te verifiëren van componenten buiten het UEFI BIOS (stuurprogramma's, bootloaders, enz.), en niet van de firmware zelf.

Daarom implementeerde Intel in SoC's met Bay Trail-microarchitectuur (2012) een hardwarematige niet-uitgeschakelde Secure Boot (Verified Boot), die niets gemeen heeft met de bovengenoemde Secure Boot-technologie. Later (2013) werd dit mechanisme verbeterd en uitgebracht onder de naam Intel Boot Guard voor desktops met Haswell-microarchitectuur.

Voordat we Intel Boot Guard beschrijven, kijken we eerst naar de uitvoeringsomgevingen in de Intel 64-architectuur, die, in combinatie, de wortels van vertrouwen vormen voor deze vertrouwde opstarttechnologie.

Intel CPU

Cap suggereert dat de processor de belangrijkste uitvoeringsomgeving is in de architectuur van Intel 64. Waarom is dit de wortel van vertrouwen? Het blijkt dat wat hem zo maakt het bezit van de volgende elementen is:

• Microcode-ROM is een niet-vluchtig, niet-herschrijfbaar geheugen voor het opslaan van microcode. Er wordt aangenomen dat microcode de implementatie is van het processorbevelsysteem met behulp van de eenvoudigste instructies. Gebeurt ook in microcode insecten. In het BIOS kun je dus binaire bestanden vinden met microcode-updates (overlay tijdens het opstarten, omdat ROM niet kan worden overschreven). De inhoud van deze binaire bestanden is gecodeerd, wat de analyse enorm bemoeilijkt (daarom is de specifieke inhoud van de microcode alleen bekend bij degenen die deze ontwikkelen), en ondertekend om de integriteit en authenticiteit te controleren;
• AES-sleutel voor het decoderen van de inhoud van microcode-updates;
• hash van de openbare RSA-sleutel die wordt gebruikt om de handtekening van microcode-updates te verifiëren;
• RSA public key hash, die de handtekening verifieert van door Intel ontwikkelde ACM-codemodules (Authenticated Code Module), die de CPU kan starten vóór BIOS-uitvoering (hallo microcode) of tijdens de werking ervan, wanneer bepaalde gebeurtenissen plaatsvinden.

Intel ME

Onze blog was gewijd aan dit subsysteem две Artikel. Laten we niet vergeten dat deze uitvoerbare omgeving gebaseerd is op een microcontroller die in de chipset is ingebouwd en de meest verborgen en bevoorrechte in het systeem is.

Ondanks zijn geheimhouding is Intel ME ook een bron van vertrouwen, omdat het:

• ME ROM - niet-vluchtig, niet-herschrijfbaar geheugen (er is geen updatemethode voorzien) met de startcode, evenals de SHA256-hash van de openbare RSA-sleutel, die de handtekening van de Intel ME-firmware verifieert;
• AES-sleutel voor het opslaan van geheime informatie;
• toegang tot een set zekeringen (FPF's, Field Programmable Fuses) geïntegreerd in de chipset voor permanente opslag van bepaalde informatie, inclusief de informatie gespecificeerd door de leverancier van het computersysteem.

Intel Boot Guard 1.x

Een kleine disclaimer. De versienummers van de Intel Boot Guard-technologie die we in dit artikel gebruiken, zijn willekeurig en hebben mogelijk niets te maken met de nummering die wordt gebruikt in de interne documentatie van Intel. Bovendien is de hier verstrekte informatie over de implementatie van deze technologie verkregen tijdens reverse engineering en kan deze onnauwkeurigheden bevatten in vergelijking met de specificatie voor Intel Boot Guard, die waarschijnlijk nooit zal worden gepubliceerd.

Intel Boot Guard (BG) is dus een door hardware ondersteunde UEFI BIOS-authenticatieverificatietechnologie. Afgaande op de korte beschrijving in het boek [Platform Embedded Security Technology Revealed, chapter Boot with Integrity, or Not Boot], werkt het als een vertrouwde opstartketen. En de eerste link daarin is de opstartcode (microcode) in de CPU, die wordt geactiveerd door de RESET-gebeurtenis (niet te verwarren met de RESET-vector in het BIOS!). De CPU vindt een codemodule ontwikkeld en ondertekend door Intel (Intel BG startup ACM) op het SPI-flashgeheugen, laadt deze in de cache, verifieert (hierboven werd al opgemerkt dat de CPU een hash heeft van de openbare sleutel die de ACM verifieert handtekening) en begint.

Deze codemodule is verantwoordelijk voor het verifiëren van een klein startgedeelte van het UEFI BIOS - Initial Boot Block (IBB), dat op zijn beurt functionaliteit bevat voor het verifiëren van het hoofdgedeelte van het UEFI BIOS. Met Intel BG kunt u dus de authenticiteit van het BIOS verifiëren voordat u het besturingssysteem laadt (wat kan worden uitgevoerd onder toezicht van Secure Boot-technologie).

Intel BG-technologie biedt twee bedieningsmodi (en de ene interfereert niet met de andere, dat wil zeggen dat beide modi op het systeem kunnen worden ingeschakeld, of beide kunnen worden uitgeschakeld).

Gemeten laars

In de Measured Boot-modus (MB) 'meet' elke opstartcomponent (beginnend met het CPU-opstart-ROM) de volgende met behulp van de mogelijkheden van de TPM (Trusted Platform Module). Voor degenen die het niet weten, zal ik het uitleggen.

TPM beschikt over PCR’s (Platform Configuration Registers), waarin het resultaat van de hashing-operatie wordt geschreven volgens de formule:

Die. de huidige PCR-waarde is afhankelijk van de vorige, en deze registers worden alleen gereset als het systeem wordt gereset.

In de MB-modus weerspiegelen PCR’s dus op een bepaald moment een unieke (binnen de mogelijkheden van de hash-operatie) identificatiecode van de code of gegevens die ‘gemeten’ zijn. PCR-waarden kunnen worden gebruikt bij sommige gegevensversleuteling (TPM_Seal). Hierna zal hun decodering (TPM_Unseal) alleen mogelijk zijn als de PCR-waarden niet zijn veranderd als gevolg van het laden (dat wil zeggen dat er geen enkele "gemeten" component is gewijzigd).

Geverifieerd opstarten

Het ergste voor degenen die het UEFI BIOS willen wijzigen is de Verified Boot (VB)-modus, waarin elke opstartcomponent cryptografisch de integriteit en authenticiteit van de volgende verifieert. En in het geval van een verificatiefout gebeurt (een van) het volgende:

• afsluiten door time-out van 1 minuut tot 30 minuten (zodat de gebruiker tijd heeft om te begrijpen waarom zijn computer niet opstart en, indien mogelijk, probeert het BIOS te herstellen);
• onmiddellijke afsluiting (zodat de gebruiker geen tijd heeft om iets te begrijpen, laat staan ​​te doen);
• met een kalme uitdrukking blijven werken (dat geval waarin er geen tijd is voor veiligheid, omdat er belangrijkere dingen te doen zijn).

De keuze voor actie hangt af van de gespecificeerde Intel BG-configuratie (namelijk van het zogenaamde handhavingsbeleid), dat permanent wordt vastgelegd door de leverancier van het computerplatform in speciaal ontworpen opslag-chipsetzekeringen (FPF's). We zullen later meer in detail op dit punt ingaan.

Naast de configuratie genereert de leverancier twee RSA 2048-sleutels en creëert hij twee datastructuren (weergegeven in de afbeelding):

1. Het rootsleutelmanifest van de leverancier (KEYM, OEM Root Key Manifest), dat de SVN (Security Version Number) van dit manifest bevat, de SHA256-hash van de openbare sleutel van het volgende manifest, de openbare RSA-sleutel (d.w.z. het openbare deel van het manifest) root key van de leverancier) om de handtekening van dit manifest en de handtekening zelf te verifiëren;
2. IBB Manifest (IBBM, Initial Boot Block Manifest), dat de SVN van dit manifest, de SHA256-hash van IBB, de publieke sleutel voor het verifiëren van de handtekening van dit manifest en de handtekening zelf bevat.

De SHA256-hash van de openbare sleutel van de OEM Root Key wordt permanent vastgelegd in chipset-zekeringen (FPF's), net als de Intel BG-configuratie. Als de Intel BG-configuratie voorziet in de opname van deze technologie, kan vanaf nu alleen de eigenaar van het privégedeelte van de OEM Root Key het BIOS op dit systeem updaten (dat wil zeggen, deze manifesten opnieuw kunnen berekenen), d.w.z. leverancier.

Als je naar de foto kijkt, rijzen er meteen twijfels over de noodzaak van zo'n lange verificatieketen - ze hadden één manifest kunnen gebruiken. Waarom dingen ingewikkeld maken?

In feite biedt Intel de leverancier dus de mogelijkheid om verschillende IBB-sleutels te gebruiken voor verschillende productlijnen en één als root-sleutel. Als het privégedeelte van de IBB-sleutel (waarmee het tweede manifest wordt ondertekend) lekt, heeft het incident slechts invloed op één productlijn en alleen totdat de leverancier een nieuw paar genereert en de opnieuw berekende manifesten opneemt in de volgende BIOS-update.

Maar als de rootsleutel (waarmee het eerste manifest wordt ondertekend) in gevaar komt, zal het niet mogelijk zijn deze te vervangen; er is geen intrekkingsprocedure voorzien. de hash van het openbare deel van deze sleutel wordt voor eens en voor altijd in FPF geprogrammeerd.

Intel Boot Guard-configuratie

Laten we nu de Intel BG-configuratie en het proces om deze te maken eens nader bekijken. Als u naar het overeenkomstige tabblad in de GUI van het Flash Image Tool-hulpprogramma van de Intel System Tool Kit (STK) kijkt, zult u merken dat de Intel BG-configuratie een hash bevat van het openbare deel van de rootsleutel van de leverancier, een paar onduidelijke waarden etc. Intel BG-profiel.

De structuur van dit profiel:

typedef struct BG_PROFILE
{
	unsigned long Force_Boot_Guard_ACM : 1;
	unsigned long Verified_Boot : 1;
	unsigned long Measured_Boot : 1;
	unsigned long Protect_BIOS_Environment : 1;
	unsigned long Enforcement_Policy : 2; // 00b – do nothing
                                              // 01b – shutdown with timeout
                                              // 11b – immediate shutdown
	unsigned long : 26;
};

Over het algemeen is de Intel BG-configuratie een zeer flexibele entiteit. Denk bijvoorbeeld aan de vlag Force_Boot_Guard_ACM. Als het wordt verwijderd en de BG-opstart-ACM-module op de SPI-flash niet wordt gevonden, zal er geen vertrouwde opstart plaatsvinden. Ze zal niet vertrouwd worden.

We schreven hierboven al dat het handhavingsbeleid voor de VB-modus zo kan worden geconfigureerd dat als er een verificatiefout optreedt, er een niet-vertrouwde download zal plaatsvinden.

Laat zulke dingen over aan het oordeel van de verkopers...

Het GUI-hulpprogramma biedt de volgende kant-en-klare profielen:

nummer
regime
beschrijving

0
Geen_FVME
Intel BG-technologie uitgeschakeld

1
VE
VB-modus is ingeschakeld, uitgeschakeld door time-out

2
VME-extensie
beide modi zijn ingeschakeld (VB en MB), afsluiten door time-out

3
VM
beide modi zijn ingeschakeld, zonder het systeem uit te schakelen

4
FVE
VB-modus ingeschakeld, onmiddellijke uitschakeling

5
FVME
beide modi ingeschakeld, onmiddellijke uitschakeling

Zoals eerder vermeld moet de Intel BG-configuratie voor eens en voor altijd door de systeemleverancier worden geschreven in chipset-zekeringen (FPF's) - een kleine (volgens niet-geverifieerde informatie slechts 256 bytes) hardwareopslag van informatie in de chipset, die kan worden geprogrammeerd buiten de productiefaciliteiten van Intel (dat is precies waarom Veld programmeerbaar Zekeringen).

Het is geweldig voor het opslaan van configuraties omdat:

• heeft een eenmalig programmeerbaar gebied voor het opslaan van gegevens (precies waar de Intel BG-configuratie is geschreven);
• Alleen Intel ME kan het lezen en programmeren.

Om de configuratie voor Intel BG-technologie op een specifiek systeem in te stellen, doet de leverancier tijdens de productie dus het volgende:

1. Met behulp van het hulpprogramma Flash Image Tool (van Intel STK) wordt een firmware-image gemaakt met een bepaalde Intel BG-configuratie in de vorm van variabelen binnen de Intel ME-regio (de zogenaamde tijdelijke spiegel voor FPF's);
2. Met behulp van het hulpprogramma Flash Programming Tool (van Intel STK) schrijft het deze afbeelding naar het SPI-flashgeheugen van het systeem en sluit het zogenaamde. productiemodus (in dit geval wordt de overeenkomstige opdracht naar Intel ME verzonden).

Als gevolg van deze bewerkingen zal Intel ME de gespecificeerde waarden van de spiegel voor FPF's in de ME-regio vastleggen in FPF's, de resoluties in SPI-flashdescriptors instellen op de door Intel aanbevolen waarden (beschreven aan het begin van de artikel) en voer een systeem-RESET uit.

Analyse van de implementatie van Intel Boot Guard

Om de implementatie van deze technologie aan de hand van een specifiek voorbeeld te analyseren, hebben we de volgende systemen gecontroleerd op sporen van Intel BG-technologie:

Systeem
Noot

Gigabyte GA-H170-D3H
Skylake, er is steun

Gigabyte GA-Q170-D3H
Skylake, er is steun

Gigabyte GA-B150-HD3
Skylake, er is steun

MSI H170A GamingPro
Skylake, geen ondersteuning

Lenovo ThinkPad 460
Skylake, ondersteund, technologie ingeschakeld

Lenovo Yoga 2 Pro
Haswell, geen ondersteuning

Lenovo U330p
Haswell, geen ondersteuning

Met “ondersteuning” bedoelen we de aanwezigheid van de Intel BG opstart-ACM-module, de hierboven genoemde manifesten en de bijbehorende code in het BIOS, d.w.z. implementatie voor analyse.

Laten we als voorbeeld degene nemen die is gedownload van kantoor. afbeelding van de website van de leverancier van SPI-flashgeheugen voor Gigabyte GA-H170-D3H (versie F4).

Intel CPU-opstart-ROM

Laten we het eerst hebben over de acties van de processor als Intel BG-technologie is ingeschakeld.

Het was niet mogelijk om voorbeelden van gedecodeerde microcode te vinden, dus hoe de hieronder beschreven acties worden geïmplementeerd (in microcode of hardware) is een open vraag. Het is echter een feit dat moderne Intel-processors deze acties “kunnen” uitvoeren.

Na het verlaten van de RESET-status vindt de processor (de inhoud van het flashgeheugen is al in de adresruimte toegewezen) de FIT-tabel (Firmware Interface Table). Het is gemakkelijk te vinden; de verwijzing ernaar staat op adres FFFF FFC0h.

In het beschouwde voorbeeld bevindt zich op dit adres de waarde FFD6 9500h. Door toegang te krijgen tot dit adres ziet de processor de FIT-tabel, waarvan de inhoud is onderverdeeld in records. Het eerste item is de header van de volgende structuur:

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

Om een ​​onbekende reden wordt de controlesom in deze tabellen niet altijd berekend (het veld blijft nul).

De overige vermeldingen verwijzen naar verschillende binaire bestanden die moeten worden geparseerd/uitgevoerd voordat het BIOS wordt uitgevoerd, d.w.z. voordat u overschakelt naar de oudere RESET-vector (FFFF FFF0h). De structuur van elk van deze vermeldingen is als volgt:

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

Het veld EntryType vertelt u naar welk type blok dit item verwijst. We kennen verschillende soorten:

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

Nu is het duidelijk dat een van de vermeldingen verwijst naar de locatie van het Intel BG startup ACM binaire bestand. De headerstructuur van dit binaire bestand is typisch voor codemodules ontwikkeld door Intel (ACM's, microcode-updates, Intel ME-codesecties, ...).

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

De processor laadt dit binaire bestand in de cache, verifieert het en voert het uit.

Intel BG-startup ACM

Uit analyse van het werk van deze ACM is gebleken dat zij het volgende doet:

• ontvangt de Intel BG-configuratie van Intel ME, geschreven in chipsetzekeringen (FPF's);
• vindt KEYM- en IBM-manifesten en verifieert deze.

Om deze manifesten te vinden, gebruikt ACM ook de FIT-tabel, die twee invoertypen heeft om structuurgegevens aan te geven (zie FIT_ENTRY_TYPES hierboven).

Laten we de manifesten eens nader bekijken. In de structuur van het eerste manifest zien we verschillende obscure constanten, een hash van de publieke sleutel uit het tweede manifest, en de publieke OEM Root Key ondertekend als een geneste structuur:

typedef struct KEY_MANIFEST
{
	char           Tag[8];          // ‘__KEYM__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned char  : 8;             // 1
	unsigned short : 16;            // 0Bh
	unsigned short : 16;            // 20h == hash size?
	unsigned char  IbbmKeyHash[32]; // SHA256 of an IBBM public key
	BG_RSA_ENTRY   OemRootKey;
};

typedef struct BG_RSA_ENTRY
{
	unsigned char  : 8;             // 10h
	unsigned short : 16;            // 1
	unsigned char  : 8;             // 10h
	unsigned short RsaPubKeySize;   // 800h
	unsigned long  RsaPubExp;
	unsigned char  RsaPubKey[256];
	unsigned short : 16;            // 14
	unsigned char  : 8;             // 10h
	unsigned short RsaSigSize;      // 800h
	unsigned short : 16;            // 0Bh
	unsigned char  RsaSig[256];
};

Om de openbare sleutel van de OEM Root Key te verifiëren, herinneren we ons dat we de SHA256-hash van zekeringen gebruiken, die op dit moment al van Intel ME is ontvangen.

Laten we verder gaan met het tweede manifest. Het bestaat uit drie structuren:

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

De eerste bevat enkele constanten:

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

De tweede bevat de SHA256-hash van de IBB en het aantal descriptors die de inhoud van de IBB beschrijven (dat wil zeggen, waaruit de hash wordt berekend):

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

De IBB-descriptoren volgen deze structuur, de een na de ander. Hun inhoud heeft het volgende formaat:

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

Het is eenvoudig: elke descriptor bevat het adres/de grootte van het IBB-deel. De aaneenschakeling van de blokken waarnaar deze descriptoren verwijzen (in de volgorde van de descriptoren zelf) is dus IBB. En in de regel is IBB de verzameling van alle modules van de SEC- en PEI-fasen.

Het tweede manifest wordt gecompleteerd door een structuur die de openbare IBB-sleutel bevat (geverifieerd door de SHA256-hash van het eerste manifest) en de handtekening van dit manifest:

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

Dus zelfs voordat het UEFI BIOS begint te werken, zal de processor ACM starten, die de authenticiteit van de inhoud van de secties zal verifiëren met de SEC- en PEI-fasecode. Vervolgens verlaat de processor ACM, volgt de RESET-vector en begint het BIOS uit te voeren.

De geverifieerde PEI-partitie moet een module bevatten die de rest van het BIOS controleert (DXE-code). Deze module wordt al ontwikkeld door IBV (Independent BIOS Vendor) of de systeemleverancier zelf. Omdat Alleen Lenovo- en Gigabyte-systemen stonden tot onze beschikking en hadden Intel BG-ondersteuning; laten we eens kijken naar de code die uit deze systemen werd gehaald.

UEFI BIOS-module LenovoVerifiedBootPei

In het geval van Lenovo bleek het de LenovoVerifiedBootPei-module {B9F2AC77-54C7-4075-B42E-C36325A9468D} te zijn, ontwikkeld door Lenovo.

Zijn taak is om (via GUID) de hashtabel voor de DXE op te zoeken en de DXE te verifiëren.

if (EFI_PEI_SERVICES->GetBootMode() != BOOT_ON_S3_RESUME)
{
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	if (!VerifyDxe())
		return EFI_SECURITY_VIOLATION;
}

Хеш таблица {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} имеет следующий формат:

typedef struct HASH_TABLE
{
	char          Tag[8];            // ‘$HASHTBL’
	unsigned long NumDxeDescriptors;
	DXE_DESCRIPTORS[];
};

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long Offset;
	unsigned long Size;
};

UEFI BIOS-module BootGuardPei

In het geval van Gigabyte bleek het de BootGuardPei-module {B41956E1-7CA2-42DB-9562-168389F0F066} te zijn, ontwikkeld door AMI en dus aanwezig in elk AMI BIOS met Intel BG-ondersteuning.

Het werkingsalgoritme is enigszins anders, maar het komt op hetzelfde neer:

int bootMode = EFI_PEI_SERVICES->GetBootMode();

if (bootMode != BOOT_ON_S3_RESUME &&
    bootMode != BOOT_ON_FLASH_UPDATE &&
    bootMode != BOOT_IN_RECOVERY_MODE)
{
	HOB* h = CreateHob();
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	WriteHob(&h, VerifyDxe());
	return h;
}

De hashtabel {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} waarnaar wordt gezocht, heeft het volgende formaat:

typedef HASH_TABLE DXE_DESCRIPTORS[];

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long BaseAddress;
	unsigned long Size;
};

Intel Boot Guard 2.x

Laten we het kort hebben over een andere implementatie van Intel Boot Guard, die werd gevonden in een nieuwer systeem gebaseerd op Intel SoC met Apollo Lake microarchitectuur - ASRock J4205-IT.

Hoewel deze versie alleen in SoC's zal worden gebruikt (nieuwe systemen met Kaby Lake-processormicroarchitectuur blijven Intel Boot Guard 1.x gebruiken), is het van groot belang om de nieuwe architectuuroptie voor Intel SoC-platforms te bestuderen, die aanzienlijke veranderingen hebben ondergaan. bijvoorbeeld:

• de BIOS- en Intel ME-regio's (of beter gezegd Intel TXE, volgens de terminologie voor Intel SoC) zijn nu één IFWI-regio;
• hoewel Intel BG op het platform was ingeschakeld, werden structuren zoals FIT, KEYM en IBM niet gevonden in het flashgeheugen;
• naast de TXE- en ISH-kernen (x86) werd een derde kern aan de chipset toegevoegd (alweer ARC trouwens) - PMC (Power Management Controller), geassocieerd met het garanderen van de werking van het stroomsubsysteem en prestatiemonitoring.

De inhoud van de nieuwe IFWI-regio bestaat uit een set van de volgende modules:

Vooroordeel
naam
beschrijving

0000 2000 uur
SMIP
een bepaalde platformconfiguratie, ondertekend door de leverancier

0000 6000 uur
RBEP
Intel TXE-firmwarecodesectie, x86, ondertekend Intel

0001 0000 uur
PMCP
Intel PMC-firmwarecodesectie, ARC, ondertekend Intel

0002 0000 uur
FTPR
Intel TXE-firmwarecodesectie, x86, ondertekend Intel

0007 B000h
UCOD
microcode-updates voor CPU, ondertekend door Intel

0008 0000 uur
IBBP
UEFI BIOS, SEC/PEI-fasen, x86, ondertekend door de leverancier

0021 8000 uur
ISHC
Intel ISH-firmwarecodesectie, x86, ondertekend door de leverancier

0025 8000 uur
FTP
Intel TXE-firmwarecodesectie, x86, ondertekend Intel

0036 1000 uur
IUNP
onbekend

0038 1000 uur
OBBP
UEFI BIOS, DXE-fase, x86, niet ondertekend

Tijdens de analyse van de TXE-firmware werd het duidelijk dat de TXE na een RESET de processor in deze toestand houdt totdat deze de basisinhoud van de adresruimte voor de CPU voorbereidt (FIT, ACM, RESET-vector ...). Bovendien plaatst TXE deze gegevens in zijn SRAM, waarna hij de processor daar tijdelijk toegang geeft en deze “loslaat” vanuit RESET.

Op uw hoede voor rootkits

Laten we nu verder gaan met de “hete” dingen. We hebben ooit ontdekt dat op veel systemen SPI-flashdescriptors machtigingen bevatten voor toegang tot regio's van het SPI-flashgeheugen, zodat alle gebruikers van dit geheugen elke regio kunnen schrijven en lezen. Die. echt niet.

Na controle met het MEinfo-hulpprogramma (van Intel STK) zagen we dat de productiemodus op deze systemen niet gesloten is, waardoor de chipsetzekeringen (FPF's) in een ongedefinieerde staat blijven. Ja, Intel BG wordt in dergelijke gevallen niet in- of uitgeschakeld.

We hebben het over de volgende systemen (met betrekking tot Intel BG en wat later in het artikel zal worden beschreven, we zullen het hebben over systemen met Haswell-processormicroarchitectuur en hoger):

• alle Gigabyte-producten;
• alle MSI-producten;
• 21 modellen Lenovo-laptops en 4 modellen Lenovo-servers.

Uiteraard hebben we de ontdekking aan deze leveranciers gemeld, evenals aan Intel.

Er kwam pas een adequate reactie van Lenovodie het probleem herkende en een patch uitgebracht.

Gigabyte Ze leken de informatie over de kwetsbaarheid te accepteren, maar gaven op geen enkele manier commentaar.

Communicatie met MSI volledig vastgelopen op ons verzoek om uw openbare PGP-sleutel te sturen (om hen een beveiligingsadvies in gecodeerde vorm te sturen). Ze verklaarden dat ze "een hardwarefabrikant zijn en geen PGP-sleutels produceren."

Maar laten we ter zake komen. Omdat de zekeringen in een niet-gespecificeerde staat blijven, kan de gebruiker (of een aanvaller) ze onafhankelijk programmeren (het moeilijkste is zoek Intel STK). Om dit te doen, moet u de volgende stappen voltooien.

1. Start op in Windows OS (in het algemeen kunnen de hieronder beschreven acties ook onder Linux worden uitgevoerd, als u een analoog van Intel STK ontwikkelt voor het gewenste besturingssysteem). Zorg er met behulp van het MEinfo-hulpprogramma voor dat er geen zekeringen zijn geprogrammeerd op dit systeem.

2. Lees de inhoud van het flash-geheugen met behulp van de Flash Programming Tool.

3. Open de gelezen afbeelding met een UEFI BIOS-bewerkingstool, breng de nodige wijzigingen aan (introduceer bijvoorbeeld een rootkit), creëer/bewerk bestaande KEYM- en IBM-structuren in de ME-regio.

De foto benadrukt het openbare deel van de RSA-sleutel, waarvan de hash samen met de rest van de Intel BG-configuratie in de chipset-zekeringen wordt geprogrammeerd.

4. Bouw met behulp van de Flash Image Tool een nieuwe firmware-image (door de Intel BG-configuratie in te stellen).

5. Schrijf een nieuwe afbeelding naar het flashgeheugen met behulp van de Flash Programming Tool en controleer met MEinfo of de ME-regio nu de Intel BG-configuratie bevat.

6. Gebruik de Flash Programming Tool om de productiemodus te sluiten.

7. Het systeem zal opnieuw opstarten, waarna u met MEinfo kunt controleren of de FPF's nu zijn geprogrammeerd.

Deze acties voor altijd schakel Intel BG in op dit systeem. De actie kan niet ongedaan worden gemaakt, wat betekent:

• Alleen de eigenaar van het privégedeelte van de rootsleutel (d.w.z. degene die Intel BG heeft ingeschakeld) kan het UEFI BIOS op dit systeem bijwerken;
• als u de originele firmware terugstuurt naar dit systeem, bijvoorbeeld met behulp van een programmeur, wordt het niet eens ingeschakeld (een gevolg van het handhavingsbeleid in geval van een verificatiefout);
• om van zo'n UEFI BIOS af te komen, moet je de chipset door geprogrammeerde FPF's vervangen door een "schone" versie (dat wil zeggen, de chipset opnieuw solderen als je toegang hebt tot een infrarood soldeerstation voor de prijs van een auto, of gewoon het moederbord vervangen ).

Om te begrijpen wat zo'n rootkit kan doen, moet u evalueren wat het mogelijk maakt om uw code uit te voeren in de UEFI BIOS-omgeving. Laten we zeggen, in de meest bevoorrechte processormodus: SMM. Zo’n rootkit kan de volgende eigenschappen hebben:

• parallel uitgevoerd met het besturingssysteem (u kunt de verwerking configureren om een ​​SMI-interrupt te genereren, die wordt geactiveerd door een timer);
• alle voordelen hebben van de SMM-modus (volledige toegang tot de inhoud van RAM en hardwarebronnen, geheimhouding van het besturingssysteem);
• De programmacode van de rootkit kan worden gecodeerd en gedecodeerd wanneer deze in de SMM-modus wordt gestart. Alle gegevens die alleen in de SMM-modus beschikbaar zijn, kunnen als coderingssleutel worden gebruikt. Bijvoorbeeld een hash van een reeks adressen in SMRAM. Om deze sleutel te krijgen, moet je naar SMM gaan. En dit kan op twee manieren worden gedaan. Zoek RCE in de SMM-code en exploiteer deze, of voeg uw eigen SMM-module toe aan het BIOS, wat onmogelijk is sinds we Boot Guard hebben ingeschakeld.

Deze kwetsbaarheid stelt een aanvaller dus in staat om:

• creëer een verborgen, niet-verwijderbare rootkit met een onbekend doel in het systeem;
• voer uw code uit op een van de chipsetkernen in de Intel SoC, namelijk op de Intel ISH (kijk goed naar de afbeelding).

Hoewel de mogelijkheden van het Intel ISH-subsysteem nog niet zijn onderzocht, lijkt het een interessante aanvalsvector voor Intel ME.

Bevindingen

1. Het onderzoek maakte het mogelijk een technische beschrijving te krijgen van de werking van Intel Boot Guard-technologie. Minus een paar geheimen in Intel's security through obscurity-model.
2. Er wordt een aanvalsscenario gepresenteerd waarmee u een verwijderbare rootkit in het systeem kunt maken.
3. We hebben gezien dat moderne Intel-processors in staat zijn veel bedrijfseigen code uit te voeren, zelfs voordat het BIOS begint te werken.
4. Platforms met Intel 64-architectuur worden steeds minder geschikt voor het draaien van vrije software: hardwareverificatie, een toenemend aantal propriëtaire technologieën en subsystemen (drie cores in de SoC-chipset: x86 ME, x86 ISH en ARC PMC).

Beperkingen

Leveranciers die de productiemodus opzettelijk open laten, moeten deze zeker sluiten. Tot nu toe zijn alleen hun ogen gesloten, en de nieuwe Kaby Lake-systemen laten dit zien.

Gebruikers kunnen Intel BG uitschakelen op hun systemen (die gevoelig zijn voor het beschreven beveiligingslek) door de Flash Programming Tool uit te voeren met de parameter -closemnf. Ten eerste moet u ervoor zorgen (met behulp van MEinfo) dat de Intel BG-configuratie in de ME-regio voorziet in het uitschakelen van deze technologie na het programmeren in FPF's.

Bron: www.habr.com