Vertraulicher Schrödingers-Download. Intel Boot Guard

Lassen Sie uns wieder auf ein niedriges Niveau hinabsteigen und über die Sicherheit von Firmware auf x86-kompatiblen Computerplattformen sprechen. Diesmal ist der Hauptbestandteil der Untersuchung Intel Boot Guard (nicht zu verwechseln mit Intel BIOS Guard!) – eine hardwaregestützte Technologie für das vertrauenswürdige Laden von BIOS, die vom Computerhersteller dauerhaft während der Produktion aktiviert oder deaktiviert werden kann. Das Rezept für unsere Untersuchung ist uns bereits bekannt: Wir schneiden die Implementierung dieser Technologie durch Reverse Engineering fein, beschreiben ihre Architektur, fügen undokumentierte Details hinzu und würzen nach Geschmack mit Angriffsszenarien. Wir heizen das Ganze an, indem wir darüber erzählen, wie ein seit Jahren klonbares Produktionsfehler bei mehreren Herstellern es einem potenziellen Angreifer ermöglicht, diese Technologie zu nutzen, um ein unlösbares (selbst für Programmierer) verstecktes Rootkit im System zu erstellen.

Übrigens basiert der Artikel auf den Vorträgen "Im Schutz der Rootkits: Intel BootGuard" von der ZeroNights 2016 und dem 29. Treffen DefCon Russland (beide Präsentationen hier).

Firmware der Computerplattform mit der Architektur Intel 64

Zunächst beantworten wir die Frage: Was ist die Firmware einer modernen Computerplattform mit der Architektur Intel 64? Natürlich ist es das UEFI BIOS. Aber diese Antwort wäre ungenau. Werfen wir einen Blick auf das Bild, das eine Desktop- (Laptop-) Variante dieser Architektur zeigt.

Die Grundlage bildet das Paket:

• Der Prozessor (CPU, Central Processing Unit), in den, neben den Hauptkernen, ein grafischer Kern (nicht in allen Modellen) integriert ist und ein Speicherkontroller (IMC, Integrated Memory Controller) eingebaut ist;
• Der Chipsatz (PCH, Platform Controller Hub), der verschiedene Controller zur Interaktion mit Peripheriegeräten und zur Verwaltung von Subsystemen enthält. Darunter ist der nicht unbekannte Intel Management Engine (ME), der ebenfalls eine Firmware (Intel ME Firmware) besitzt.

Notebooks erfordern, zusätzlich zu dem oben Genannten, einen eingebauten Controller (ACPI EC, Advanced Control and Power Interface Embedded Controller), der für die Funktionsfähigkeit des Stromversorgungssystems, des Touchpads, der Tastatur, der Fn-Tasten (Helligkeit des Bildschirms, Lautstärke, Tastaturbeleuchtung usw.) und mehr verantwortlich ist. Auch dieser hat seine eigene Firmware.

Die Gesamtheit der oben genannten Firmware bildet die Firmware der Computerplattform (Systemfirmware), die im gemeinsamen SPI-Flash-Speicher gespeichert ist. Um den Benutzern dieser Speicher zu helfen, nicht durcheinander zu geraten, ist der Inhalt dieses Speichers in die folgenden Regionen unterteilt (wie im Bild gezeigt):

• UEFI BIOS;
• Firmware des ACPI EC (eine separate Region erschien mit der Mikroarchitektur Skylake von 2015, aber in der Praxis haben wir bisher keine Beispiele für ihre Nutzung gesehen, sodass die Firmware des eingebetteten Controllers nach wie vor Teil des UEFI BIOS ist);
• Intel ME Firmware;
• Konfiguration (MAC-Adresse usw.) des eingebetteten GbE (Gigabit Ethernet) Netzadaptors;
• Flash Descriptors – der Hauptbereich des Flash-Speichers, der Zeiger auf die anderen Bereiche sowie Zugriffsberechtigungen für diese enthält.

Die Zugangskontrolle zu den Regionen (entsprechend den festgelegten Berechtigungen) wird vom SPI-Busmaster – dem im Chipsatz integrierten SPI-Controller – erledigt, über den auf diesen Speicher zugegriffen wird. Wenn die Berechtigungen auf die von Intel empfohlenen (aus Sicherheitsgründen) Werte festgelegt sind, hat jeder Benutzer des SPI-Flash-Speichers vollständigen Zugriff (lesen/ schreiben) nur auf seinen Bereich. Die anderen sind entweder nur lesbar oder nicht zugänglich. Ein bekanntes Faktum: Auf vielen Systemen hat die CPU vollen Zugriff auf das UEFI BIOS und GbE, hat nur Leserechte auf die Flash-Descriptors, und hat überhaupt keinen Zugriff auf den Intel ME Bereich. Warum auf vielen und nicht auf allen? Was empfohlen wird, ist nicht zwingend. Mehr dazu im weiteren Verlauf des Artikels.

Schutzmechanismen der Firmware der Computerplattform gegen Modifikationen

Es ist offensichtlich, dass die Firmware der Computerplattform vor möglichen Kompromittierungen geschützt werden muss, die es einem potenziellen Angreifer ermöglichen würden, sich darin festzusetzen (Updates/Systemneuinstallationen zu überstehen), seinen Code in den privilegiertesten Modi auszuführen usw. Und die Zugangskontrolle zu den Regionen des SPI-Flash-Speichers ist natürlich nicht ausreichend. Daher werden verschiedene Mechanismen zum Schutz der Firmware vor Modifikationen angewendet, die spezifisch für jede Ausführungsumgebung sind.

So ist die Intel ME Firmware signiert, um die Integrität und Authentizität zu kontrollieren, und wird bei jedem Laden in den ME UMA-Speicher vom ME-Controller überprüft. Dieser Verifizierungsprozess wurde bereits in einem unserer Artikel, die dem Intel ME-Subsystem gewidmet ist.

Die ACPI EC-Firmware wird in der Regel nur auf Integrität überprüft. Da dieses Binärformat jedoch Teil des UEFI BIOS ist, unterliegt es fast immer denselben Schutzmechanismen, die das UEFI BIOS nutzt. Darüber werden wir sprechen.

Diese Mechanismen lassen sich in zwei Kategorien unterteilen.

Schutz gegen das Schreiben in den UEFI BIOS-Bereich

1. Physischer Schutz des Inhalts des SPI-Flashspeichers durch einen Write-Protect-Jumper;
2. Schutz der Projektionsregion des UEFI BIOS im Adressraum der CPU durch PRx-Register des Chipsatzes;
3. Blockierung von Schreibversuchen in den UEFI BIOS-Bereich durch Generierung und Verarbeitung des entsprechenden SMI-Interrupts, indem die Bits BIOS_WE/BLE und SMM_BWP in den Registern des Chipsatzes gesetzt werden;
4. Eine fortgeschrittenere Variante dieses Schutzes ist Intel BIOS Guard (PFAT).

Neben diesen Mechanismen können Hersteller eigene Sicherheitsmaßnahmen entwickeln und anwenden (z.B. das Signieren von Kapseln mit UEFI BIOS-Updates).

Es ist wichtig zu beachten, dass auf einem bestimmten System (abhängig vom Hersteller) nicht alle oben genannten Schutzmechanismen angewendet werden können. Sie können entweder gar nicht angewendet oder anfällig umgesetzt sein. Weitere Informationen zu diesen Mechanismen und zur Situation ihrer Umsetzung finden Sie in diesem Artikel. Interessierten empfehlen wir, sich mit dem gesamten Artikelzyklus zur Sicherheit des UEFI BIOS von CodeRush.

Überprüfung der Authentizität des UEFI BIOS

Wenn wir über Technologien für ein vertrauenswürdiges Booten sprechen, ist das erste, was in den Sinn kommt, Secure Boot. Architektonisch ist es jedoch dafür gedacht, die Authentizität externer, im Vergleich zum UEFI BIOS stehender Komponenten (Treiber, Bootloader usw.) zu überprüfen, nicht die Firmware selbst.

Daher implementierte Intel in SoCs mit der Mikroarchitektur Bay Trail (2012) einen hardwareseitig nicht deaktivierbaren Secure Boot (Verified Boot), der nichts mit der oben erwähnten Secure Boot-Technologie zu tun hat. Später (2013) wurde dieser Mechanismus verbessert und unter dem Namen Intel Boot Guard für Desktop-PCs mit der Mikroarchitektur Haswell veröffentlicht.

Bevor wir Intel Boot Guard beschreiben, wollen wir die Ausführungsumgebungen in der Intel 64-Architektur klären, die gleichzeitig die Vertrauensanker für diese Technologie des vertrauenswürdigen Bootens darstellen.

Intel CPU

Käp sagt uns, dass der Prozessor die Hauptausführungsumgebung in der Intel 64-Architektur ist. Warum ist er auch der Vertrauensanker? Es stellt sich heraus, dass dies mit den folgenden Elementen zusammenhängt:

• Microcode-ROM — ein nichtflüchtiger, nicht beschreibbarer Speicher zur Speicherung von Mikrokode. Man nimmt an, dass Mikrokode die Implementierung des Befehlssystems des Prozessors in einfachsten Anweisungen ist. Auch im Mikrokode treten Fehlerauf. Daher kann man im BIOS Binärdateien mit Mikrokodeteilen finden (sie werden während des Bootvorgangs eingespielt, da ROM nicht beschreibbar ist). Der Inhalt dieser Binärdateien ist verschlüsselt, was die Analyse erheblich erschwert (deshalb ist der konkrete Inhalt des Mikrokodes nur denjenigen bekannt, die ihn entwickeln), und er ist signiert, um die Integrität und Authentizität zu überprüfen;
• AES-Schlüssel zur Entschlüsselung des Inhalts von Mikrokodupdates;
• Hash des öffentlichen RSA-Schlüssels, der zur Überprüfung der Signatur von Mikrokodupdates verwendet wird;
• Hash des öffentlichen RSA-Schlüssels, der zur Überprüfung der Signatur der von Intel entwickelten Code-Module ACM (Authenticated Code Module) dient, die die CPU vor der Ausführung des BIOS (Hallo Mikrokode) oder während seiner Laufzeit bei bestimmten Ereignissen ausführen kann.

Intel ME

Dieses Subsystem hat in unserem Blog sogar zwei des Artikelsein eigenes Kapitel erhalten. Erinnern wir uns daran, dass diese ausführbare Umgebung auf einem Mikrocontroller basiert, der im Chipsatz integriert ist, und die am meisten versteckte und privilegierte in der gesamten Systemarchitektur ist.

Trotz ihrer Verschleierung ist Intel ME ebenfalls eine Root of Trust, da sie Folgendes hat:

• ME-ROM — ein nichtflüchtiger, nicht beschreibbarer Speicher (es gibt keine Möglichkeit zur Aktualisierung), der den Startcode sowie den SHA256-Hash des öffentlichen RSA-Schlüssels enthält, der zur Überprüfung der Signatur der Intel ME-Firmware dient;
• AES-Schlüssel zur Speicherung geheimer Informationen;
• Zugriff auf die im Chipsatz integrierten Fuses (FPFs, Field Programmable Fuses) zur permanenten Speicherung bestimmter Informationen, einschließlich der vom Anbieter der Computersysteme vorgegebenen.

Intel Boot Guard 1.x

Ein kleiner Disclaimer. Die Versionsnummern der Intel Boot Guard-Technologie, die wir in diesem Artikel verwenden, sind hypothetisch und können nichts mit der Nummerierung zu tun haben, die in der internen Dokumentation von Intel verwendet wird. Außerdem wurden die hier angegebenen Informationen über die Implementierung dieser Technologie im Rahmen von Reverse Engineering gewonnen und können Ungenauigkeiten im Vergleich zur möglicherweise nie veröffentlichten Spezifikation zu Intel Boot Guard enthalten.

Intel Boot Guard (BG) ist eine hardwaregestützte Technologie zur Verifizierung der Authentizität des UEFI BIOS. Judging by its brief description in the book [Platform Embedded Security Technology Revealed, Kapitel Boot with Integrity, or Not Boot], funktioniert es als eine Kette vertrauenswürdiger Starts. Und das erste Glied herein ist der Boot-Code (Mikrocode) innerhalb der CPU, der durch das Ereignis RESET aktiviert wird (nicht zu verwechseln mit dem RESET-Vektor im BIOS!). Die CPU findet ein von Intel entwickeltes und signiertes Code-Modul (Intel BG startup ACM) im SPI-Flash-Speicher, lädt es in ihren Cache, verifiziert es (wie bereits erwähnt, hat die CPU einen Hash des öffentlichen Schlüssels, mit dem die Signatur des ACM überprüft wird) und startet.

Dieses Code-Modul ist verantwortlich für die Verifizierung des kleinen Anfangsteils des UEFI BIOS – des Initial Boot Block (IBB), der seinerseits Funktionen zur Verifizierung des Hauptteils des UEFI BIOS enthält. Somit ermöglicht Intel BG die Bestätigung der Authentizität des BIOS vor dem Laden des Betriebssystems (das möglicherweise unter der Aufsicht der Technologie Secure Boot läuft).

Die Technologie Intel BG sieht zwei Betriebsmodi vor (wobei der eine den anderen nicht stört, d.h. beide Modus können im System aktiviert oder deaktiviert sein).

Measured Boot

Im Modus Measured Boot (MB) "misst" jeder Boot-Komponente (beginnend mit CPU Boot ROM) die nächste, wobei die Möglichkeiten des TPM (Trusted Platform Module) genutzt werden. Für diejenigen, die damit nicht vertraut sind, hier eine Erklärung.

Das TPM hat PCRs (Platform Configuration Registers), in die das Ergebnis der Hash-Operation nach folgender Formel geschrieben wird:

Das aktuelle Wert von PCR hängt von dem vorherigen ab, wobei diese Register nur beim RESET des Systems zurückgesetzt werden.

Somit spiegeln im Modus MB zu einem bestimmten Zeitpunkt die PCRs einen einzigartigen (im Rahmen der Möglichkeiten der Hash-Operation) Identifikator des Codes oder der Daten wieder, die "gemessen" wurden. Die Werte der PCR können bei der Verschlüsselung bestimmter Daten genutzt werden (TPM_Seal). Nach dieser können sie nur dann entschlüsselt werden (TPM_Unseal), wenn die Werte der PCR als Ergebnis des Ladens unverändert geblieben sind (d.h., kein "gemessenes" Element wurde modifiziert).

Verified Boot

Der beunruhigendste Modus für Liebhaber der Modifikation des UEFI BIOS ist der Modus Verified Boot (VB), bei dem jede Boot-Komponente kryptografisch die Integrität und Authentizität der nächsten überprüft. Und im Falle eines Fehler bei der Verifizierung geschieht (eines der):

• Zeitüberschreitung von 1 bis 30 Minuten (damit der Benutzer versteht, warum sein Computer nicht hochfährt und, wenn möglich, versucht, das BIOS wiederherzustellen);
• sofortige Abschaltung (damit der Benutzer nichts versteht und, noch dazu, nichts tun kann);
• Weiterarbeiten mit unbeteiligtem Gesicht (der Fall, wenn es nicht um Sicherheit geht, da Wichtigeres ansteht).

Die Auswahl der Maßnahme hängt von der konfigurierten Intel BG-Konfiguration ab (genauer gesagt, von der so genannten Enforcement Policy), die vom Computerplattformanbieter dauerhaft in einem speziellen Speicher – den Fuse des Chipsatzes (FPF) – gespeichert wird. Auf diesen Punkt werden wir später genauer eingehen.

Neben der Konfiguration erzeugt der Anbieter zwei RSA 2048 Schlüssel und erstellt zwei Datenstrukturen (siehe Abbildung):

1. Das Manifest des Root-Keys des Anbieters (KEYM, OEM Root Key Manifest), in das er 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 Root-Keys des Anbieters) zur Überprüfung der Signatur dieses Manifests sowie die Signatur selbst einfügt;
2. Das Manifest des IBB (IBBM, Initial Boot Block Manifest), in das er die SVN dieses Manifests, den SHA256-Hash des IBB, den öffentlichen Schlüssel zur Überprüfung der Signatur dieses Manifests sowie die Signatur selbst einfügt.

Der SHA256-Hash des öffentlichen OEM Root Key wird dauerhaft in die Fuses des Chipsatzes (FPF) geschrieben, ebenso wie die Intel BG-Konfiguration. Wenn die Intel BG-Konfiguration das Aktivieren dieser Technologie vorsieht, kann die BIOS-Aktualisierung (d.h. die Möglichkeit, diese Manifeste neu zu berechnen) ab diesem Zeitpunkt nur vom Inhaber des privaten Teils des OEM Root Key durchgeführt werden, d.h. vom Anbieter.

Wenn man sich das Bild ansieht, kommt sofort der Zweifel auf, ob eine so lange Verifizierungskette wirklich nötig ist – man hätte doch ein einziges Manifest verwenden können. Warum komplizieren?

In Wirklichkeit ermöglicht es Intel dem Anbieter, verschiedene IBB-Schlüssel für unterschiedliche Produktlinien zu verwenden und einen als Root-Key. Wenn der private Teil des IBB-Schlüssels (mit dem das zweite Manifest signiert wird) entlarvt wird, betrifft der Vorfall nur eine Produktlinie und nur solange, bis der Anbieter ein neues Schlüsselpaar generiert und die neu berechneten Manifeste im nächsten BIOS-Update einfügt.

Wenn der Root-Schlüssel (mit dem das erste Manifest signiert wird) kompromittiert wird, kann er nicht ersetzt werden, da es kein Verfahren zur Widerrufung gibt, weil der Hash des öffentlichen Teils dieses Schlüssels einmalig und für immer in die FPFs programmiert wird.

Intel Boot Guard-Konfiguration

Lassen Sie uns nun näher auf die Intel BG-Konfiguration und deren Erstellung eingehen. Wenn man den entsprechenden Tab in der GUI des Flash Image Tool aus dem Intel System Tool Kit (STK) betrachtet, kann man feststellen, dass die Intel BG-Konfiguration den Hash des öffentlichen Teils des Root-Anbieterschlüssels, ein paar unverständliche Werte und das sogenannte Intel BG-Profil beinhaltet.

Die Struktur 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 – nichts tun
                                              // 01b – Herunterfahren mit Timeout
                                              // 11b – sofortiges Herunterfahren
	unsigned long : 26;
};

Im Allgemeinen ist die Intel BG-Konfiguration eine sehr flexible Entität. Betrachten wir zum Beispiel das Flag Force_Boot_Guard_ACM. Wenn es deaktiviert ist und das BG-Startup-ACM im SPI-Flash-Speicher nicht gefunden wird, gibt es keinen vertrauenswürdigen Boot. Es erfolgt ein nicht vertrauenswürdiger Boot.

Wie bereits erwähnt, kann die Durchsetzungsrichtlinie für den VB-Modus so konfiguriert werden, dass bei einer Verifikationsfehlermeldung wiederum ein nicht vertrauenswürdiger Boot erfolgt.

Solche Dinge in die Entscheidung der Anbieter zu legen...

Die GUI des Dienstprogramms bietet folgende „bereite“ Profile an:

Nummer
Modus
Beschreibung

0
No_FVME
Intel BG-Technologie ist deaktiviert

1
VE
VB-Modus aktiviert, Herunterfahren nach Timeout

2
VME
Beide Modi (VB und MB) aktiviert, Herunterfahren nach Timeout

3
VM
Beide Modi aktiviert, ohne Systemherunterfahren

4
FVE
VB-Modus aktiviert, sofortiges Herunterfahren

5
FVME
Beide Modi aktiviert, sofortiges Herunterfahren

Wie bereits erwähnt, muss die Intel BG-Konfiguration einmalig und für immer vom Systemanbieter in die Fuses des Chipsatzes (FPFs) geschrieben werden – ein kleines (laut unbestätigten Informationen, nur 256 Byte) physisches Speichersystem innerhalb des Chipsatzes, das außerhalb der Produktionskapazitäten von Intel programmiert werden kann (deshalb, genau genommen Field Programmable Fuses).

Es eignet sich hervorragend zur Speicherung von Konfigurationen, da:

• es einen einmal programmierbaren Bereich zur Speicherung von Daten gibt (genau dort wird die Intel BG-Konfiguration gespeichert);
• nur Intel ME kann es lesen und programmieren.

Um die Konfiguration für die Intel BG-Technologie auf einem bestimmten System festzulegen, führt der Hersteller während der Produktion Folgendes durch:

1. Mit dem Flash Image Tool (aus dem Intel STK) wird ein Firmware-Abbild mit der angegebenen Intel BG-Konfiguration in Form von Variablen im Intel ME-Bereich erstellt (sogenanntes temporäres Spiegelbild für FPFs);
2. Mit dem Flash Programming Tool (aus dem Intel STK) wird dieses Abbild in den SPI-Flash-Speicher des Systems geschrieben und der sogenannte Manufacturing Mode wird geschlossen (währenddessen wird der entsprechende Befehl an Intel ME gesendet).

Infolge dieser Operationen wird Intel ME die festgelegten Werte aus dem Spiegelbild für FPFs im ME-Bereich committen, die Berechtigungen in den SPI-Flash-Descriptoren auf die von Intel empfohlenen Werte einstellen (wie zu Beginn des Artikels beschrieben) und einen RESET des Systems durchführen.

Analyse der Implementierung von Intel Boot Guard

Um die Implementierung dieser Technologie anhand eines konkreten Beispiels zu analysieren, haben wir folgende Systeme auf Hinweise auf die Intel BG-Technologie überprüft:

Das System
Hinweis

Gigabyte GA-H170-D3H
Skylake, Unterstützung vorhanden

Gigabyte GA-Q170-D3H
Skylake, Unterstützung vorhanden

Gigabyte GA-B150-HD3
Skylake, Unterstützung vorhanden

MSI H170A Gaming Pro
Skylake, keine Unterstützung

Lenovo ThinkPad 460
Skylake, Unterstützung vorhanden, Technologie aktiviert

Lenovo Yoga 2 Pro
Haswell, keine Unterstützung

Lenovo U330p
Haswell, keine Unterstützung

Unter "Unterstützung" versteht man das Vorhandensein des Intel BG Startup ACM-Moduls, der oben erwähnten Manifeste und des entsprechenden Codes im BIOS, d.h. die Implementierung für die Analyse.

Als Beispiel nehmen wir das von der offiziellen Website des Herstellers heruntergeladene ABbild der SPI-Flash-Speicher für Gigabyte GA-H170-D3H (Version F4).

Intel CPU Boot ROM

Zunächst sprechen wir über die Aktionen des Prozessors, falls die Intel BG-Technologie aktiviert ist.

Es konnten keine entschlüsselten Microcode-Beispiele gefunden werden, daher bleibt die Frage offen, wie die nachfolgend beschriebenen Aktionen umgesetzt werden (im Microcode oder hardwareseitig). Dennoch steht fest, dass moderne Intel-Prozessoren in der Lage sind, diese Aktionen durchzuführen.

Nach dem Verlassen des RESET-Zustands findet der Prozessor (dessen Adressraum bereits mit dem Inhalt des Flashspeichers abgebildet ist) die FIT-Tabelle (Firmware Interface Table). Sie ist leicht zu finden, da ein Zeiger auf sie an der Adresse FFFF FFC0h gespeichert ist.

In dem betrachteten Beispiel liegt an dieser Adresse der Wert FFD6 9500h. Wenn der Prozessor auf diese Adresse zugreift, sieht er die FIT-Tabelle, deren Inhalt in Einträge unterteilt ist. Der erste Eintrag ist der Header der folgenden Struktur:

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_   ’
	unsigned long  NumEntries; // einschließlich FIT-Header-Eintrag
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

Aus unbekannter Ursache ist die Prüfziffer in diesen Tabellen nicht immer berechnet (das Feld bleibt null).

Die restlichen Einträge weisen auf verschiedene Binärdateien hin, die vor der Ausführung des BIOS geparst/exekutiert werden müssen, d.h. bevor der Übergang zum Legacy RESET-Vektor (FFFF FFF0h) erfolgt. Die Struktur jedes dieser Einträge sieht wie folgt aus:

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 Typ des Blocks an, auf den dieser Eintrag verweist. Uns sind mehrere Typen bekannt:

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

Jetzt ist offensichtlich, dass einer der Einträge auf den Speicherort des Intel BG Startup ACM-Binärdatei verweist. Die Struktur des Headers dieser Binärdatei ist typisch für die von der Firma Intel entwickelten Code-Module (ACMs, Mikrocode-Updates, Intel ME-Codebereiche, …).

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;           // im 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, verifiziert sie und startet sie.

Intel BG Startup ACM

Aus der Analyse der Funktionsweise dieses ACM wurde klar, dass er Folgendes tut:

• erhält von Intel ME die Konfiguration von Intel BG, die in die Fuses des Chipsatzes (FPF) geschrieben ist;
• findet die Manifeste KEYM und IBBM, überprüft sie.

Um diese Manifeste zu finden, verwendet das ACM ebenfalls die FIT-Tabelle, in der zwei Eintragstypen für die Angabe von Strukturdaten vorgesehen sind (siehe FIT_ENTRY_TYPES oben).

Lassen Sie uns näher auf die Manifeste eingehen. In der Struktur des ersten Manifests sehen wir mehrere unklare Konstanten, den Hash des öffentlichen Schlüssels aus dem zweiten Manifest und den öffentlichen Schlüssel OEM Root Key mit einer Signatur in Form einer eingebetteten 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-Größe?
	unsigned char  IbbmKeyHash[32]; // SHA256 eines IBBM-Publikums-Schlüssels
	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 OEM Root Key verwenden wir den SHA256-Hash aus den Fuses, der zu diesem Zeitpunkt bereits von Intel ME erhalten wurde.

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

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Boot-Richtlinien
	IBBS Ibbs;         // IBB-Beschreibung
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // IBBM-Signatur
};

In der ersten – 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
};

In der zweiten befindet sich der SHA256-Hash von IBB und die Anzahl der Deskriptoren, die den Inhalt von IBB beschreiben (d.h. den Teil, von dem 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-Größe ?
	unsigned char  IbbHash[32];       // SHA256 von einem IBB
	unsigned char  NumIbbDescriptors;
};

Die Deskriptoren von IBB folgen dieser Struktur, einer nach dem anderen. Ihr Inhalt hat folgendes Format:

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

Alles ist einfach: Jeder Deskriptor enthält die Adresse/Größe eines Teils von IBB. So ergibt die Verkettung der Blöcke, auf die diese Deskriptoren verweisen (in der Reihenfolge, in der sich die Deskriptoren befinden), das IBB. Und in der Regel ist IBB die Gesamtheit aller Module der Phasen SEC und PEI.

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

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

Der Prozessor wird also bereits vor dem Start des UEFI BIOS das ACM aktivieren, das die Echtheit des Inhalts der SEC- und PEI-Phase überprüft. Danach verlässt der Prozessor das ACM, springt zum RESET-Vektor und beginnt mit der Ausführung des BIOS.

Der verifizierte PEI-Bereich muss ein Modul enthalten, das den Rest des BIOS (DXE-Code) überprüft. Dieses Modul wird von einem IBV (Independent BIOS Vendor) oder vom Hersteller des Systems entwickelt. Da in unserem Fall nur Systeme von Lenovo und Gigabyte zur Verfügung standen, die Intel BG unterstützen, betrachten wir den Code, der speziell aus diesen Systemen extrahiert wurde.

UEFI BIOS-Modul LenovoVerifiedBootPei

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

Seine Aufgabe besteht darin, (über GUID) die Hash-Tabelle für DXE zu finden und DXE zu verifizieren.

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

Die Hash-Tabelle {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} hat das folgende Format:

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

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

UEFI BIOS-Modul BootGuardPei

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

Sein Algorithmus ist etwas anders, zielt jedoch auf dasselbe ab:

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 Hash-Tabelle {389CC6F2-1EA8-467B-AB8A-78E769AE2A15}, die er sucht, 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

Kurze Erklärung einer weiteren Implementierung von Intel Boot Guard, die in einem neueren System auf Basis von Intel SoC mit der Mikroarchitektur Apollo Lake — ASRock J4205-IT — gefunden wurde.

Obwohl diese Version nur in SoCs verwendet werden wird (neue Systeme mit Prozessorarchitektur Kaby Lake nutzen weiterhin Intel Boot Guard 1.x), ist sie von großem Interesse für das Studium einer neuen Architekturvariante für Plattformen auf Intel SoC, die spürbare Änderungen aufweist, wie:

• Die BIOS- und Intel ME-Bereiche (bzw. Intel TXE, gemäß der Terminologie für Intel SoC) sind jetzt ein einzelner IFWI-Bereich geworden.
• Obwohl Intel BG auf der Plattform aktiviert war, wurden keine Strukturen wie FIT, KEYM, IBBM im Flash-Speicher gefunden;
• Neben den TXE- und ISH-Kernen (x86) fügte der Chipsatz einen dritten Kern hinzu (übrigens wiederum ARC) – PMC (Power Management Controller), der für die Funktionsfähigkeit der Stromversorgungseinheit und die Überwachung der Leistung verantwortlich ist.

Der Inhalt der neuen IFWI-Region besteht aus einer Reihe folgender Module:

Offset
Name
Beschreibung

0000 2000h
SMIP
eine bestimmte Plattformkonfiguration, vom Anbieter signiert

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

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

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

0007 B000h
UCOD
Mikrocode-Updates für die CPU, von Intel signiert

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

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

0025 8000h
NFTP
der Codebereich der Intel TXE-Firmware, x86, von Intel signiert

0036 1000h
IUNP
unbekannt

0038 1000h
OBBP
UEFI BIOS, DXE-Phase, x86, nicht signiert

Bei der Analyse der TXE-Firmware wurde offensichtlich, dass TXE nach einem RESET den Prozessor in diesem Zustand hält, bis der grundlegende Inhalt des Adressraums für die CPU (FIT, ACM, RESET-Vektor ...) vorbereitet ist. TXE platziert diese Daten in ihrem SRAM, gewährt temporär dem Prozessor Zugriff darauf und "entlässt" ihn aus dem RESET.

Im Schutz vor Rootkits

Kommen wir nun zum "heißen" Thema. Eines Tages stellten wir fest, dass in den SPI-Flash-Descriptoren vieler Systeme Zugriffsberechtigungen für Regionen im SPI-Flash-Speicher festgelegt sind, sodass alle Benutzer dieses Speichers sowohl in jede Region schreiben als auch lesen können. D.h., keinerlei Einschränkungen.

Nach einer Überprüfung mit dem Tool MEinfo (aus dem Intel STK) sahen wir, dass der Herstellungsmodus auf diesen Systemen nicht geschlossen ist, wodurch die Fuses des Chipsatzes (FPFs) in einem undefinierten Zustand blieben. Ja, Intel BG ist in solchen Fällen weder aktiviert noch deaktiviert.

Es handelt sich um folgende Systeme (bezüglich Intel BG und was im Folgenden im Artikel dargestellt wird, sprechen wir über Systeme mit der Prozessor-Mikroarchitektur Haswell und neuer):

• alle Produkte von Gigabyte;
• alle Produkte von MSI;
• 21 Modelle von Lenovo-Laptops und 4 Modelle von Lenovo-Servern.

Natürlich haben wir diese Entdeckung den entsprechenden Anbietern sowie der Firma Intel gemeldet.

Eine angemessene Reaktion kam nur von Lenovo, die das Problem anerkannten und einen Patch veröffentlichten.

Gigabyte sie schienen die Informationen zur Schwachstelle zwar zur Kenntnis genommen zu haben, kommentierten aber nicht.

Kommunikation mit MSI Es gab keinerlei Fortschritt bei unserer Bitte, ihren offenen PGP-Schlüssel zu senden (um ihnen sicherheitsbezogene Informationen in verschlüsselter Form zu senden). Sie erklärten, dass sie „Hersteller von Geräten sind und keine PGP-Schlüssel erzeugen“.

Aber näher zum Thema. Da die Fuses in einem undefinierten Zustand belassen wurden, kann der Benutzer (oder ein Angreifer) sie selbst programmieren (das Schwierigste ist, Intel STK zu finden.). Dafür sind die folgenden Schritte erforderlich.

1. In das Windows-Betriebssystem booten (übrigens können die im Folgenden beschriebenen Schritte auch unter Linux durchgeführt werden, wenn eine analoge Intel STK für das benötigte Betriebssystem entwickelt wird). Mit dem Tool MEinfo überprüfen, ob die Fuses in diesem System nicht programmiert sind.

2. Den Inhalt des Flash-Speichers mit dem Flash Programming Tool auslesen.

3. Das ausgelesene Image mit einem beliebigen Tool zum Bearbeiten des UEFI BIOS öffnen, die erforderlichen Änderungen vornehmen (zum Beispiel einen Rootkit einfügen), bestehende KEYM- und IBBM-Strukturen im ME-Bereich erstellen/bearbeiten.

Im Bild ist der öffentliche Teil des RSA-Schlüssels hervorgehoben, dessen Hash in die Fuses des Chipsatzes zusammen mit der restlichen Intel BG-Konfiguration programmiert wird.

4. Mit dem Flash Image Tool ein neues Firmware-Image erstellen (mit der Konfiguration Intel BG).

5. Das neue Image mit dem Flash Programming Tool auf den Flash-Speicher schreiben, mit MEinfo prüfen, dass der ME-Bereich nun die Intel BG-Konfiguration enthält.

6. Mit dem Flash Programming Tool den Manufacturing Mode schließen.

7. Das System wird neu gestartet, nach dem Neustart kann man mit MEinfo überprüfen, dass die FPFs jetzt programmiert sind.

Diese Maßnahmen aktivieren dauerhaft Intel BG auf diesem System. Maßnahmen können nicht rückgängig gemacht werden, was bedeutet:

• Eine Aktualisierung des UEFI BIOS auf diesem System kann nur von dem Inhaber des privaten Teils des Root-Schlüssels durchgeführt werden (d.h. von demjenigen, der Intel BG aktiviert hat);
• Wenn man die Original-Firmware auf dieses System zurückbringt, zum Beispiel mit Hilfe eines Programmiergeräts, wird es nicht einmal starten (Folge der Enforcement-Richtlinie im Falle eines Verifizierungsfehlers);
• Um dieses UEFI BIOS loszuwerden, müsste man den Chipsatz mit programmierten FPFs gegen einen „sauberen“ ersetzen (d.h. den Chipsatz umlöten, wenn man Zugang zu einer Infrarot-Lötstation hat, die so viel kostet wie ein Auto, oder einfach das Motherboard ersetzen).

Um zu verstehen, was ein solcher Rootkit anrichten kann, muss man einschätzen, was es ermöglicht, eigenen Code in der UEFI BIOS-Umgebung auszuführen. Zum Beispiel im privilegiertesten Modus des Prozessors – SMM. Ein solcher Rootkit kann folgende Eigenschaften haben:

• parallel zum Betriebssystem ausgeführt werden (es kann konfiguriert werden, um durch die Generierung eines SMI-Interrupts zu arbeiten, der durch einen Timer ausgelöst wird);
• alle Vorteile des Betriebs im SMM-Modus genießen (voller Zugriff auf den Inhalt des Arbeitsspeichers und auf die Hardware-Ressourcen, Geheimhaltung vor dem Betriebssystem);
• der Programmcode des Rootkits kann in verschlüsselter Form vorliegen und beim Start im SMM-Modus entschlüsselt werden. Als Schlüssel für die Verschlüsselung können beliebige Daten verwendet werden, die nur im SMM-Modus verfügbar sind. Zum Beispiel ein Hash von einer Reihe von Adressen im SMRAM. Um diesen Schlüssel zu erhalten, muss man in den SMM gelangen. Das kann auf zwei Arten geschehen. Entweder eine RCE im SMM-Code finden und ausnutzen oder ein eigenes SMM-Modul in das BIOS einfügen, was nicht möglich ist, da wir Boot Guard aktiviert haben.

Somit ermöglicht diese Schwachstelle einem Angreifer:

• einen im System versteckten, nicht löschbaren Rootkit unbekannten Zwecks zu erstellen;
• seinen Code auf einem der Chipsatzkerne innerhalb von Intel SoC auszuführen, nämlich auf Intel ISH (sehen Sie sich das Bild genau an).

Obwohl die Möglichkeiten des Intel ISH-Subsystems noch nicht untersucht sind, erscheint es als ein interessanter Angriffsvektor auf Intel ME.

Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.

1. Die Untersuchung hat eine technische Beschreibung der Funktionsweise der Intel Boot Guard-Technologie geliefert. Der Nachteil ist, dass einige Geheimnisse im Intel-Modell der Sicherheit durch Verschleierung bestehen.
2. Ein Angriffsszenario wurde vorgestellt, das es ermöglicht, einen nicht löschbaren Rootkit im System zu erstellen.
3. Wir haben gesehen, dass moderne Intel-Prozessoren in der Lage sind, viel proprietären Code noch vor dem Starten des BIOS auszuführen.
4. Plattformen mit Intel 64-Architektur werden zunehmend weniger geeignet für den Einsatz von freier Software: Hardware-Validierung, die zunehmende Anzahl proprietärer Technologien und Subsysteme (drei Kerne im SoC-Chipsatz: x86 ME, x86 ISH und ARC PMC).

Minderungen

Anbieter, die absichtlich den Herstellermodus offen lassen, sollten ihn unbedingt schließen. Bisher wird nur wegschaut, und neue Kaby Lake-Systeme zeigen dies.

Benutzer können Intel BG auf ihren Systemen (die von der beschriebenen Schwachstelle betroffen sind) selbst deaktivieren, indem sie das Flash Programming Tool mit dem Parameter -closemnf ausführen. Zuvor sollte sichergestellt werden (mithilfe von MEinfo), dass die Intel BG-Konfiguration in der ME-Region tatsächlich das Deaktivieren dieser Technologie nach dem Programmieren in die FPFs vorsieht.

Quelle: habr.com