Vertrauenswürdiger Start bei Schrödinger. Intel Boot Guard

Lassen Sie uns wieder auf ein grundlegendes Niveau zurückkehren und über die Sicherheit von BIOS-Versionen auf x86-kompatiblen Computerplattformen sprechen. Diesmal liegt der Schwerpunkt auf Intel Boot Guard (nicht zu verwechseln mit Intel BIOS Guard!) – einer hardwaregestützten Technologie für den sicheren Bootvorgang des BIOS, die vom Anbieter des Computersystems während der Produktion dauerhaft aktiviert oder deaktiviert werden kann. Der Rezept für die Untersuchung ist uns bereits bekannt: Wir analysieren die Implementierung dieser Technologie durch Reverse Engineering, beschreiben ihre Architektur und fügen unzureichend dokumentierte Details hinzu, gewürzt mit Angriffsvektoren und gut vermischt. Eine interessante Anekdote dazu ist, wie ein über Jahre hinweg kopierter Produktionsfehler bei mehreren Anbietern es einem potenziellen Angreifer ermöglicht, diese Technologie zu nutzen, um ein unauffindbares (sogar für Programmierer) Rootkit im System zu installieren.

Übrigens basiert der Artikel auf den Berichten „Im Schutz von Rootkits: Intel Boot Guard“ von der Konferenz ZeroNights 2016 und dem 29. Treffen DefCon Russland (beide Präsentationen hier).

BIOS der Computerplattform mit Intel 64 Architektur

Beginnen wir mit der Frage: Was ist die Firmware einer modernen Computerplattform mit Intel 64-Architektur? Natürlich ist das das UEFI BIOS. Aber diese Antwort wäre ungenau. Schauen wir uns das Bild an, das die Desktop- (oder Laptop-) Variante dieser Architektur zeigt.

Die Grundlage besteht aus folgendem Zusammenspiel:

• Der CPU (Central Processing Unit), der neben den Hauptkernen auch einen Grafikprozessor (nicht in allen Modellen) und einen integrierten Speichercontroller (IMC, Integrated Memory Controller) beinhaltet;
• Des Chipsatzes (PCH, Platform Controller Hub), der verschiedene Controller für die Interaktion mit Peripheriegeräten und das Management der Subsysteme enthält. Darunter ist die bekannte Intel Management Engine (ME), die ebenfalls eine Firmware hat (Intel ME firmware).

Bei Laptops kommt zusätzlich ein integrierter Controller (ACPI EC, Advanced Control and Power Interface Embedded Controller) hinzu, der für die Funktionalität des Energieverwaltungssystems, des Touchpads, der Tastatur und der Fn-Tasten (Helligkeit, Lautstärke, Tastaturbeleuchtung usw.) verantwortlich ist. Und auch dieser Controller hat seine eigene Firmware.

Die oben genannten Firmware-Versionen bilden die Systemfirmware, die im gemeinsamen SPI-Flash-Speicher gespeichert ist. Um Verwirrung bei den Nutzern dieses Speichers zu vermeiden, ist der Inhalt in die folgenden Bereiche unterteilt (wie im Bild dargestellt):

• UEFI BIOS;
• Firmware des ACPI EC (ein separater Bereich wurde mit der Mikroarchitektur Skylake (2015) eingeführt, jedoch haben wir bisher keine praktischen Anwendungen gesehen, sodass die Firmware des Embedded Controllers weiterhin Bestandteil des UEFI BIOS ist);
• Firmware Intel ME;
• Konfiguration (MAC-Adresse usw.) des integrierten GbE-Netzwerkadapters (Gigabit Ethernet);
• Flash-Beschreibungen (Flash Descriptors) – der Hauptbereich des Flash-Speichers, der Hinweise auf die anderen Bereiche sowie Zugriffsberechtigungen auf diese enthält.

Die Zugriffskontrolle auf Regionen (gemäß den festgelegten Berechtigungen) wird vom SPI-Bus-Controller verwaltet, der im SPI-Chipsatz integriert ist und über den der Zugriff auf diesen Speicher erfolgt. Wenn die Berechtigungen auf die von Intel empfohlenen Werte (aus Sicherheitsgründen) eingestellt sind, hat jeder Benutzer des SPI-Flashspeichers vollständigen Zugriff (lesen/schreiben) nur auf seine eigene Region. Alle anderen Regionen sind entweder nur im Lesemodus zugänglich oder gar nicht zugänglich. Es ist allgemein bekannt, dass die CPU in vielen Systemen vollständigen Zugriff auf das UEFI-BIOS und GbE hat, jedoch nur Lesezugriff auf Flash-Deskriptoren und überhaupt keinen Zugriff auf die Intel ME-Region. Warum bei vielen, aber nicht bei allen? Was empfohlen wird, ist nicht zwingend. Weitere Details werden im weiteren Verlauf des Artikels behandelt.

Schutzmechanismen der Firmware einer 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 in ihr festzusetzen (Updates/Wiederinstallationen des Betriebssystems zu überstehen), ihren Code in den privilegiertesten Modi auszuführen usw. Und die Trennung des Zugriffs auf die Regionen des SPI-Flashspeichers reicht selbstverständlich nicht aus. Daher werden verschiedene, jeweils umgebungsspezifische Mechanismen zum Schutz der Firmware vor Modifikationen eingesetzt.

So ist die Firmware Intel ME zur Kontrolle der Integrität und Authentizität signiert und wird bei jedem Laden in den ME UMA-Speicher vom ME-Controller überprüft. Dieser Verifizierungsprozess wurde bereits in einem unserer Artikel, der sich mit dem Intel ME-System befasst, behandelt.

Die ACPI EC-Firmware wird in der Regel nur auf Integrität geprüft. Da dieser Binärcode jedoch Bestandteil des UEFI BIOS ist, unterliegt er fast immer denselben Schutzmechanismen wie das UEFI BIOS. Darüber werden wir sprechen.

Diese Mechanismen lassen sich in zwei Kategorien einteilen.

Schreibschutz für den UEFI BIOS-Bereich

1. Physikalischer Schutz des Inhalts des SPI-Flashspeichers durch einen Write-Protect-Jumper;
2. Schutz des UEFI BIOS-Projektionsbereichs im Adressraum der CPU durch PRx-Register des Chipsatzes;
3. Blockierung von Schreibversuchen in den UEFI BIOS-Bereich durch Erzeugung und Verarbeitung des entsprechenden SMI-Interrupts mittels Setzen der Bits BIOS_WE/BLE und SMM_BWP in den Chipsatzregistern;
4. Eine fortgeschrittenere Variante dieses Schutzes ist Intel BIOS Guard (PFAT).

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

Es ist wichtig zu beachten, dass auf einem bestimmten System (abhängig vom Anbieter) nicht alle oben genannten Schutzmechanismen angewendet werden können, sie möglicherweise gar nicht implementiert sind oder schwach umgesetzt werden. Weitere Informationen zu diesen Mechanismen und ihrer Implementierung finden Sie in in diesem Artikel. Interessierten empfehlen wir, den gesamten Artikelzyklus zur Sicherheit von UEFI BIOS von CodeRush.

Überprüfung der Authentizität des UEFI BIOS

Wenn wir über vertraute Boot-Technologien sprechen, denken wir zuerst an Secure Boot. Architektonisch dient es jedoch der Authentifizierung von externen Komponenten im Verhältnis zum UEFI BIOS (Treibern, Bootloadern usw.) und nicht der Firmware selbst.

Deshalb implementierte Intel in SoCs mit der Mikroarchitektur Bay Trail (2012) einen hardwareseitigen, nicht abschaltbaren Secure Boot (Verified Boot), der nichts mit der zuvor genannten Technologiesecure Boot zu tun hat. Später (2013) wurde dieser Mechanismus verbessert und unter dem Namen Intel Boot Guard für Desktop-Systeme mit der Mikroarchitektur Haswell veröffentlicht.

Bevor wir Intel Boot Guard beschreiben, lassen Sie uns die Ausführungsumgebungen in der Intel 64 Architektur untersuchen, die zugleich die Wurzeln des Vertrauens für diese vertrauenswürdige Boot-Technologie darstellen.

Intel CPU

Käpt'n sagt, dass der Prozessor die Hauptausführungsumgebung in der Intel 64 Architektur ist. Warum ist er der Wurzel des Vertrauens? Es stellt sich heraus, dass ihn folgende Elemente dazu machen:

• Microcode ROM – nichtflüchtiger, nicht beschreibbarer Speicher zur Speicherung von Mikrokode. Es wird angenommen, dass Mikrokode die Implementierung des Befehlssystems des Prozessors in einfachsten Instruktionen darstellt. Auch im Mikrokode können Fehler auftreten. Fehler. Daher finden sich im BIOS Binärdateien mit Aktualisierungen des Mikrokodes (die während des Bootvorgangs angewendet werden, da ROM nicht überschrieben werden kann). Der Inhalt dieser Binärdateien ist verschlüsselt, was die Analyse erheblich erschwert (deshalb ist der spezifische Inhalt des Mikrokodes nur den Entwicklern bekannt), und ist signiert, um die Integrität und Authentizität zu überprüfen.
• AES-Schlüssel zur Entschlüsselung des Inhalts der Mikrokodupdates;
• Hash des öffentlichen RSA-Schlüssels, mit dem die Signatur der Mikrokodupdates überprüft wird;
• Hash des öffentlichen RSA-Schlüssels, mit dem die Signatur der von Intel entwickelten Authentifizierten Code Module (ACM) überprüft wird, die die CPU vor dem Start des BIOS (Hallo Mikrokode) oder während seiner Ausführung in bestimmten Fällen ausführen kann.

Intel ME

Unserem Blog wurde dieser Unterbereich sogar zwei einem Artikel. Lassen Sie uns daran erinnern, dass diese ausführbare Umgebung auf einem im Chipsatz integrierten Mikrocontroller basiert und die am wenigsten sichtbare und privilegierte im System ist.

Trotz ihrer Unsichtbarkeit ist Intel ME auch die Root of Trust, da sie Folgendes beinhaltet:

• ME ROM - ein nichtflüchtiger, nicht beschreibbarer Speicher (aktualisierbare Methoden sind nicht vorgesehen), der den Startcode sowie den SHA256-Hash des öffentlichen RSA-Schlüssels enthält, mit dem die Firmware von Intel ME signiert wird;
• AES-Schlüssel zum Speichern geheimer Informationen;
• Zugriff auf die im Chipsatz integrierte Gruppe von Fuses (FPFs, Field Programmable Fuses) zur permanenten Speicherung bestimmter Informationen, einschließlich der vom Anbieter der Computersysteme festgelegten.

Intel Boot Guard 1.x

Ein kleiner Hinweis: Die Versionsnummern der Intel Boot Guard-Technologie, die wir in diesem Artikel verwenden, sind beispielhaft und haben möglicherweise nichts mit der Nummerierung zu tun, die in der internen Dokumentation von Intel verwendet wird. Darüber hinaus stammen die hier dargestellten Informationen zur Implementierung dieser Technologie aus Reverse Engineering und könnten im Vergleich zur Intel Boot Guard-Spezifikation Ungenauigkeiten aufweisen, die wahrscheinlich nie veröffentlicht wird.

Intel Boot Guard (BG) ist also eine hardwaregestützte Technologie zur Verifizierung der Authentizität des UEFI BIOS. Laut der kurzen Beschreibung in dem Buch [Platform Embedded Security Technology Revealed, Kapitel Boot with Integrity, or Not Boot] funktioniert sie als vertrauenswürdige Startkette. Das erste Glied in dieser Kette ist der Bootcode (Mikrocode) innerhalb der CPU, der beim RESET-Ereignis gestartet wird (nicht zu verwechseln mit dem RESET-Vektor im BIOS!). Die CPU findet im SPI-Flash-Speicher das von Intel entwickelte und signierte Code-Modul (Intel BG startup ACM), lädt es in ihren Cache, verifiziert es (wie zuvor erwähnt, hat die CPU den Hash des öffentlichen Schlüssels, der zur Überprüfung der Signatur des ACM verwendet wird) und startet es.

Dieses Codemodul ist verantwortlich für die Verifizierung des kleinen Startteils des UEFI-BIOS – des Initial Boot Block (IBB), der wiederum Funktionen zur Verifikation des Hauptteils des UEFI-BIOS enthält. So ermöglicht Intel BG, die Echtheit des BIOS vor dem Laden des Betriebssystems (das unter der Technologie Secure Boot ausgeführt werden kann) zu überprüfen.

Die Technologie Intel BG bietet zwei Betriebsmodi an (die sich nicht gegenseitig ausschließen, d.h. beide Modi können im System aktiviert oder deaktiviert werden).

Measured Boot

Im Modus Measured Boot (MB) "misst" jede Boot-Komponente (beginnend mit dem CPU-Boot-ROM) die nächste, indem sie die Möglichkeiten des TPM (Trusted Platform Module) nutzt. Für diejenigen, die nicht im Bilde sind, eine kurze Erklärung.

TPM verfügt über PCRs (Platform Configuration Registers), in denen das Ergebnis der Hash-Berechnung nach folgender Formel gespeichert wird:

Das aktuelle PCR-Wert hängt vom vorherigen ab, wobei die Registerdaten nur bei einem RESET des Systems zurückgesetzt werden.

Im MB-Modus spiegeln die PCRs zu einem bestimmten Zeitpunkt einen einzigartigen (innerhalb der Möglichkeiten der Hash-Operation) Identifikator für den Code oder die Daten wider, die „gemessen“ wurden. Die Werte der PCR können bei der Verschlüsselung bestimmter Daten (TPM_Seal) verwendet werden. Danach ist eine Entschlüsselung (TPM_Unseal) nur möglich, wenn die Werte der PCR nach dem Booten unverändert bleiben (d.h. kein „gemessenes“ Element wurde modifiziert).

Verified Boot

Der erschreckendste Aspekt für diejenigen, die den UEFI BIOS modifizieren wollen, ist der Verified Boot (VB) Modus, in dem jede Boot-Komponente kryptografisch die Integrität und Echtheit der nächsten überprüft. Bei einem Verifikationsfehler geschieht eines der Folgenden:

• ein Herunterfahren nach einem Timeout von 1 bis 30 Minuten (damit der Benutzer verstehen kann, warum sein Computer nicht startet und gegebenenfalls versucht, das BIOS wiederherzustellen);
• ein sofortiges Herunterfahren (damit der Benutzer nichts verstehen und erst recht nichts tun kann);
• eine Fortsetzung des Betriebs mit gleichgültigem Ausdruck (in diesem Fall ist Sicherheit nicht wichtig, denn es gibt wichtigere Dinge).

Die Auswahl der Maßnahme hängt von der konfigurierten Intel BG (insbesondere von der sogenannten Enforcement Policy) ab, die vom Anbieter der Computerplattform dauerhaft in einem speziellen Speicher – den Fuses des Chipsatzes (FPFs) – gespeichert wird. Wir werden später ausführlicher auf diesen Punkt eingehen.

Zusätzlich zur Konfiguration generiert der Anbieter zwei RSA 2048 Schlüssel und erstellt zwei Datenstrukturen (wie im Bild dargestellt):

1. Das Manifest des Root-Schlüssels des Anbieters (KEYM, OEM Root Key Manifest), das die SVN (Security Version Number) dieses Manifests, den SHA256-Hash des öffentlichen Schlüssels des nachfolgenden Manifests, den öffentlichen RSA-Schlüssel (d.h. den öffentlichen Teil des Root-Schlüssels des Anbieters) zur Überprüfung der Signatur dieses Manifests und die Signatur selbst enthält;
2. Das IBB-Manifest (IBBM, Initial Boot Block Manifest), das die 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 öffentlichen OEM Root Key wird dauerhaft in die Fuses des Chipsatzes (FPF) geschrieben, ebenso wie die Intel BG-Konfiguration. Wenn die Intel BG-Konfiguration diese Technologie aktiviert, kann ab diesem Zeitpunkt das BIOS auf diesem System nur noch von dem Inhaber des privaten OEM Root Key aktualisiert werden, also vom Anbieter.

Auf den ersten Blick stellt sich die Frage, ob eine so lange Verifizierungskette wirklich notwendig ist – man hätte auch einen einzigen Manifest verwenden können. Warum das Ganze komplizierter machen?

Tatsächlich bietet Intel dem Anbieter auf diese Weise die Möglichkeit, verschiedene IBB-Schlüssel für unterschiedliche Produktlinien zu verwenden, wobei ein Schlüssel als Root-Key dient. Wenn der private IBB-Schlüssel, der den zweiten Manifest signiert, kompromittiert wird, betrifft der Vorfall nur eine Produktlinie und zwar nur 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 ist, kann er nicht ersetzt werden. Es gibt keine Rückrufverfahren, da der Hash des öffentlichen Teils dieses Schlüssels einmalig in die FPFs programmiert wird.

Konfiguration von Intel Boot Guard

Jetzt werfen wir einen detaillierteren Blick auf die Konfiguration von Intel BG und den Prozess ihrer Erstellung. Wenn man die entsprechende Registerkarte in der GUI des Flash Image Tool aus dem Intel System Tool Kit (STK) betrachtet, erkennt man, dass die Konfiguration von Intel BG den Hash des öffentlichen Teils des Root-Schlüssels des Anbieters, einige nicht näher bezeichnete Werte und das sogenannte Intel BG-Profil umfasst.

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 Konfiguration von Intel BG eine sehr flexible Entität. Betrachten wir beispielsweise das Flag Force_Boot_Guard_ACM. Wenn es deaktiviert ist, gibt es keine vertrauenswürdige Boot-Prozedur, wenn das BG-Startup-ACM im SPI-Flashspeicher nicht gefunden wird. Es erfolgt ein nicht vertrauenswürdiger Boot.

Wie bereits erwähnt, kann die Durchsetzungsrichtlinie für den VB-Modus so konfiguriert werden, dass bei einem Verifizierungsfehler erneut ein unvertrauenswürdiger Start erfolgt.

Solche Entscheidungen sollten nicht dem Ermessen der Anbieter überlassen werden…

Die GUI-Utilities bieten folgende „vorgefertigte“ Profile an:

Nummer
Modus
Beschreibung

0
No_FVME
Intel BG-Technologie ist deaktiviert

1
VE
VB-Modus aktiviert, Timeout-Abschaltung

2
VME
Beide Modi (VB und MB) aktiviert, Timeout-Abschaltung

3
VM
Beide Modi aktiviert, keine Systemabschaltung

4
FVE
VB-Modus aktiviert, sofortige Abschaltung

5
FVME
Beide Modi aktiviert, sofortige Abschaltung

Wie bereits erwähnt, muss die Intel BG-Konfiguration einmal für alle Zeiten vom Systemanbieter in die Fuses des Chipsatzes (FPF) geschrieben werden – ein kleines (ungeprüften Informationen zufolge nur 256 Byte) Hardware-Speicher für Informationen innerhalb des Chipsatzes, das außerhalb der Produktionsstätten von Intel programmiert werden kann (daher, genau Field Programmable Fuses).

Es eignet sich hervorragend zur Speicherung der Konfiguration, da:

• es einen einmal programmierbaren Bereich für die Datenspeicherung hat (dorthin wird die Intel BG-Konfiguration aufgezeichnet);
• lesen und programmieren kann es nur Intel ME.

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 gewünschten Intel BG-Konfiguration in Form von Variablen innerhalb der Intel ME-Region erstellt (das sogenannte temporäre 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 geschlossen (wobei der entsprechende Befehl an die Intel ME gesendet wird).

Als Ergebnis dieser Vorgänge wird Intel ME die zugewiesenen Werte aus dem Spiegelbild für FPFs in die ME-Region übernehmen, die Berechtigungen in den SPI-Flash-Dekschreibern auf die von Intel empfohlenen Werte setzen (wie zu Beginn des Artikels beschrieben) und einen RESET des Systems durchführen.

Analyse der Implementierung von Intel Boot Guard

Um die Umsetzung dieser Technologie anhand eines konkreten Beispiels zu analysieren, haben wir die folgenden Systeme auf Spuren der Intel BG-Technologie überprüft:

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" verstehen wir das Vorhandensein des Intel BG Startup ACM Moduls, der oben erwähnten Manifestdateien und des entsprechenden Codes im BIOS, d.h. die Implementierung für die Analyse.

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

Intel CPU Boot-ROM

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

Es konnten keine entschlüsselten Microcode-Beispiele gefunden werden, daher bleibt die Frage offen, wie die im Folgenden beschriebenen Aktionen umgesetzt sind (im Microcode oder hardwaremäßig). Dennoch ist es eine Tatsache, dass moderne Intel-Prozessoren in der Lage sind, diese Aktionen auszuführen.

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

In unserem Beispiel steht 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 Kopf 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 unbekannten Gründen ist die Prüfziffer in diesen Tabellen nicht immer berechnet (Feld bleibt null).

Die restlichen Einträge weisen auf verschiedene Binärdateien hin, die noch vor der Ausführung des BIOS geparst/ausgeführt werden müssen, d. h. bevor der Übergang zum Legacy-RESET-Vektor (FFFF FFF0h) erfolgt. 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 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 der Binärdatei Intel BG Startup ACM verweist. Die Struktur des Headers dieser Binärdatei ist typisch für die von Intel entwickelten Code-Module (ACM, Mikrokodupdates, 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, verifiziert sie und startet sie.

Intel BG Startup ACM

Die Analyse der Funktionsweise dieses ACM hat gezeigt, dass er Folgendes tut:

• er erhält von Intel ME die Intel BG-Konfiguration, die im Fusionsspeicher des Chips (FPF) gespeichert ist;
• er findet die Manifestdateien KEYM und IBBM und verifiziert diese.

Um diese Manifestdateien zu finden, nutzt der ACM ebenfalls die FIT-Tabelle, die zwei Arten von Einträgen für die Angabe der Strukturdaten enthält (siehe FIT_ENTRY_TYPES oben).

Lasst uns näher auf die Manifestdateien eingehen. In der Struktur des ersten Manifests sehen wir mehrere unklare Konstanten, den Hash des öffentlichen Schlüssels aus dem zweiten Manifest und den OEM Root Key mit einer Unterschrift 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-Öffentlichen 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 Verifizierung des öffentlichen Schlüssels OEM Root Key verwenden wir den SHA256-Hash der Fusionsdaten, 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 des IBB und die Anzahl der Deskriptoren, die den Inhalt des IBB beschreiben (d.h. das, wovon 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 eines IBB
	unsigned char  NumIbbDescriptors;
};

Die IBB-Dek descriptor 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;
};

Es ist ganz einfach: Jeder Descriptor enthält die Adresse/Größe eines Stücks IBB. Die Verkettung der Blöcke, auf die diese Deskriptoren verweisen (in der Reihenfolge, in der sich die Deskriptoren selbst befinden), ist das IBB. In der Regel ist das IBB eine Sammlung aller SEC- und PEI-Modulen.

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

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

Bereits vor der Ausführung des UEFI BIOS startet der Prozessor das ACM, welches die Integrität der Inhalte der SEC- und PEI-Phasen überprüft. Danach verlässt der Prozessor das ACM, wechselt 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 entweder von einem IBV (Independent BIOS Vendor) oder dem Systemanbieter selbst entwickelt. Da wir nur Systeme von Lenovo und Gigabyte mit Intel BG Unterstützung zur Verfügung haben, 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}, das von Lenovo entwickelt wurde.

Seine Aufgabe besteht darin, (basierend auf der 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 folgendes 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 BootGuardPei-Modul {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 Arbeitsalgorithmus ist etwas anders, aber die Grundidee bleibt die gleiche:

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 folgendes 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

Kurz möchten wir eine weitere Implementierung von Intel Boot Guard vorstellen, 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 wird (neue Systeme mit der Prozessor-Mikroarchitektur Kaby Lake verwenden weiterhin Intel Boot Guard 1.x), ist sie von großem Interesse, um die neue Architekturoption für Intel SoC-Plattformen zu untersuchen, in der bemerkenswerte Änderungen stattgefunden haben, wie zum Beispiel:

• BIOS-Regionen und Intel ME (besser gesagt Intel TXE, gemäß der Terminologie für Intel SoCs) sind jetzt eine einzige IFWI-Region;
• Obwohl die Plattform mit Intel BG aktiviert war, wurden solche Strukturen wie FIT, KEYM und IBBM im Flash-Speicher nicht gefunden.
• Neben den TXE- und ISH-Kernen (x86) hat das Chipsatzteam einen dritten Kern hinzugefügt (übrigens wieder ARC) – PMC (Power Management Controller), der für die Betriebssicherheit der Stromversorgung und die Leistungsüberwachung verantwortlich ist.

Der Inhalt der neuen IFWI-Region besteht aus einem Set der folgenden Module:

Offset
Name
Beschreibung

0000 2000h
SMIP
eine bestimmte Konfiguration der Plattform, signiert vom Anbieter

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

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

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

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

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

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

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

0036 1000h
IUNP
unbekannt

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

Bei der Analyse der TXE-Firmware wurde deutlich, 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 seinem SRAM, gewährt vorübergehend dem Prozessor Zugriff darauf und lässt ihn dann aus dem RESET los.

Wächter gegen Rootkits

Kommen wir nun zum „heißen Thema“. Wir haben einmal festgestellt, dass in vielen Systemen in den SPI-Flash-Datenblättern Berechtigungen für den Zugriff auf Bereiche des SPI-Flash-Speichers so eingestellt sind, dass alle Benutzer dieses Speichers jeden Bereich sowohl lesen als auch schreiben können. Das heißt, es gibt keinerlei Einschränkungen.

Nach der Überprüfung mit dem Werkzeug MEinfo (aus dem Intel STK) stellten wir fest, dass der Herstellermodus auf diesen Systemen nicht deaktiviert ist. Folglich sind die Fuse-Elemente des Chipsatzes (FPFs) in einem undefinierten Zustand belassen worden. Ja, Intel BG ist in solchen Fällen weder aktiviert noch deaktiviert.

Es geht um folgende Systeme (in Bezug auf Intel BG und das, was im weiteren Verlauf des Artikels erläutert wird, sprechen wir über Systeme mit der Mikroarchitektur Haswell und neuer):

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

Selbstverständlich haben wir diesen Herstellern und auch der Firma Intel von unserem Fund berichtet.

Eine angemessene Reaktion kam nur von Lenovo, die das Problem anerkannt haben und einen Patch veröffentlicht haben..

Gigabyte scheint die Information über die Verletzbarkeit zwar entgegengenommen zu haben, hat sich jedoch nicht weiter dazu geäußert.

Die Kommunikation mit MSI kam völlig zum Stillstand, nachdem wir darum gebeten hatten, uns ihren offenen PGP-Schlüssel zuzuschicken (um ihnen die Sicherheitswarnung verschlüsselt zu senden). Sie erklärten, dass sie „Hersteller von Hardware sind und keine PGP-Keys erstellen“.

Aber kommen wir zum Wesentlichen. Da die Fuses in einem unbestimmten Zustand gelassen wurden, kann der Benutzer (oder ein Angreifer) sie selbst programmieren (das Schwierigste ist, den Intel STK zu finden). Dazu müssen die folgenden Schritte ausgeführt werden.

1. In das Betriebssystem Windows booten (im Grunde können die unten beschriebenen Schritte auch unter Linux durchgeführt werden, wenn ein entsprechender Intel STK für das benötigte Betriebssystem entwickelt wird). Mit dem Tool MEinfo sicherstellen, dass die Fuses auf diesem System nicht programmiert sind.

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

3. Öffnen Sie das abgelesene Image mit einem beliebigen UEFI BIOS Bearbeitungswerkzeug und nehmen Sie die erforderlichen Änderungen vor (z. B. einen Rootkit einfügen), erstellen/bearbeiten Sie die vorhandenen KEYM- und IBBM-Strukturen im ME-Bereich.

Auf dem Bild ist der öffentliche Teil des RSA-Schlüssels hervorgehoben, dessen Hash zusammen mit der restlichen Intel BG-Konfiguration in die Fuses des Chips eingeprägt wird.

4. Verwenden Sie das Flash Image Tool, um ein neues Firmware-Image zu erstellen (unter Angabe der Intel BG-Konfiguration).

5. Schreiben Sie das neue Image mit dem Flash Programming Tool auf den Flash-Speicher und stellen Sie mit MEinfo sicher, dass der ME-Bereich jetzt die Intel BG-Konfiguration enthält.

6. Schließen Sie den Herstellermodus mit dem Flash Programming Tool.

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 Intel BG auf diesem System dauerhaft. Eine Rückgängigmachung dieser Aktion ist nicht möglich, was bedeutet:

• Die UEFI BIOS auf diesem System kann nur von dem Besitzer des privaten Teils des Wurzel-Schlüssels (d.h. der Person, die Intel BG aktiviert hat) aktualisiert werden;
• wenn das Original-Firmware-Image dieses Systems mit einem Programmierer zurückgegeben wird, wird es sich nicht einmal einschalten (Folge der Durchsetzungsrichtlinie im Falle einer Verifizierungsfehlers);
• Um ein solches UEFI BIOS zu beseitigen, muss der Chipsatz mit programmierten FPFs durch einen "sauberen" ersetzt werden (d.h. den Chipsatz umlöten, wenn man Zugang zu einer Infrarot-Lötstation im Preis eines Autos hat, oder einfach das Motherboard ersetzen).

Um zu verstehen, was ein solcher Rootkit anrichten kann, muss man bewerten, welche Möglichkeiten zur Ausführung von eigenem Code in der UEFI BIOS-Umgebung bestehen. Zum Beispiel im privilegiertesten Modus des Prozessors – SMM. Ein solcher Rootkit kann folgende Eigenschaften haben:

• parallel zum Betriebssystem ausgeführt werden (man kann die Ausführung durch Generierung eines SMI-Interrupts konfigurieren, der durch einen Timer ausgelöst wird);
• alle Vorteile des SMM-Modus nutzen (voller Zugriff auf den Inhalt des Arbeitsspeichers und die Hardware-Ressourcen, Unsichtbarkeit für das Betriebssystem);
• Der Programmiercode 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 zugänglich sind. Zum Beispiel der Hash einer Adressensammlung im SMRAM. Um diesen Schlüssel zu erlangen, muss man in den SMM eindringen. Dies kann auf zwei Arten geschehen: Entweder findet man eine RCE im SMM-Code und exploitiert sie oder man fügt ein eigenes SMM-Modul ins BIOS ein, was jedoch nicht möglich ist, da wir Boot Guard aktiviert haben.

Somit ermöglicht diese Schwachstelle einem Angreifer:

• ein verborgenes, unlöschbares Rootkit unbekannten Zwecks im System zu erstellen;
• seinen Code auf einem der Kerne des Chipsatzes innerhalb des Intel SoC, nämlich auf dem Intel ISH, auszuführen (sehen wir uns das Bild genauer an).

Obwohl die Möglichkeiten des Intel ISH-Subsystems noch nicht gründlich untersucht wurden, stellt es einen interessanten Angriffsvektor auf Intel ME dar.

Fazit

1. Die Untersuchung ermöglichte es, eine technische Beschreibung der Funktionsweise der Technologie Intel Boot Guard zu erhalten. Ein Nachteil ist das Geheimhaltungsprinzip in Intels Modell der Sicherheit durch Unkenntnis.
2. Ein Angriffsszenario wurde vorgestellt, das es ermöglicht, ein unlöschbares Rootkit im System zu erstellen.
3. Wir haben festgestellt, dass moderne Intel-Prozessoren in der Lage sind, viele proprietäre Codes bereits vor dem Start des BIOS auszuführen.
4. Plattformen mit der Intel 64-Architektur werden zunehmend ungeeignet für die Ausführung von Open-Source-Software: Hardware-Verifikation, eine zunehmende Anzahl proprietärer Technologien und Subsystene (drei Kerne im SoC-Chipsatz: x86 ME, x86 ISH und ARC PMC).

Maßnahmen

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

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

Quelle: habr.com