Auditieren von UEFI-Firmware mit CHIPSEC

Was macht Auditieren von UEFI-Firmware mit CHIPSEC?

Nur für autorisierte Nutzung: CHIPSEC lädt einen Kernel-Treiber und liest/schreibt Low-Level-Hardware-Register, SPI-Flash und SMM. Führen Sie es nur auf Systemen aus, die Ihnen gehören oder für die Sie ausdrücklich zur Bewertung autorisiert sind, idealerweise auf dedizierter Testhardware. Fehlgebrauch (insbesondere von Write-/Modify-Modulen) kann ein System unbrauchbar machen. Führen Sie niemals schreibfähige Module auf Produktionssystemen aus.

Überblick

CHIPSEC ist das quelloffene Plattform-Sicherheitsbewertungs-Framework, das von Intels Advanced Threat Research Team entwickelt wurde. Es inspiziert die Low-Level-Sicherheitskonfiguration von x86-Plattform-Firmware und -Hardware – die Schicht unterhalb des Betriebssystems, in der Bootkits und Firmware-Implantate lauern. CHIPSEC lädt einen signierten Kernel-Treiber (Linux, Windows oder vom UEFI-Shell) zum Lesen und Schreiben von Hardware-Registern, modellspezifischen Registern (MSRs), PCI-Konfigurationsbereich, SPI-Flash und UEFI-Variablen. Anschließend führt es eine automatisierte Testsuite aus, die prüft, ob die defensiven Sperren der Plattform tatsächlich aktiviert sind.

Die Bedrohung, die CHIPSEC adressiert, ist MITRE ATT&CK T1542.001 — Pre-OS Boot: System Firmware: Angreifer modifizieren Systemfirmware (das BIOS/UEFI-Image im SPI-Flash), um eine heimliche, persistente, OS-überlebensfähige Kontrolle zu erlangen. Firmware-Implantate überstehen eine Betriebssystem-Neuinstallation und Festplattenaustausch und sind für die meisten EDR-Lösungen unsichtbar. Der Wert von CHIPSEC liegt darin, die Voraussetzungen zu verifizieren, die solche Implantate verhindern: dass der SPI-Flash-BIOS-Bereich schreibgeschützt ist (BIOS_CNTL BLE/SMM_BWP, SPI Protected Ranges), dass die Flash-Deskriptorsperre den Bereichszugriff beschränkt, dass SMRAM/SMRR konfiguriert sind und dass Secure-Boot-Variablen geschützt sind. Es dumpet zudem den SPI-Flash für offline forensische Vergleiche.

Quellen: Intel/CHIPSEC-Projekt (https://github.com/chipsec/chipsec), CHIPSEC-Dokumentation (https://chipsec.github.io/).

Wann zu verwenden

• Basis-Firmware-Sicherheitsbewertung einer neuen Laptop-/Server-Plattform oder eines Fleet-Images
• Verifizierung, dass der BIOS-Schreibschutz und die SPI-Flash-Sperren ordnungsgemäß vom OEM aktiviert wurden
• Firmware-Forensik: Dumping von SPI-Flash zum Vergleich mit einem bekannten, guten Image
• Validierung des Secure-Boot-Variablen-Schutzes und des S3-Bootscript-Schutzes
• Suche nach Anzeichen eines Firmware-Implantats oder einer Fehlkonfiguration, die dies ermöglicht

Voraussetzungen

• Physischer oder Admin-/Root-Zugriff auf die Ziel-x86-Plattform (Intel oder AMD)
• Linux (root) oder Windows (Administrator) oder eine UEFI-Shell-Umgebung
• Fähigkeit, einen Kernel-Treiber zu laden (Secure Boot muss möglicherweise den CHIPSEC-Treiber zulassen, oder verwenden Sie --no_driver für eingeschränkte Prüfungen)
• Python 3.8+ und ein C-Compiler/Build-Tools für das Kernel-Modul auf Linux
• Dedizierte Testhardware wird dringend empfohlen

Installation von CHIPSEC:

# Von PyPI
pip install chipsec

# Oder aus dem Quellcode (erstellt den Kernel-Helper/Treiber)
git clone https://github.com/chipsec/chipsec
cd chipsec
python setup.py install        # erstellt und installiert, einschließlich des Linux-Treibers

# Überprüfung
sudo chipsec_main --help
sudo chipsec_util --help

Ziele

• Die vollständige automatisierte Plattform-Sicherheitstestsuite ausführen und die Ergebnisse von PASS/FAIL/WARNING interpretieren
• BIOS-Schreibschutz (BIOS_CNTL) und SPI Protected Ranges verifizieren
• Die SPI-Flash-Deskriptorsperre für Lese-/Schreibzugriffe verifizieren
• SMRAM/SMRR und SMI-Handler-Schutz verifizieren
• Secure-Boot-Variablen-Schutz und S3-Bootscript-Schutz verifizieren
• SPI-Flash dumpen und für die Offline-Analyse dekodieren
• UEFI-Variablen auflisten und anomale/unerwartete Einträge erkennen

MITRE ATT&CK Abbildung

Technik-ID	Name	Taktik
T1542.001	Pre-OS Boot: System Firmware	Persistence / Defense Evasion

CHIPSEC verteidigt gegen T1542.001, indem es überprüft, dass die Kontrollen, die unbefugte Firmware-Änderungen verhindern, aktiviert sind. Ein FAIL bei common.bios_wp (BIOS nicht schreibgeschützt) oder chipsec.modules.common.spi_lock (Flash-Deskriptor nicht gesperrt) bedeutet, dass ein Angreifer mit OS-Berechtigungen den SPI-Flash neu schreiben und persistente Firmware implantieren könnte – genau die Vorbedingung für diese Technik.

Arbeitsablauf

Schritt 1: Die vollständige automatisierte Testsuite ausführen

chipsec_main ohne Modulargument führt alle anwendbaren Sicherheitsprüfungen für die erkannte Plattform aus und gibt eine Zusammenfassung der Ergebnisse PASS/FAIL/WARNING/INFORMATION aus.

sudo chipsec_main

# Maschinenlesbare Ausgabe für Berichte/Diffs speichern
sudo chipsec_main -j results.json -x results.xml -l chipsec.log

Schritt 2: Die Kern-Firmware-Schutzmodule einzeln ausführen

Die common-Modulgruppe enthält die OEM-unabhängigen Sicherheitsprüfungen. Führen Sie die gesamte Gruppe oder bestimmte Module aus:

# Die gesamte common-Gruppe ausführen
sudo chipsec_main -m common

# BIOS-Schreibschutz: prüft BIOS_CNTL BLE/SMM_BWP und SPI Protected Ranges
sudo chipsec_main -m common.bios_wp

# SPI-Flash-Deskriptorsperre (FLOCKDN) — sind Flash-Bereichszugriffe gesperrt?
sudo chipsec_main -m common.spi_lock

# SMRR-Programmierung — schützt SMRAM vor cachebasierten Angriffen
sudo chipsec_main -m common.smrr

# SMM-BIOS-Schreibschutz
sudo chipsec_main -m common.smm

# S3-Rückkehr-Bootscript-Schutz (gegen Bootscript-Tabellen-Angriffe)
sudo chipsec_main -m common.uefi.s3bootscript

Schritt 3: Secure-Boot-Variablen-Schutz verifizieren

# Prüft, ob die Secure-Boot-UEFI-Variablen ordnungsgemäß geschützt sind
sudo chipsec_main -m common.secureboot.variables

# Für einen aktiven Test des Schreibschutzes der Variablen (NUR Testhardware):
sudo chipsec_main -m common.secureboot.variables -a modify

Schritt 4: SPI-Flash-Bereichszugriffsberechtigungen inspizieren

# SPI-Flash-Regionen, Deskriptor und Zugriffsberechtigungen melden
sudo chipsec_util spi info

# Das SPI-Zugriffskontrollmodul prüfen
sudo chipsec_main -m common.spi_access

Schritt 5: SPI-Flash für Offline-Forensik dumpen

Das Dumping des Flashs ermöglicht das Dekodieren der Firmware-Volumes und den Vergleich mit einem bekannten OEM-Image.

# Den gesamten SPI-Flash in eine Datei dumpen
sudo chipsec_util spi dump rom.bin

# Das gedumpte Image dekodieren: extrahiert Firmware-Volumes, Dateien, NVRAM-Variablen usw.
sudo chipsec_util decode rom.bin

Schritt 6: UEFI-Variablen auflisten und bewerten

# Alle UEFI-Variablen von der Runtime-Schnittstelle auflisten
sudo chipsec_util uefi var-list

# Variablen direkt aus dem SPI-Image auflisten (offline)
sudo chipsec_util uefi var-find PK
sudo chipsec_util uefi var-read db <GUID> db.bin

# Die UEFI-Firmware-Struktur dekodieren
sudo chipsec_util uefi decode rom.bin

Schritt 7: Eingeschränkte Bewertung ohne Kernel-Treiber

Wenn das Laden des Treibers unmöglich ist (eingeschränktes Secure Boot), laufen einige Prüfungen dennoch schreibgeschützt.

sudo chipsec_main -n            # --no_driver: überspringt Prüfungen, die den Treiber benötigen
sudo chipsec_main -p <PLATFORM> # Plattformcode erzwingen, falls automatische Erkennung fehlschlägt

Schritt 8: Ergebnisse bewerten und berichten

• FAIL auf bios_wp / spi_lock → Firmware ist aus dem OS überschreibbar: hohes Risiko für T1542.001.
• FAIL auf secureboot.variables → Secure Boot-Richtlinie kann manipuliert werden.
• Vergleichen Sie den spi dump mit dem bekannten OEM-Image (hashen Sie Firmware-Volumes), um unbefugte Änderungen zu erkennen.
• Notieren Sie Plattform, BIOS-Version und jede FAIL/WARNING mit den relevanten Registerwerten für den Bericht.

Werkzeuge und Ressourcen

Werkzeug	Zweck	Quelle
chipsec_main	Automatisierte Plattform-Sicherheitstestsuite	https://github.com/chipsec/chipsec
chipsec_util	Manueller Hardware-/Firmware-Zugriff (spi, uefi, decode)	https://chipsec.github.io/
UEFITool	GUI/CLI-Parsing von gedumpten UEFI-Images	https://github.com/LongSoft/UEFITool
Binarly fwhunt	Firmware-Schwachstellen-/Implantat-Suchregeln	https://github.com/binarly-io/fwhunt-scan
NSA UEFI Secure Boot-Anleitung	Härtungsreferenz	https://media.defense.gov/

Kernmodul-Referenz

Modul	Prüfungen
common.bios_wp	BIOS_CNTL BLE / SMM_BWP und SPI Protected Ranges
common.spi_lock	SPI-Flash-Deskriptor FLOCKDN
common.spi_access	SPI-Flash-Bereichs-Lese-/Schreibberechtigungen
common.smrr	System Management Range Registers Programmierung
common.smm	SMM-BIOS-Schreibschutz
common.secureboot.variables	Secure-Boot-Variablen-Schutz
common.uefi.s3bootscript	S3-Rückkehr-Bootscript-Schutz

Validierungskriterien

• CHIPSEC installiert und Treiber geladen (oder -n dokumentiert, falls nicht)
• Vollständige chipsec_main-Suite ausgeführt mit gespeicherter JSON/XML/Log-Ausgabe
• common.bios_wp-Ergebnis interpretiert (Schreibschutz-Status)
• common.spi_lock / spi_access-Ergebnis interpretiert (Deskriptorsperre)
• SMRR/SMM-Modulergebnisse aufgezeichnet
• Secure-Boot-Variablen-Schutz geprüft
• SPI-Flash gedumpt und für Offline-Analyse dekodiert
• UEFI-Variablen aufgelistet und bewertet
• Alle FAIL/WARNING-Befunde mit Plattform-/BIOS-Version dokumentiert
• Write-/Modify-Module NICHT auf Produktionshardware ausgeführt