zurück zum Artikel

Der Hacker Cr4sh erklärt, wie er eine Hintertür in die UEFI-Firmware eines Intel-Mainboards einbaut. Dabei zeigen sich einmal mehr kritische Lücken in der x86-Plattform, vor allem beim System Management Mode.

Wieder einmal öffnet der System Management Mode (SMM) aus der PC-Frühzeit eine Sicherheitslücke, mit der böswillige Angreifer und Lauscher eine gut getarnte Hintertür in x86-Computer einbauen können. Der Hacker Cr4sh alias Dmytro Oleksiuk erläutert in einem langen Blog-Eintrag [1], wie er ins UEFI-BIOS des Intel-Mainboards DQ77KB eine Backdoor implantiert. Die wesentlichen Teile des Codes stellt er gleich noch bei GitHub bereit [2].

Ein unmittelbares Risiko für Angriffe mit dem Code besteht nicht, wie Cr4sh selbst erklärt. So benutzt er einen Hardware-Adapter, um den manipulierten UEFI-Code in den Flash-Chip des Mainboards zu schreiben. Für Angriffe aus dem Netz müsste man andere Sicherheitslücken [3] nutzen, um den UEFI-Code einzuschleusen.

Außerdem ist der Schad-Code, den Cr4sh geschrieben hat, systemspezifisch: Außer auf dem Intel DQ77KB würde er auf anderen Systemen nur funktionieren, wenn deren Firmware den APIC-Timer auf gleiche Weise ansteuert.

System Management Mode

Cr4sh beschreibt sehr gut, weshalb der nach heutigen Maßstäben schlecht gegen Angriffe gesicherte SMM [4] Hacker geradezu einlädt: Diesen Betriebsmodus von x86-Prozessoren kann man sich ähnlich wie eine Virtuelle Maschine (VM) vorstellen, die parallel zum Betriebssystem läuft. Schlimmer noch: Der SMM ist nicht nur für das Betriebssystem und darin laufende Virenscanner unsichtbar, sondern arbeitet auch noch mit den allerhöchsten Zugriffsrechten. Darin ist der SMM einem Hypervisor vergleichbar – bloß, dass ein System Management Interrrupt (SMI), der den Prozessor in den SMM schaltet, noch höhere Priorität besitzt als ein Non-Maskable Interrupt (NMI).

Und während AMD und Intel den Hypervisor immer stärker gegen Angriffe abschotten, etwa mit zusätzlichen Sicherheitsfunktionen in VT-x und kryptografischen Schutzmaßnahmen bis hin zur Verankerung von Schlüsseln im TPM, gab es beim SMM kaum Fortschritte in Bezug auf höhere Sicherheit. Erst für die Haswell-Plattform hat Intel SMM External Call Trap (SECT) eingeführt: Wenn das BIOS SECT aktiviert, kann ein SMI Handler keinen Code mehr im User Memory aufrufen.

SMM läuft immer mit

Für den SMM reserviert die Firmware einen kleinen Teil des physischen RAM, der für das Betriebssystem unsichtbar ist. Im SMRAM läuft vor allem Code, der im (UEFI-)BIOS enthalten ist und den das System für die Konfiguration und die Systemverwaltung benötigt. Dazu gehören auch ACPI-Funktionen wie die Energieverwaltung, also das Umschalten verschiedener P-States – letztlich Taktfrequenzen und Kernspannungen – der CPU und auch der C-States, also der CPU-Schlafmodi.

Wenn aber beispielsweise außer dem Schreibprogramm keine weitere Software CPU-Leistung fordert, schlafen moderne Prozessoren sogar zwischen zwei Tastaturanschlägen kurzzeitig ein, wechseln also den C-State. Dabei schaltet die CPU stets kurz in den SMM – also mehrere Dutzend Mal pro Sekunde. Tatsächlich verbringen moderne Rechner einen durchaus erheblichen Teil ihrer Betriebszeit im SMM, wie Forscher der Uni Portland erläutern.

Attacke!

Die wesentliche Idee des Cr4sh-Hacks ist die Kommunikation zwischen Schad-Code, der unter dem normalen Betriebssystem läuft, und Code, den die CPU im SMM ausführt. So lässt sich die unsichtbar im SMM verankerte Hintertür nutzen, um Informationen abzuzapfen. Als Proof-of-Concept hat Cr4sh Code geschrieben, der vom Betriebssystem aus den SMM ansteuert, um Daten über den RS-232-(COM-)Port auszugeben.

UEFI-Treiber

Zuerst hat Cr4sh einen ohnehin vorhandenen UEFI-Treiber manipuliert, also ihm zusätzliche Funktionen eingepflanzt. Dabei hat er einen Treiber ausgewählt, der sowohl in der Phase der Plattform-Initialisierung durch das UEFI-BIOS läuft, also im Driver Execution Environment (DXE), als auch im System Management Mode. Diesen kombinierten DXE/SMM-Treiber hat er aus der Firmware des Intel DQ77KB extrahiert, erweitert und wieder in die Firmware verpackt. Dann hat er die manipulierte Firmware mit einem USB-SPI-Programmiergerät in den Flash-Chip geschrieben.

APIC-Timer

Auf der Seite des Betriebssystems hat Cr4sh zunächst versucht, die Daten mit sogennanten SMI-Handlers abzusetzen. Dazu sind aber Administrator-Rechte im Betriebssystem nötig. Doch dann kam er auf die Idee, manipulierte Aufrufe des APIC-Timers zu verwenden: Das klappt auch ohne erhöhte Rechte. Schließlich erklärt Cr4sh, wie man über diese Aufrufe die Backdoor nutzen kann, um eine Shell aufzurufen.

Links zum Thema:

• Cr4sh: Building reliable SMM backdoor for UEFI based platforms [5]
• SMM in Kapitel 2.4.8.2 des BIOS and Kernel Developer’s Guide für AMD Kabini [6] (PDF)
• How an I/O port leads to System Management Mode [7]
• System Management Mode (SMM) external call trap (SECT) [8]
• Performance Implications of SMM (Uni Portland) [9] (PDF)
• EFI Driver Execution Environment Core Interface Spec v0.9 [10]

(ciw [11])

URL dieses Artikels:
https://www.heise.de/-2748219

Links in diesem Artikel:
[1] http://blog.cr4.sh/2015/07/building-reliable-smm-backdoor-for-uefi.html
[2] https://github.com/Cr4sh/SmmBackdoor
[3] https://www.heise.de/news/BIOS-Rootkit-LightEater-In-den-dunklen-Ecken-abseits-des-Betriebssystems-2582782.html
[4] https://www.heise.de/news/US-Cert-warnt-vor-weiteren-UEFI-BIOS-Luecken-2512913.html
[5] http://blog.cr4.sh/2015/07/building-reliable-smm-backdoor-for-uefi.html
[6] http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/48751_BKDG_Fam_16h_Mod_00h-0Fh.pdf
[7] http://dreamlayers.blogspot.de/2012/10/how-io-port-leads-to-system-management.html
[8] https://software.intel.com/en-us/articles/intel-xeon-processor-e5-2600-v3-product-family-technical-overview#_Toc398042549
[9] http://web.cecs.pdx.edu/~karavan/research/SMM_IISWC_preprint.pdf
[10] http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-dxe-cis-v09.html
[11] mailto:ciw@ct.de

Copyright © 2015 Heise Medien