Schrödingers bewährter Stiefel. Intel Boot Guard

Wir schlagen vor, noch einmal auf die niedrige Ebene zu gehen und über die Sicherheit von Firmware-x86-kompatiblen Computerplattformen zu sprechen. Der Hauptbestandteil der Forschung ist diesmal Intel Boot Guard (nicht zu verwechseln mit Intel BIOS Guard!) – eine hardwareunterstützte BIOS-Trusted-Boot-Technologie, die ein Computersystemanbieter in der Produktionsphase dauerhaft aktivieren oder deaktivieren kann. Nun, wir kennen das Forschungsrezept bereits: Die Implementierung dieser Technologie durch Reverse Engineering dünn ausschneiden, ihre Architektur beschreiben, sie mit undokumentierten Details füllen, sie mit Angriffsvektoren nach Geschmack würzen und alles vermischen. Fügen wir Feuer mit einer Geschichte darüber hinzu, wie ein seit Jahren geklonter Fehler in der Produktion mehrerer Anbieter es einem potenziellen Angreifer ermöglicht, diese Technologie zu nutzen, um ein verstecktes Rootkit zu erstellen, das nicht (nicht einmal von einem Programmierer) im System entfernt werden kann.

Der Artikel basiert übrigens auf den Berichten „On Guard for Rootkits: Intel BootGuard“ von der Konferenz ZeroNights 2016 und 29. Sitzung DefCon Russland (beide Vorträge hier).

Firmware für eine Computerplattform mit Intel 64-Architektur

Beantworten wir zunächst die Frage: Wie lautet die Firmware einer modernen Computerplattform mit der Intel 64-Architektur? Natürlich UEFI-BIOS. Aber diese Antwort wird nicht korrekt sein. Werfen wir einen Blick auf die Abbildung, die die Desktop-(Laptop-)Version dieser Architektur zeigt.

Der Link ist die Basis:

• Prozessor (CPU, Central Processing Unit), der zusätzlich zu den Hauptkernen über einen integrierten Grafikkern (nicht in allen Modellen) und einen Speichercontroller (IMC, Integrated Memory Controller) verfügt;
• Chipsatz (PCH, Platform Controller Hub), der verschiedene Controller für die Interaktion mit Peripheriegeräten und die Verwaltung von Subsystemen enthält. Darunter ist die berüchtigte Intel Management Engine (ME), die auch über eine Firmware (Intel ME Firmware) verfügt.

Darüber hinaus benötigen Laptops einen integrierten Controller (ACPI EC, Advanced Control and Power Interface Embedded Controller), der für den Betrieb des Stromversorgungssubsystems, des Touchpads, der Tastatur und der Fn-Tasten (Bildschirmhelligkeit, Lautstärke, Tastatur) verantwortlich ist Hintergrundbeleuchtung usw.). ) und mehr. Und er hat auch eine eigene Firmware.

Die Kombination der oben genannten Firmware ist also die Firmware der Computerplattform (Systemfirmware), die auf einem gemeinsamen SPI-Flash-Speicher gespeichert ist. Damit Benutzer dieses Speichers nicht verwirrt werden, wo jemand liegt, ist der Inhalt dieses Speichers in die folgenden Bereiche unterteilt (wie in der Abbildung dargestellt):

• UEFI-BIOS;
• ACPI EC-Firmware (eine separate Region erschien mit der Skylake-Prozessor-Mikroarchitektur (2015), aber in der Praxis haben wir noch keine Beispiele für ihre Verwendung gesehen, daher ist die Firmware des eingebetteten Controllers immer noch Teil des UEFI-BIOS);
• Intel ME-Firmware;
• Konfiguration (MAC-Adresse usw.) des integrierten GbE-Netzwerkadapters (Gigabit Ethernet);
• Flash-Deskriptoren – der Hauptbereich des Flash-Speichers, der Zeiger auf andere Bereiche sowie Berechtigungen für den Zugriff darauf enthält.

Die Differenzierung des Zugriffs auf Regionen (gemäß den angegebenen Berechtigungen) erfolgt durch den SPI-Busmaster – den im Chipsatz integrierten SPI-Controller, über den auf diesen Speicher zugegriffen wird. Wenn die Berechtigungen auf die von Intel (aus Sicherheitsgründen) empfohlenen Werte eingestellt sind, dann hat jeder Benutzer des SPI-Flashs vollen Zugriff (Lesen/Schreiben) nur auf seine Region. Der Rest ist entweder schreibgeschützt oder nicht zugänglich. Bekannte Tatsache: Auf vielen Systemen hat die CPU vollen Zugriff auf das UEFI-BIOS und GbE, nur Lesezugriff auf Flash-Deskriptoren und überhaupt keinen Zugriff auf die Intel ME-Region. Warum viele und nicht alle? Was empfohlen wird, ist optional. Wir werden Ihnen später im Artikel mehr erzählen.

Mechanismen zum Schutz der Firmware einer Computerplattform vor Änderungen

Offensichtlich sollte die Firmware einer Computerplattform vor einer möglichen Kompromittierung geschützt werden, die es einem potenziellen Angreifer ermöglichen würde, darin Fuß zu fassen (Betriebssystem-Updates/Neuinstallationen zu überleben), seinen Code in den privilegiertesten Modi auszuführen usw. Und natürlich reicht es nicht aus, den Zugriff auf SPI-Flash-Speicherbereiche einzuschränken. Daher werden verschiedene, für jede Ausführungsumgebung spezifische Mechanismen verwendet, um die Firmware vor Änderungen zu schützen.

Daher ist die Intel ME-Firmware zur Integritäts- und Authentizitätskontrolle signiert und wird jedes Mal vom ME-Controller überprüft, wenn sie in den ME UMA-Speicher geladen wird. Dieser Verifizierungsprozess wurde von uns bereits in einem der besprochen Artikelist dem Intel ME-Subsystem gewidmet.

Und die ACPI-EC-Firmware wird in der Regel nur auf Integrität überprüft. Aufgrund der Tatsache, dass diese Binärdatei jedoch im UEFI-BIOS enthalten ist, unterliegt sie fast immer denselben Schutzmechanismen, die das UEFI-BIOS verwendet. Lass uns über sie reden.

Diese Mechanismen können in zwei Kategorien unterteilt werden.

Schreibschutz für die UEFI-BIOS-Region

1. Physischer Schutz des Inhalts des SPI-Flash-Speichers durch einen Schreibschutz-Jumper;
2. Schutz der Projektion der UEFI-BIOS-Region im CPU-Adressraum mithilfe der PRx-Register des Chipsatzes;
3. Blockieren von Schreibversuchen in die UEFI-BIOS-Region durch Generieren und Verarbeiten des entsprechenden SMI-Interrupts durch Setzen der BIOS_WE/BLE- und SMM_BWP-Bits in den Chipsatzregistern;
4. Eine erweiterte Version dieses Schutzes ist Intel BIOS Guard (PFAT).

Zusätzlich zu diesen Mechanismen können Anbieter eigene Sicherheitsmaßnahmen entwickeln und implementieren (z. B. das Signieren von Kapseln mit UEFI-BIOS-Updates).

Es ist wichtig zu beachten, dass auf einem bestimmten System (je nach Anbieter) möglicherweise nicht alle der oben genannten Schutzmechanismen angewendet werden, sie möglicherweise überhaupt nicht angewendet werden oder sie möglicherweise auf anfällige Weise implementiert werden. Mehr über diese Mechanismen und die Situation bei ihrer Umsetzung können Sie hier lesen Dieser Artikel. Interessierten empfehlen wir die Lektüre der gesamten Artikelserie zum Thema UEFI-BIOS-Sicherheit von CodeRush.

Überprüfung der UEFI-BIOS-Authentifizierung

Wenn wir über vertrauenswürdige Boot-Technologien sprechen, fällt uns als Erstes Secure Boot ein. Architektonisch ist es jedoch darauf ausgelegt, Komponenten außerhalb des UEFI-BIOS (Treiber, Lader usw.) und nicht die Firmware selbst zu authentifizieren.

Daher hat Intel in SoCs mit der Bay Trail-Mikroarchitektur (2012) einen hardwaremäßig nicht umschaltbaren Secure Boot (Verified Boot) implementiert, der nichts mit der oben genannten Secure Boot-Technologie zu tun hat. Später (2013) wurde dieser Mechanismus verbessert und unter dem Namen Intel Boot Guard für Desktops mit der Haswell-Mikroarchitektur veröffentlicht.

Bevor wir Intel Boot Guard beschreiben, werfen wir einen Blick auf die Ausführungsumgebungen in der Intel 64-Architektur, die in ihrer Kombination die Vertrauensbasis für diese vertrauenswürdige Boot-Technologie darstellen.

Intel CPU

Cap schlägt vor, dass der Prozessor die Hauptausführungsumgebung in der Intel 64-Architektur ist. Warum ist er auch die Wurzel des Vertrauens? Es stellt sich heraus, dass es der Besitz der folgenden Elemente ist, die es so machen:

• Microcode ROM ist ein nichtflüchtiger, nicht wiederbeschreibbarer Speicher zum Speichern von Mikrocode. Es wird angenommen, dass Mikrocode die Implementierung des Prozessorbefehlssystems auf der Grundlage einfachster Anweisungen ist. Passiert auch im Mikrocode Fehler. Im BIOS finden Sie also Binärdateien mit Mikrocode-Updates (sie werden beim Booten überlagert, da das ROM nicht überschrieben werden kann). Der Inhalt dieser Binärdateien ist verschlüsselt, was die Analyse erheblich erschwert (daher ist der spezifische Inhalt des Mikrocodes nur denjenigen bekannt, die ihn entwickeln), und signiert, um die Integrität und Authentizität zu kontrollieren;
• AES-Schlüssel zum Entschlüsseln des Inhalts von Mikrocode-Updates;
• ein Hash des öffentlichen RSA-Schlüssels, der die Signatur von Mikrocode-Updates überprüft;
• RSA-Public-Key-Hash, der die Signatur von Intel-entwickelten ACM-Codemodulen (Authenticated Code Module) überprüft, die die CPU ausführen kann, bevor das BIOS startet (Hallo Mikrocode) oder während seines Betriebs, wenn bestimmte Ereignisse auftreten.

Intel ME

Diesem Subsystem widmete sich unser Blog две Artikel. Denken Sie daran, dass diese ausführbare Umgebung auf dem im Chipsatz integrierten Mikrocontroller basiert und die am besten verborgene und privilegierteste im System ist.

Trotz der Tarnung ist Intel ME auch die Wurzel des Vertrauens, denn es verfügt über:

• ME ROM – nichtflüchtiger, nicht wiederbeschreibbarer Speicher (keine Update-Methode vorgesehen), der den Startcode sowie den SHA256-Hash des öffentlichen RSA-Schlüssels enthält, der die Signatur der Intel ME-Firmware überprüft;
• AES-Schlüssel zum Speichern geheimer Informationen;
• Zugriff auf eine Reihe von Sicherungen (FPFs, Field Programmable Fuses), die in den Chipsatz integriert sind, um bestimmte Informationen dauerhaft zu speichern, einschließlich der vom Computersystemanbieter angegebenen Informationen.

Intel Boot Guard 1.x

Kleiner Haftungsausschluss. Die Versionsnummern der Intel Boot Guard-Technologie, die wir in diesem Artikel verwenden, sind willkürlich und haben möglicherweise nichts mit der in der internen Intel-Dokumentation verwendeten Nummerierung zu tun. Darüber hinaus wurden die hier angegebenen Informationen zur Implementierung dieser Technologie im Zuge des Reverse Engineering gewonnen und können im Vergleich zur Spezifikation für Intel Boot Guard, die wahrscheinlich nie veröffentlicht wird, Ungenauigkeiten enthalten.

Intel Boot Guard (BG) ist also eine hardwareunterstützte UEFI-BIOS-Authentifizierungstechnologie. Der kurzen Beschreibung im Buch [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot] nach zu urteilen, funktioniert es als vertrauenswürdige Boot-Kette. Und der erste Link darin ist der Boot-Code (Mikrocode) innerhalb der CPU, der durch das RESET-Ereignis ausgelöst wird (nicht zu verwechseln mit dem RESET-Vektor im BIOS!). Die CPU findet ein von Intel entwickeltes und signiertes Codemodul (Intel BG Startup ACM) im SPI-Flash-Speicher, lädt es in ihren Cache und verifiziert es (oben wurde bereits erwähnt, dass die CPU über einen Public-Key-Hash verfügt, der die ACM-Signatur verifiziert ) und startet.

Dieses Codemodul ist für die Überprüfung eines kleinen Startteils des UEFI-BIOS verantwortlich – Initial Boot Block (IBB), der wiederum die Funktionalität zur Überprüfung des Hauptteils des UEFI-BIOS enthält. Somit ermöglicht Ihnen Intel BG, die Authentizität des BIOS vor dem Booten des Betriebssystems zu überprüfen (was unter der Aufsicht der Secure Boot-Technologie durchgeführt werden kann).

Die Intel BG-Technologie bietet zwei Betriebsmodi (und einer stört den anderen nicht, d. h. beide Modi können auf dem System aktiviert und beide deaktiviert werden).

Gemessener Stiefel

Im Measured Boot (MB)-Modus „misst“ jede Boot-Komponente (beginnend mit dem CPU-Boot-ROM) die nächste mithilfe der Funktionen des Trusted Platform Module (TPM). Für diejenigen, die es nicht wissen, möchte ich es erklären.

TPM verfügt über PCRs (Platform Configuration Registers), die das Ergebnis des Hashing-Vorgangs gemäß der Formel aufzeichnen:

Diese. Der aktuelle PCR-Wert hängt vom vorherigen ab und diese Register werden nur zurückgesetzt, wenn das System zurückgesetzt wird.

Somit spiegeln PCRs im MB-Modus zu einem bestimmten Zeitpunkt eine eindeutige (innerhalb der Möglichkeiten der Hash-Operation) Kennung des Codes oder der Daten wider, die „gemessen“ wurden. Die PCR-Werte können bei der Verschlüsselung einiger Daten (TPM_Seal) verwendet werden. Danach ist ihre Entschlüsselung (TPM_Unseal) nur dann möglich, wenn sich die PCR-Werte durch das Laden nicht geändert haben (d. h. keine einzige „gemessene“ Komponente wurde geändert).

Verifizierter Start

Das Schrecklichste für diejenigen, die gerne das UEFI-BIOS modifizieren, ist der Verified Boot (VB)-Modus, bei dem jede Boot-Komponente kryptografisch die Integrität und Authentizität der nächsten überprüft. Und im Falle eines Verifizierungsfehlers tritt (eines der folgenden) ein:

• Herunterfahren durch Timeout von 1 Minute bis 30 Minuten (damit der Benutzer Zeit hat zu verstehen, warum sein Computer nicht startet, und wenn möglich versuchen würde, das BIOS wiederherzustellen);
• sofortiges Herunterfahren (damit der Benutzer keine Zeit hat, es zu verstehen und darüber hinaus zu tun);
• Fortsetzung der Arbeit mit ernstem Gesicht (der Fall, wenn keine Zeit für Sicherheit bleibt, weil es Wichtigeres zu tun gibt).

Die Wahl der Aktion hängt von der angegebenen Intel BG-Konfiguration ab (nämlich von der sogenannten Durchsetzungsrichtlinie), die vom Computerplattformanbieter dauerhaft in einem speziell entwickelten Speicher – Chipsatzsicherungen (FPFs) – aufgezeichnet wird. Auf diesen Punkt werden wir später noch näher eingehen.

Zusätzlich zur Konfiguration generiert der Anbieter zwei RSA 2048-Schlüssel und erstellt zwei Datenstrukturen (siehe Abbildung):

1. Das Root-Key-Manifest des Anbieters (KEYM, OEM Root Key Manifest), das die SVN (Security Version Number) dieses Manifests, den SHA256-Hash des öffentlichen Schlüssels des nächsten Manifests, den öffentlichen RSA-Schlüssel (d. h. den öffentlichen Teil des Manifests) enthält Anbieter-Root-Schlüssel), um die Signatur dieses Manifests und die Signatur selbst zu überprüfen;
2. Das IBB-Manifest (IBBM, Initial Boot Block Manifest), das den SVN dieses Manifests, den SHA256-Hash des IBB, den öffentlichen Schlüssel zur Überprüfung der Signatur dieses Manifests und die Signatur selbst enthält.

Der SHA256-Hash des OEM-Root-Schlüssels wird, genau wie die Intel BG-Konfiguration, dauerhaft in Chipsatz-Sicherungen (FPFs) geschrieben. Wenn die Intel BG-Konfiguration die Einbeziehung dieser Technologie vorsieht, kann dieses System von nun an nur noch der Besitzer des privaten Teils des OEM-Root-Schlüssels das BIOS aktualisieren (d. h. diese Manifeste neu berechnen können), d. h. Verkäufer.

Beim Betrachten des Bildes kommen sofort Zweifel an der Notwendigkeit einer so langen Verifizierungskette auf – man hätte ein einziges Manifest verwenden können. Warum kompliziert?

Tatsächlich bietet Intel dem Anbieter damit die Möglichkeit, unterschiedliche IBB-Schlüssel für verschiedene Produktlinien und einen als Root zu verwenden. Wenn der private Teil des IBB-Schlüssels (der das zweite Manifest signiert) durchgesickert ist, betrifft der Vorfall nur eine Produktlinie und nur so lange, bis der Anbieter ein neues Paar generiert und die neu berechneten Manifeste im nächsten BIOS-Update aktiviert.

Wenn jedoch der Root-Schlüssel kompromittiert ist (mit dem das erste Manifest signiert ist), kann er nicht ersetzt werden, da das Widerrufsverfahren nicht vorgesehen ist. Der Hash des öffentlichen Teils dieses Schlüssels wird ein für alle Mal in FPFs programmiert.

Intel Boot Guard-Konfiguration

Schauen wir uns nun die Intel BG-Konfiguration und den Prozess ihrer Erstellung genauer an. Wenn Sie sich die entsprechende Registerkarte in der GUI des Flash Image Tools aus dem Intel System Tool Kit (STK) ansehen, werden Sie feststellen, dass die Intel BG-Konfiguration einen Hash des öffentlichen Teils des Hersteller-Root-Schlüssels enthält, ein paar undurchsichtige Werte usw. Intel BG-Profil.

Der Aufbau dieses Profils:

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

Generell handelt es sich bei der Intel BG-Konfiguration um eine sehr flexible Einheit. Betrachten Sie zum Beispiel das Force_Boot_Guard_ACM-Flag. Wenn es gelöscht ist und das BG-Start-ACM-Modul auf dem SPI-Flash nicht gefunden wird, findet kein vertrauenswürdiger Start statt. Es wird nicht vertrauenswürdig sein.

Wir haben oben bereits geschrieben, dass die Durchsetzungsrichtlinie für den VB-Modus so konfiguriert werden kann, dass bei fehlgeschlagener Überprüfung erneut ein nicht vertrauenswürdiger Download erfolgt.

Überlassen Sie solche Dinge den Verkäufern ...

Die GUI des Dienstprogramms stellt die folgenden „vorgefertigten“ Profile bereit:

Nein.
Regime
Beschreibung

0
No_FVME
Intel BG-Technologie deaktiviert

1
VE
VB-Modus aktiviert, Herunterfahren durch Timeout

2
VME
beide Modi sind aktiviert (VB und MB), Abschaltung durch Timeout

3
VM
Beide Modi sind aktiviert, ohne dass das System ausgeschaltet werden muss

4
FVE
VB-Modus aktiviert, sofortiges Herunterfahren

5
FVME
Beide Modi aktiviert, sofortiges Herunterfahren

Wie bereits erwähnt, muss die Intel BG-Konfiguration vom Systemhersteller ein für alle Mal in Chipsatz-Fuses (FPFs) geschrieben werden – ein kleiner (nach ungeprüften Informationen nur 256 Byte) Hardware-Informationsspeicher innerhalb des Chipsatzes, der außerhalb programmiert werden kann der Produktionsanlagen von Intel (das ist der Grund). Feldprogrammierbar Sicherungen).

Es eignet sich hervorragend zum Speichern von Konfigurationen, weil:

• verfügt über einen einmalig programmierbaren Datenspeicherbereich (genau dort, wo die Intel BG-Konfiguration geschrieben wird);
• Nur Intel ME kann es lesen und programmieren.

Um also die Konfiguration für die Intel BG-Technologie auf einem bestimmten System festzulegen, geht der Anbieter während der Produktion wie folgt vor:

1. Mit dem Dienstprogramm Flash Image Tool (von Intel STK) wird ein Firmware-Image mit einer bestimmten Intel BG-Konfiguration als Variablen innerhalb der Intel ME-Region (dem sogenannten temporären Spiegel für FPFs) erstellt.
2. Mit dem Flash Programming Tool (von Intel STK) schreibt man dieses Image in den SPI-Flash-Speicher des Systems und schließt das sogenannte. Herstellungsmodus (in diesem Fall wird der entsprechende Befehl an Intel ME gesendet).

Als Ergebnis dieser Vorgänge überträgt Intel ME die angegebenen Werte aus dem Spiegel für FPFs in der ME-Region an FPFs und setzt die Berechtigungen in SPI-Flash-Deskriptoren auf die von Intel empfohlenen Werte (beschrieben am Anfang). Artikel) und führen Sie einen System-Reset durch.

Analyse der Intel Boot Guard-Implementierung

Um die Implementierung dieser Technologie an einem konkreten Beispiel zu analysieren, haben wir die folgenden Systeme auf Spuren der Intel BG-Technologie überprüft:

System
Beachten

Gigabyte GA-H170-D3H
Skylake, es gibt Unterstützung

Gigabyte GA-Q170-D3H
Skylake, es gibt Unterstützung

Gigabyte GA-B150-HD3
Skylake, es gibt Unterstützung

MSI H170A Gaming Pro
Skylake, keine Unterstützung

Lenovo ThinkPad 460
Skylake, Support verfügbar, Technologie aktiviert

Lenovo Yoga 2 Pro
Haswell, keine Unterstützung

Lenovo U330p
Haswell, keine Unterstützung

„Unterstützung“ bedeutet das Vorhandensein des Intel BG-Startup-ACM-Moduls, der oben genannten Manifeste und des entsprechenden Codes im BIOS, d. h. Implementierungen zur Analyse.

Nehmen wir als Beispiel das aus dem Büro heruntergeladene. Hersteller-Site-Image des SPI-Flash-Speichers für Gigabyte GA-H170-D3H (Version F4).

Boot-ROM der Intel-CPU

Lassen Sie uns zunächst über die Aktionen des Prozessors sprechen, wenn die Intel BG-Technologie aktiviert ist.

Es war nicht möglich, Beispiele des entschlüsselten Mikrocodes zu finden. Daher ist die Frage, wie die unten beschriebenen Aktionen implementiert werden (im Mikrocode oder in der Hardware), offen. Dennoch ist die Tatsache, dass moderne Intel-Prozessoren diese Aktionen „können“, eine Tatsache.

Nach Verlassen des RESET-Zustands findet der Prozessor (in dessen Adressraum bereits der Inhalt des Flash-Speichers abgebildet ist) die FIT (Firmware Interface Table). Es ist einfach zu finden, der Zeiger darauf wird an der Adresse FFFF FFC0h geschrieben.

In diesem Beispiel enthält diese Adresse den Wert FFD6 9500h. Unter dieser Adresse sieht der Prozessor die FIT-Tabelle, deren Inhalt in Datensätze unterteilt ist. Der erste Eintrag ist die Überschrift der folgenden 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;
};

Aus einem unbekannten Grund wird die Prüfsumme in diesen Tabellen nicht immer berechnet (das Feld bleibt null).

Die verbleibenden Einträge verweisen auf verschiedene Binärdateien, die analysiert/ausgeführt werden müssen, bevor das BIOS ausgeführt wird, d. h. bevor zum alten RESET-Vektor (FFFF FFF0h) gewechselt wird. Die Struktur jedes dieser Einträge ist wie folgt:

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

Das Feld „EntryType“ gibt den Blocktyp an, auf den dieser Eintrag verweist. Wir kennen mehrere Arten:

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

Nun ist es offensichtlich, dass einer der Einträge auf den Speicherort der Intel BG-Startup-ACM-Binärdatei verweist. Die Header-Struktur dieser Binärdatei ist typisch für von Intel entwickelte Codemodule (ACMs, Mikrocode-Updates, Intel ME-Codeabschnitte, ...).

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

Der Prozessor lädt diese Binärdatei in seinen Cache, überprüft sie und startet sie.

Intel BG-Startup ACM

Als Ergebnis der Analyse der Arbeit dieses ACM wurde deutlich, dass es Folgendes tut:

• empfängt von Intel ME die Intel BG-Konfiguration, die in die Chipsatzsicherungen (FPFs) geschrieben wird;
• findet KEYM- und IBMM-Manifeste und überprüft sie.

Um diese Manifeste zu finden, verwendet ACM auch die FIT-Tabelle, die zwei Arten von Einträgen enthält, die auf diese Strukturen verweisen (siehe FIT_ENTRY_TYPES oben).

Schauen wir uns die Manifeste genauer an. In der Struktur des ersten Manifests sehen wir mehrere obskure Konstanten, einen Hash des öffentlichen Schlüssels aus dem zweiten Manifest und einen öffentlichen OEM-Root-Schlüssel, der als verschachtelte Struktur signiert ist:

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

Zur Überprüfung des öffentlichen Schlüssels des OEM-Root-Schlüssels erinnern wir uns daran, dass der SHA256-Hash der Sicherungen verwendet wird, der zu diesem Zeitpunkt bereits von Intel ME empfangen wurde.

Kommen wir zum zweiten Manifest. Es besteht aus drei Strukturen:

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

Die erste enthält einige Konstanten:

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

Die zweite enthält den SHA256-Hash des IBB und die Anzahl der Deskriptoren, die den Inhalt des IBB beschreiben (d. h. woraus der Hash berechnet wird):

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

Die IBB-Deskriptoren folgen nacheinander dieser Struktur. Ihr Inhalt hat folgendes Format:

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

Es ist ganz einfach: Jeder Deskriptor enthält die Adresse/Größe eines IBB-Blocks. Somit ist die Verkettung der Blöcke, auf die diese Deskriptoren verweisen (in der Reihenfolge der Deskriptoren selbst), IBB. Und in der Regel ist IBB eine Kombination aller Module der SEC- und PEI-Phasen.

Das zweite Manifest endet mit einer Struktur, die den öffentlichen IBB-Schlüssel (verifiziert durch den SHA256-Hash aus dem ersten Manifest) und die Signatur dieses Manifests enthält:

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

So startet der Prozessor bereits vor Beginn der UEFI-BIOS-Ausführung ACM, das die Authentizität des Inhalts der Abschnitte anhand des SEC- und PEI-Phasencodes überprüft. Als nächstes verlässt der Prozessor das ACM, bewegt sich entlang des RESET-Vektors und beginnt mit der Ausführung des BIOS.

Die PEI-verifizierte Partition muss ein Modul enthalten, das den Rest des BIOS überprüft (DXE-Code). Dieses Modul wird bereits von IBV (Independent BIOS Vendor) oder dem Systemanbieter selbst entwickelt. Weil Es stellte sich heraus, dass uns nur Lenovo- und Gigabyte-Systeme zur Verfügung standen. Da wir Intel BG-Unterstützung haben, betrachten wir den aus diesen Systemen extrahierten Code.

UEFI-BIOS-Modul LenovoVerifiedBootPei

Im Fall von Lenovo handelte es sich um das von Lenovo entwickelte Modul LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}.

Seine Aufgabe besteht darin, (anhand der GUID) eine Hash-Tabelle für den DXE nachzuschlagen und den DXE zu überprüfen.

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

Im Fall von Gigabyte handelte es sich um das BootGuardPei-Modul {B41956E1-7CA2-42DB-9562-168389F0F066}, das von AMI entwickelt wurde und daher in jedem AMI-BIOS mit Intel BG-Unterstützung vorhanden ist.

Der Funktionsalgorithmus ist etwas anders, läuft jedoch auf das Gleiche hinaus:

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

Die nachgeschlagene Hash-Tabelle {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} hat das folgende 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

Lassen Sie uns kurz über eine weitere Implementierung von Intel Boot Guard sprechen, die in einem neueren System auf Basis von Intel SoC mit Apollo Lake-Mikroarchitektur zu finden ist – ASRock J4205-IT.

Obwohl diese Version nur in SoCs verwendet wird (neue Systeme mit Kaby-Lake-Prozessor-Mikroarchitektur verwenden weiterhin Intel Boot Guard 1.x), besteht großes Interesse an der Erforschung einer neuen Architekturoption für Plattformen auf Basis von Intel SoCs, die bereits greifbar geworden ist Änderungen, zum Beispiel:

• BIOS- und Intel ME-Regionen (oder besser gesagt Intel TXE gemäß der Intel SoC-Terminologie) sind jetzt eine IFWI-Region;
• Obwohl Intel BG auf der Plattform aktiviert war, wurden Strukturen wie FIT, KEYM, IBMM nicht im Flash-Speicher gefunden;
• Zusätzlich zu den TXE- und ISH-Kernen (x86) wurde dem Chipsatz ein dritter Kern (übrigens wieder ARC) hinzugefügt – PMC (Power Management Controller), der mit der Sicherstellung der Funktionsfähigkeit des Energiesubsystems und der Leistungsüberwachung verbunden ist.

Der Inhalt der neuen IFWI-Region besteht aus folgenden Modulen:

Offset
Name
Beschreibung

0000 2000h
SMIP
eine vom Anbieter signierte Plattformkonfiguration

0000 6000h
RBEP
Intel TXE-Firmware-Codeabschnitt, x86, signiert von Intel

0001 0000h
PMCP
Firmware-Codeabschnitt Intel PMC, ARC, signiert von Intel

0002 0000h
FTPR
Intel TXE-Firmware-Codeabschnitt, x86, signiert von Intel

0007B000h
UCOD
Von Intel signierte CPU-Mikrocode-Updates

0008 0000h
IBBP
UEFI-BIOS, SEC/PEI-Phasen, x86, vom Hersteller signiert

0021 8000h
ISHC
Codeabschnitt der Intel ISH-Firmware, x86, signiert vom Anbieter

0025 8000h
FTP
Intel TXE-Firmware-Codeabschnitt, x86, signiert von Intel

0036 1000h
IUNP
unbekannt

0038 1000h
OBBP
UEFI-BIOS, DXE-Phase, x86, unsigniert

Bei der Analyse der TXE-Firmware wurde deutlich, dass TXE nach einem RESET den Prozessor in diesem Zustand hält, bis es die grundlegenden Inhalte des Adressraums für die CPU vorbereitet (FIT, ACM, RESET-Vektor ...). Darüber hinaus legt TXE diese Daten in seinem SRAM ab, gewährt dem Prozessor dort vorübergehend Zugriff und „gibt“ sie von RESET frei.

Auf der Hut vor Rootkits

Kommen wir nun zum „Heißen“. Wir haben einmal herausgefunden, dass SPI-Flash-Deskriptoren auf vielen Systemen Berechtigungen haben, auf Regionen des SPI-Flash-Speichers zuzugreifen, sodass alle Benutzer dieses Speichers jede Region sowohl schreiben als auch lesen können. Diese. auf keinen Fall.

Nach einer Überprüfung mit dem MEinfo-Dienstprogramm (von Intel STK) stellten wir fest, dass der Fertigungsmodus auf diesen Systemen nicht geschlossen war und die Chipsatzsicherungen (FPFs) daher in einem unbestimmten Zustand belassen wurden. Ja, Intel BG ist in solchen Fällen weder aktiviert noch deaktiviert.

Wir sprechen über die folgenden Systeme (in Bezug auf Intel BG und das, was später in diesem Artikel beschrieben wird, werden wir über Systeme mit Haswell-Prozessor-Mikroarchitektur und höher sprechen):

• alle Gigabyte-Produkte;
• alle MSI-Produkte;
• 21 Lenovo Laptop-Modelle und 4 Lenovo Server-Modelle.

Selbstverständlich haben wir den Fund sowohl diesen Anbietern als auch Intel gemeldet.

Eine angemessene Reaktion folgte erst ab Lenovower das Problem erkannt hat und einen Patch veröffentlicht.

Gigabyte Es scheint, dass sie Informationen über die Sicherheitslücke akzeptiert haben, sich aber in keiner Weise dazu geäußert haben.

Kommunikation mit MSI auf unsere Aufforderung, unseren öffentlichen PGP-Schlüssel zu senden (um ihnen eine verschlüsselte Sicherheitswarnung zu senden), völlig ins Stocken geraten. Sie gaben an, dass sie „ein Hardwarehersteller sind und keine PGP-Schlüssel herstellen“.

Aber mehr auf den Punkt. Da die Sicherungen in einem undefinierten Zustand belassen werden, kann der Benutzer (oder Angreifer) sie selbst programmieren (am schwierigsten ist es). Finden Sie Intel STK). Dies erfordert die folgenden Schritte.

1. Booten Sie in das Windows-Betriebssystem (im Allgemeinen können die unten beschriebenen Schritte auch unter Linux ausgeführt werden, wenn Sie ein Analogon von Intel STK für das gewünschte Betriebssystem entwickeln). Stellen Sie mithilfe des Dienstprogramms MEinfo sicher, dass die Sicherungen in diesem System nicht programmiert sind.

2. Lesen Sie den Inhalt des Flash-Speichers mit dem Flash Programming Tool.

3. Öffnen Sie das gelesene Image mit einem beliebigen UEFI-BIOS-Bearbeitungstool, nehmen Sie die erforderlichen Änderungen vor (z. B. ein Rootkit implementieren), erstellen/bearbeiten Sie die vorhandenen KEYM- und IBMM-Strukturen in der ME-Region.

Der öffentliche Teil des RSA-Schlüssels ist im Bild hervorgehoben, dessen Hash zusammen mit dem Rest der Intel BG-Konfiguration in die Chipsatzsicherungen programmiert wird.

4. Erstellen Sie mit dem Flash Image Tool ein neues Firmware-Image (durch Festlegen der Intel BG-Konfiguration).

5. Schreiben Sie mit dem Flash Programming Tool ein neues Image in den Flash und überprüfen Sie mit MEinfo, ob die ME-Region jetzt die Intel BG-Konfiguration enthält.

6. Verwenden Sie das Flash Programming Tool, um den Fertigungsmodus zu schließen.

7. Das System wird neu gestartet. Anschließend können Sie mit MEinfo überprüfen, ob die FPFs jetzt programmiert sind.

Diese Aktionen für immer Aktivieren Sie Intel BG auf diesem System. Es ist nicht möglich, die Aktion rückgängig zu machen, was bedeutet:

• Nur der Besitzer des privaten Teils des Root-Schlüssels (d. h. derjenige, der Intel BG aktiviert hat) kann das UEFI-BIOS auf diesem System aktualisieren;
• Wenn Sie die Original-Firmware beispielsweise mithilfe eines Programmiergeräts an dieses System zurückgeben, lässt es sich nicht einmal einschalten (eine Folge der Durchsetzungsrichtlinie im Falle eines Überprüfungsfehlers).
• Um ein solches UEFI-BIOS loszuwerden, müssen Sie den Chipsatz mit programmierten FPFs durch einen „sauberen“ ersetzen (d. h. den Chipsatz neu löten, wenn Sie Zugang zu einer Infrarot-Lötstation zum Preis eines Autos haben, oder einfach das Motherboard austauschen). ).

Um zu verstehen, was ein solches Rootkit bewirken kann, müssen Sie bewerten, was die Ausführung Ihres Codes in einer UEFI-BIOS-Umgebung ermöglicht. Sagen wir, im privilegiertesten Modus des Prozessors – SMM. Ein solches Rootkit kann folgende Eigenschaften haben:

• parallel zum Betriebssystem ausgeführt werden (Sie können die Verarbeitung konfigurieren, indem Sie einen SMI-Interrupt generieren, der durch einen Timer ausgelöst wird);
• Sie haben alle Vorteile des SMM-Modus (vollständiger Zugriff auf den Inhalt von RAM und Hardwareressourcen, Geheimhaltung gegenüber dem Betriebssystem);
• Der Rootkit-Code kann beim Start im SMM-Modus verschlüsselt und entschlüsselt werden. Alle nur im SMM-Modus verfügbaren Daten können als Verschlüsselungsschlüssel verwendet werden. Zum Beispiel ein Hash aus einer Reihe von Adressen im SMRAM. Um diesen Schlüssel zu erhalten, müssen Sie in das SMM klettern. Und das kann auf zwei Arten geschehen. Suchen Sie den RCE im SMM-Code und nutzen Sie ihn aus, oder fügen Sie dem BIOS Ihr eigenes SMM-Modul hinzu, was nicht möglich ist, da wir Boot Guard aktiviert haben.

Somit ermöglicht diese Sicherheitslücke einem Angreifer Folgendes:

• ein verstecktes, nicht entfernbares Rootkit mit unbekanntem Zweck im System erstellen;
• Führen Sie Ihren Code auf einem der Chipsatzkerne im Intel SoC aus, nämlich auf dem Intel ISH (schauen Sie sich das Bild genauer an).

Obwohl die Fähigkeiten des Intel ISH-Subsystems noch nicht erforscht sind, scheint es ein interessanter Angriffsvektor gegen Intel ME zu sein.

Befund

1. Die Studie lieferte eine technische Beschreibung der Funktionsweise der Intel Boot Guard-Technologie. Abzüglich einiger Geheimnisse in Intels „Security Through Obscurity“-Modell.
2. Es wird ein Angriffsszenario vorgestellt, das die Erstellung eines nicht entfernbaren Rootkits im System ermöglicht.
3. Wir haben gesehen, dass moderne Intel-Prozessoren in der Lage sind, bereits vor dem Start des BIOS eine Menge proprietären Code auszuführen.
4. Plattformen mit Intel 64-Architektur eignen sich immer weniger für den Betrieb freier Software: Hardware-Verifizierung, immer mehr proprietäre Technologien und Subsysteme (drei Kerne im SoC-Chipsatz: x86 ME, x86 ISH und ARC PMC).

Milderungen

Anbieter, die den Herstellungsmodus absichtlich offen lassen, sollten ihn unbedingt schließen. Bisher schließen sie nur die Augen und die neuen Kaby-Lake-Systeme zeigen das.

Benutzer können Intel BG auf ihren Systemen (die von der beschriebenen Sicherheitslücke betroffen sind) deaktivieren, indem sie das Flash Programming Tool mit der Option -closemnf ausführen. Zunächst sollte man sich (mittels MEinfo) vergewissern, dass die Konfiguration von Intel BG in der ME-Region genau das Abschalten dieser Technologie nach der Programmierung in FPFs vorsieht.

Source: habr.com