Secure Boot - UEFI-Bootprozess-Absicherung gegen Bootkits
Secure Boot ist ein UEFI-Firmware-Standard der sicherstellt dass nur kryptografisch signierte Bootloader und Betriebssystem-Kernel geladen werden dürfen. Schützt gegen Bootkits und rootkits die vor dem Betriebssystem starten. Aktiviert via UEFI-Einstellungen, konfigurierbar mit eigenen Keys (Custom Secure Boot). Unterstützt von Windows 10/11, Linux (shim, GRUB), macOS (Apple T2/M1). Ergänzt durch Measured Boot und TPM 2.0.
Secure Boot ist ein Sicherheitsstandard der in der UEFI-Firmware (Unified Extensible Firmware Interface) implementiert ist und sicherstellt, dass ein Computer nur Software lädt die vom Hersteller digital signiert und als vertrauenswürdig eingestuft wurde. Ohne Secure Boot kann Schadsoftware vor dem Betriebssystem starten - unsichtbar für Antivirus-Software.
Das Bootkit-Problem
Normaler Boot-Prozess
- UEFI/BIOS startet
- Bootloader (GRUB, Windows Boot Manager) wird geladen
- OS-Kernel wird geladen
- Betriebssystem startet
- Antivirus, Security-Tools starten
Problem: Antivirus startet nach dem Bootloader! Malware die im Bootloader installiert ist, startet vor dem AV - und ist für diesen unsichtbar.
Bekannte Bootkit-Angriffe
BlackLotus (2023): UEFI-Bootkit für Windows
- Läuft im Ring 0 vor dem Windows-Kernel
- Kann Secure Boot bypassen! (ungepatchte PCs)
- Für AV unsichtbar
- Deaktiviert: Defender, BitLocker, Kernel-Patch-Protection
Weitere Beispiele:
- FinSpy UEFI-Implantat (APT, staatliche Angreifer)
- MosaicRegressor (APT41, in UEFI-Flash eingebettet!)
- TrickBot “TrickBoot”: UEFI-Manipulation via Admin-Zugriff
Folgen eines UEFI-Bootkits:
- Persistenz über Festplattenwechsel und Windows-Neuinstallation!
- Vollständige Kontrolle über System vor jedem Sicherheitsmechanismus
- Entdeckung extrem schwierig (kein normales Dateisystem-Tool findet es)
Secure-Boot-Funktionsprinzip
UEFI-Key-Struktur
| Key | Bedeutung | Inhaber |
|---|---|---|
| PK (Platform Key) | Vertrauensanker | Hardware-Hersteller (ASUS, Dell, Lenovo etc.) |
| KEK (Key Exchange Key) | Zwischenzertifikat | Microsoft, Linux Foundation etc. |
| db (Signature Database) | Erlaubte Signaturen | Bootloader |
| dbx (Forbidden Database) | Verbotene/revozierte Signaturen | - |
Vertrauenskette: PK → KEK → db → Bootloader-Signatur → Kernel-Signatur
Boot-Prozess mit Secure Boot
- UEFI prüft: Hat Bootloader eine gültige Signatur?
- Signatur in
db(Signature Database)? → weiter - Signatur in
dbx(revoziert)? → STOP - Kein Zertifikat? → STOP
- Signatur in
- Bootloader geladen (z.B. Windows Boot Manager)
- Bootloader prüft: Hat OS-Kernel gültige Signatur?
- Kernel geladen → System bootet
Manipulierter Bootloader = keine gültige Signatur = STOP.
Unterstützte Betriebssysteme
| OS | Unterstützung |
|---|---|
| Windows 10/11 | Nativ (Microsoft-Zertifikat) |
| Linux | Über shim (Pre-Bootloader mit Microsoft-Zertifikat); shim lädt GRUB, GRUB lädt Linux-Kernel |
| macOS (Intel) | Nicht Secure Boot im UEFI-Sinne |
| macOS (Apple Silicon) | Eigenes Boot-Security-Konzept (Secure Enclave) |
| Android | Eigene Verified-Boot-Implementierung |
Konfiguration und Custom Secure Boot
UEFI-Einstellungen:
→ PC neu starten → UEFI/BIOS-Taste (F2, F12, DEL, ESC)
→ "Security" → "Secure Boot"
→ Status: Enabled / Disabled / User Mode / Setup Mode
Setup Mode: eigene Keys können installiert werden
User Mode: Standard-Keys aktiv, keine Änderungen ohne PK-Signatur# Secure Boot Status prüfen - Windows:
msinfo32 # → "Secure Boot State": Yes/No/Unsupported
# PowerShell:
Confirm-SecureBootUEFI
# True = Secure Boot aktiv und validiert# Secure Boot Status prüfen - Linux:
mokutil --sb-state
# "SecureBoot enabled" oder "SecureBoot disabled"
# Bootcurrent und Secure Boot:
efivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot
# 01 = aktiviert, 00 = deaktiviert# Custom Secure Boot (Eigene Keys, für Enterprise):
# Szenario: Eigene Linux-Distribution oder Custom-Bootloader
# Eigenen Key erstellen:
openssl req -new -x509 -newkey rsa:4096 \
-keyout MOK.key -out MOK.crt \
-days 3650 -subj "/CN=My Secure Boot Key"
# Key in DER-Format:
openssl x509 -in MOK.crt -outform DER -out MOK.der
# Key im MOK-Manager registrieren (Linux):
mokutil --import MOK.der
# → Neustart → MOK-Manager → Key bestätigen
# Eigenen Kernel signieren:
sbsign --key MOK.key --cert MOK.crt \
--output /boot/vmlinuz-signed /boot/vmlinuz# Secure Boot in Unternehmens-GPO (Windows):
# Nur UEFI-Klasse erlaubt (kein Legacy BIOS):
Computer Config → Admin Templates → Windows Components → BitLocker
→ "Allow Secure Boot for integrity validation": Enabled
# AUCH: Credential Guard benötigt Secure Boot!BlackLotus und Secure Boot Bypasses
BlackLotus: Secure Boot Bypass (2023)
CVE-2022-21894 (Boot Manager):
- Ausgenutzt von BlackLotus
- Boot Manager vor Patch: bestimmte UEFI-Bootloader werden geladen obwohl sie Schwachstellen haben
- Exploit: Signierten, aber vulnerablen Bootloader starten → von dort Secure Boot deaktivieren
Schutz:
- dbx-Update: Schwachstellen-Bootloader in Revokationsliste
- Windows Update KB5025885 (Mai 2023): CRITICAL!
- UEFI-Firmware-Update des PC-Herstellers
- Measured Boot + TPM: auch nach Boot-Manipulation erkennbar
BootHole (CVE-2020-10713, GRUB2)
Buffer Overflow in GRUB2’s Parsing von grub.cfg - erlaubt Secure Boot zu umgehen. Alle Linux-Distributionen mit GRUB2 betroffen. Fix: shim- und GRUB2-Update + dbx-Revokation.
Generelle Angriffsvektoren gegen Secure Boot
- UEFI-Firmware selbst angreifen (wenn Admin-Zugriff vorhanden)
- Vuln in Bootloader-Signatur-Prüfung
- Veraltete, signierte Bootloader wiederverwenden (Rollback)
- Physischer Angriff: CMOS-Reset, UEFI-Flash via SPI
Defense-in-Depth
Secure Boot + TPM 2.0 + Measured Boot + Attestation:
- Measured Boot: TPM-PCR-Register enthalten Hash des Boot-Prozesses
- Attestation: Cloud/MDM kann feststellen ob Boot-Prozess unverändert war
- Conditional Access: Unsicherer Boot-Zustand → kein Netzwerkzugang!
TPM-Integration und Measured Boot
TPM 2.0 (Trusted Platform Module)
Hardware-Sicherheitsmodul auf Mainboard - speichert Hashes des Boot-Prozesses in PCR-Registern (Platform Config Registers).
Measured Boot - UEFI misst (hasht) jeden Schritt:
| PCR-Register | Inhalt |
|---|---|
| PCR0 | BIOS/UEFI-Code |
| PCR4 | Bootloader (MBR, EFI-App) |
| PCR5 | Bootloader-Konfiguration |
| PCR7 | Secure Boot-Status |
| PCR11 | Windows Boot Manager |
Jeder Schritt erzeugt einen Hash im PCR. Änderungen sind messbar. BitLocker nutzt PCR-Werte: Boot-Tamper → BitLocker-Key gesperrt!
Remote Attestation
TPM kann kryptografisch beweisen dass der Boot-Prozess unverändert war.
Conditional Access (Microsoft Intune, Azure AD): “Gerät mit nicht-konformem Boot-Prozess → kein Unternehmens-Zugriff!”
Windows Device Health Attestation:
- Gerät meldet TPM-PCR-Werte an Azure
- Azure verifiziert: Secure Boot aktiv? Keine bekannte Malware im Boot?
- Conditional Access Policy: “Nur konforme Geräte → Zugriff auf O365”
