Firmware & Supply-Chain-Angriffe

UEFI-Angriffe & Bootkits — unterhalb des Betriebssystems

Das Unified Extensible Firmware Interface (UEFI) hat das ältere BIOS als Firmware-Standard abgelöst und ist auf praktisch jedem modernen PC und Server vorhanden. UEFI ist im Kern ein Mini-Betriebssystem: Es hat eigene Treiber, einen Netzwerk-Stack, einen Dateisystem-Zugriff (auf die EFI System Partition) und kann ausführbaren Code laden — alles bevor Windows oder Linux startet. Genau diese Mächtigkeit macht UEFI zu einem attraktiven Angriffsziel. Ein UEFI-Rootkit (auch „Bootkit“) wird in die SPI-Flash-Firmware geschrieben und lädt sich bei jedem Start vor dem Betriebssystem. Da es vor dem OS aktiv ist, kann es sämtliche Sicherheitsmechanismen des Betriebssystems — Secure Boot, Kernel-Integritätsprüfungen, EDR-Agents — manipulieren oder umgehen.

Die Realität von UEFI-Malware in freier Wildbahn: LoJax (2018, APT28/Fancy Bear) war das erste dokumentierte UEFI-Rootkit in einer realen Cyber-Spionage-Operation. Es infizierte die SPI-Flash-Firmware von Lenovo-Laptops und überlebte sowohl Festplattenaustausch als auch Betriebssystem-Neuinstallation. MosaicRegressor (2020, wahrscheinlich chinesischer Ursprung) nutzte ein modifiziertes UEFI-Firmware-Modul, um bei jedem Start eine Backdoor ins Betriebssystem zu injizieren. CosmicStrand (2022, chinesischer Nexus) infizierte das UEFI-Firmware von ASUS- und Gigabyte-Mainboards und aktivierte eine Kernel-Level-Backdoor über die gesamte Boot-Kette hinweg. Diese Entdeckungen zeigen: UEFI-Angriffe sind keine theoretische Bedrohung mehr, sondern werden aktiv von staatlichen Akteuren eingesetzt.

• BMC/IPMI — der vergessene Computer im Computer: Jeder Server besitzt einen Baseboard Management Controller (BMC), erreichbar über IPMI (Intelligent Platform Management Interface, UDP Port 623). Der BMC ist ein eigenständiger Mikrocontroller mit eigenem Betriebssystem, Netzwerk-Stack und Webserver — er läuft auch wenn der Server ausgeschaltet ist. Über den BMC kann man: den Server remote ein-/ausschalten, auf die Konsole zugreifen (KVM over IP), virtuelle Medien einlegen, die UEFI-Firmware flashen. Standard-Credentials: Dell iDRAC (root/calvin), HP iLO (Administrator/8-stellig auf Label), Supermicro IPMI (ADMIN/ADMIN). In über 40 % der Rechenzentren sind BMC-Interfaces im gleichen Netzwerk wie die Produktionsserver — ohne Segmentierung.
• DMA-Angriffe über Thunderbolt/PCIe: Thunderbolt-Ports bieten Direct Memory Access (DMA) — ein angeschlossenes Gerät kann direkt auf den Arbeitsspeicher des Hosts zugreifen, ohne CPU-Vermittlung. Ein Angreifer mit physischem Zugang kann über ein modifiziertes Thunderbolt-Gerät (z. B. PCILeech) den gesamten RAM auslesen — inklusive Passwort-Hashes, Kerberos-Tickets und Verschlüsselungsschlüssel. Verteidigung: VBS (Virtualization-Based Security) und DMA Guard in Windows, IOMMU (Intel VT-d / AMD-Vi) im BIOS aktivieren.
• Evil Maid Attack — physischer UEFI-Angriff: Ein Angreifer mit kurzfristigem physischem Zugang (z. B. Hotelpersonal, Reinigungsdienst) bootet von einem USB-Stick und modifiziert die EFI System Partition: Er ersetzt den Windows Boot Manager durch eine manipulierte Version, die beim nächsten Start ein Keylogger-Modul lädt. Bitlocker mit TPM+PIN schützt dagegen: Ohne die PIN wird der Bitlocker-Schlüssel nicht freigegeben, und die manipulierte EFI-Binary bricht die PCR-Messungen des TPM.
• SPI-Flash-Write-Schutz: Die meisten Mainboards bieten einen Hardware-Write-Schutz für den SPI-Flash-Chip (BIOS Write Protect / BIOS Lock). Dieser muss im UEFI-Setup explizit aktiviert werden — standardmäßig ist er oft deaktiviert. Zusätzlich: Intel Boot Guard (hardwareseitig in der CPU verankert) verifiziert die Firmware-Signatur bei jedem Start — ein modifiziertes UEFI-Image wird abgelehnt, bevor es ausgeführt werden kann.

Supply-Chain-Angriffe — wenn vertrauenswürdige Software zum Trojaner wird

Supply-Chain-Angriffe kompromittieren nicht das Ziel direkt, sondern einen vertrauenswürdigen Lieferanten — und nutzen dessen Update-Mechanismus, um Malware an alle Kunden zu verteilen. Der SolarWinds-Angriff (2020, APT29/Cozy Bear) ist das Paradebeispiel: Die Angreifer kompromittierten den Build-Server von SolarWinds und fügten eine Backdoor (SUNBURST) in das Orion-Update ein. Über 18.000 Organisationen — darunter US-Regierungsbehörden, Microsoft und FireEye — installierten das kompromittierte Update. Die Backdoor kommunizierte über DNS (C2-Domänen als CNAME-Subdomains von avsvmcloud.com) und wartete 2 Wochen nach Installation, bevor sie aktiv wurde — um Sandbox-Analysen zu umgehen.

Der Kaseya-Angriff (2021, REvil) nutzte eine Zero-Day-Schwachstelle im Kaseya VSA Remote-Management-Tool, um Ransomware über den automatischen Software-Verteilungsmechanismus an über 1.500 Unternehmen gleichzeitig zu verteilen. Der 3CX-Angriff (2023, Lazarus Group) kompromittierte den Desktop-Client des VoIP-Anbieters 3CX — die kompromittierte Version wurde über den offiziellen Auto-Update-Mechanismus an 600.000 Kunden verteilt und war mit einem gültigen Code-Signing-Zertifikat signiert. Die Besonderheit: Es war ein cascading Supply-Chain-Angriff — die Angreifer hatten zuvor einen anderen Softwarehersteller (Trading Technologies) kompromittiert und über dessen Software einen 3CX-Entwickler infiziert.

• Dependency Confusion: Entwickler verwenden Paketmanager (npm, PyPI, NuGet) mit internen (privaten) und externen (öffentlichen) Paketquellen. Ein Angreifer registriert ein öffentliches Paket mit dem gleichen Namen wie ein internes Paket, aber einer höheren Versionsnummer. Viele Paketmanager bevorzugen die höhere Version aus der öffentlichen Quelle — das bösartige Paket wird installiert. Der Sicherheitsforscher Alex Birsan demonstrierte dies 2021 und erlangte Code-Execution bei Apple, Microsoft und PayPal.
• Typosquatting in Paketregistries: Angreifer registrieren Pakete mit ähnlichen Namen: python-requests statt requests, lodash-utils statt lodash. Das bösartige Paket enthält den gleichen Code wie das Original, plus eine Backdoor im setup.py (Python) oder postinstall-Skript (npm). Auf PyPI wurden 2023 über 400 solcher Pakete identifiziert, die Credentials stahlen. Verteidigung: Lockfiles mit Integrity-Hashes (package-lock.json, Pipfile.lock), Sigstore/Cosign für Paket-Signaturverifikation.
• Hardware-Supply-Chain: Der Bloomberg-Bericht über Supermicro (2018) behauptete, dass chinesische Nachrichtendienste winzige Chips auf Supermicro-Mainboards löteten, die Backdoor-Zugang ermöglichten — Apple und Amazon dementierten. Unabhängig von der Verifizierung dieses spezifischen Falls: Hardware-Implantate sind ein reales Risiko für Hochsicherheitsumgebungen. Gegenmaßnahme: Trusted Platform Module (TPM)-basierte Attestierung der Hardware-Integrität und Measured Boot (jede Komponente in der Boot-Kette wird gemessen und gegen bekannte Werte geprüft).
• CI/CD-Pipeline-Angriffe: Build-Server sind High-Value-Targets: Wer den Build-Prozess kontrolliert, kontrolliert das Produkt. Angriffsvektoren: Kompromittierte GitHub Actions / GitLab Runners, manipulierte Dockerfiles, gefälschte Build-Dependencies, Secrets in CI/CD-Variablen. Verteidigung: SLSA (Supply-chain Levels for Software Artifacts) — ein Framework von Google, das Build-Integrity von Level 1 (Dokumentation) bis Level 4 (hermetische, reproduzierbare Builds mit Hardware-Attestierung) definiert.

Verteidigung & Firmware-Sicherheit — die unterste Schicht schützen

Der Schutz gegen Firmware-Angriffe beginnt mit Secure Boot — dem Mechanismus, der sicherstellt, dass nur signierte Firmware und Bootloader ausgeführt werden. Secure Boot verwendet eine Zertifikatskette: Die Platform Key (PK) des Mainboard-Herstellers signiert die Key Exchange Keys (KEK), die wiederum die Datenbank (db) der erlaubten Signaturen und die Revocation Database (dbx) der gesperrten Signaturen autorisieren. In der Praxis sind die meisten Systeme mit Microsoft-Zertifikaten in der db konfiguriert, was sicherstellt, dass Windows-Bootloader akzeptiert werden. Für Linux: Shim (signiert von Microsoft) lädt GRUB2 (signiert von der Distribution), das den Linux-Kernel lädt — eine dreistufige Vertrauenskette.

• Firmware-Integritätsprüfung: CHIPSEC (Intel, Open Source) prüft die Firmware-Konfiguration auf bekannte Schwachstellen: SPI-Flash-Write-Schutz, SMRAM-Schutz, Secure-Boot-Status, BIOS-Lock. python chipsec_main.py -m common.bios_wp prüft den BIOS-Write-Schutz. python chipsec_main.py -m common.secureboot.variables prüft die Secure-Boot-Konfiguration. Jeder fehlgeschlagene Test ist eine potenzielle Angriffsoberfläche für Firmware-Malware.
• UEFI-Firmware-Updates automatisieren: Firmware-Updates werden häufig vernachlässigt — viele Server laufen jahrelang mit veralteter Firmware. LVFS (Linux Vendor Firmware Service) bietet automatische Firmware-Updates für über 800 Geräte (Dell, Lenovo, HP, Intel). Für Windows: Windows Update for Business kann Firmware-Updates über UEFI Capsule Update verteilen. Dell bietet Dell Command Update für automatisierte BIOS-Updates über SCCM/Intune.
• BMC/IPMI isolieren: BMC-Interfaces müssen in einem dedizierten Management-VLAN liegen, getrennt vom Produktionsnetzwerk. Zugang nur über Jump-Server mit MFA. Standard-Credentials sofort ändern. IPMI-über-LAN deaktivieren, wenn nicht benötigt (nur seriell oder über dediziertes Management-Interface). Firmware des BMC regelmäßig aktualisieren — BMC-Schwachstellen (z. B. CVE-2019-6260 „Pantsdown“) ermöglichen Remote Code Execution mit SYSTEM-Rechten auf dem BMC.
• Software Bill of Materials (SBOM): Ein SBOM listet alle Komponenten und Abhängigkeiten einer Software auf — inklusive Bibliotheken, Frameworks und deren Versionen. US Executive Order 14028 (2021) verpflichtet Lieferanten der US-Regierung zur Bereitstellung eines SBOM. Formate: SPDX (Linux Foundation) und CycloneDX (OWASP). Tools: Syft (generiert SBOM aus Container-Images), Grype (scannt SBOM gegen CVE-Datenbanken). Fordern Sie SBOMs von Ihren Softwarelieferanten ein — bei einem Supply-Chain-Vorfall wissen Sie sofort, ob Sie betroffen sind.