ESET-Forscher haben eine Schwachstelle entdeckt, die die Umgehung von UEFI Secure Boot ermöglicht. Betroffen ist ein Großteil UEFI-basierter Systeme. Die Sicherheitslücke (CVE-2024-7344) wurde in einer UEFI-Anwendung gefunden, die von einem Microsofts UEFI-Zertifikat für Drittanbieter, Microsoft Corporation UEFI CA 2011, signiert wurde. Gelingt es potenziellen Angreifern, diese Lücke auszunutzen, können sie schadhaften Code während des Systemstarts ausführen. Dies erlaubt es ihnen, bösartige UEFI-Bootkits (wie z. B. Bootkitty oder BlackLotus) selbst auf Systemen mit aktiviertem UEFI Secure Boot zu installieren, unabhängig vom installierten Betriebssystem.

Die betroffene UEFI-Anwendung kommt in mehreren Software-Produkten zur Echtzeit-Systemwiederherstellung von Computern vor:

  • Howyar SysReturn vor Version 10.2.023_20240919
  • Greenware GreenGuard vor Version 10.2.023-20240927
  • Radix SmartRecovery vor Version 11.2.023-20240927
  • Sanfong EZ-back System vor Version 10.3.024-20241127
  • WASAY eRecoveryRX vor Version 8.4.022-20241127
  • CES NeoImpact vor Version 10.1.024-20241127
  • SignalComputer HDD King vor Version 10.3.021-20241127

Zu der Sicherheitslücke kommt es, indem diese Anwendungen auf einen individuellen PE-Lader zurückgreifen, anstatt die standardmäßigen und sicheren UEFI-Funktionen LoadImage und StartImage zu verwenden. Die Folge: Die Anwendung erlaubt das Laden einer beliebigen UEFI-Binärdatei - sogar einer unsignierten - aus einer speziell erstellten Datei namens cloak.dat während des Systemstarts, unabhängig vom UEFI Secure Boot-Status.

ESET meldete diese Ergebnisse im Juni 2024 an das CERT Coordination Center (CERT/CC), das sich erfolgreich mit den betroffenen Herstellern in Verbindung setzte. Das Problem ist inzwischen behoben. Microsoft hat die alten, anfälligen Dateien mit dem Patch Tuesday Update vom 14. Januar 2025 zurückgezogen.

Die wichtigsten Punkte dieses Blogposts:
  • ESET-Forscher entdeckten eine neue Schwachstelle (CVE-2024-7344), die die Umgehung von UEFI Secure Boot auf den meisten UEFI-basierten Systemen ermöglicht.
  • Die Ausnutzung dieser Schwachstelle ermöglicht die Ausführung von nicht vertrauenswürdigem Code während des Systemstarts und damit die Bereitstellung von bösartigen UEFI-Bootkits.
  • Betroffen sind alle UEFI-Systeme, bei denen die UEFI-Signierung von Microsoft-Drittanbietern aktiviert ist (bei Windows 11 Secured-core-PCs sollte diese Option standardmäßig deaktiviert sein).
  • Das Problem wurde von den betroffenen Herstellern behoben und alte, anfällige Binärdateien wurden von Microsoft mit dem Patch Tuesday Update vom 14. Januar 2025 zurückgezogen.

ESET bedankt sich bei CERT/CC für die Zusammenarbeit bei der Offenlegung der Sicherheitslücken. Auch den betroffenen Hersteller spricht ESET seinen Dank für die transparente und reibungslose Kommunikation aus. 

Zeitlicher Ablauf von Offenlegung bis Behebung:

  • 2024-07-08: ESET hat die Sicherheitslücke gefunden.
  • 2024-07-09: ESET meldet die Sicherheitslücke an CERT/CC.
  • 2024-07-23: CERT/CC erklärt sich bereit, uns bei der Koordinierung der Veröffentlichung der Sicherheitslücke zu helfen - das Datum der Veröffentlichung wurde auf den 21.10.2024 festgelegt.
  • 2024-08-05: CERT/CC hat sich erfolgreich an die betroffenen Anbieter gewandt.
  • 2024-08-20: Die Hersteller stellen erste Patches zur Überprüfung bereit.
  • 2024-08-20: ESET bestätigte, dass das gemeldete Problem korrekt behoben wurde, entdeckte jedoch ein weiteres, neu eingeführtes Problem mit der gleichen Ursache.
  • 2024-08-28: Der Hersteller stellt einen zweiten Patch zur Überprüfung bereit.
  • 2024-09-23: Wir haben uns mit Microsoft auf das neue Veröffentlichungsdatum 2025-01-14 geeinigt.
  • 2025-01-14: Rücknahme der betroffenen anfälligen UEFI-Anwendungen durch Microsoft.
  • 2025-01-16: ESET Blogpost veröffentlicht.

UEFI Secure Boot in der realen Welt

Bevor es um die Schwachstelle geht, wollen wir uns die UEFI Secure Boot-Verifizierung auf realen Geräten ansehen und wer für die Verwaltung der UEFI Secure Boot-Datenbanken auf diesen Geräten verantwortlich ist.

Die grundlegende Logik ist recht einfach und wird in Abbildung 1 dargestellt. Wenn der UEFI-Boot-Manager eine Boot-Anwendung lädt, wie z. B. den Windows-Boot-Manager, shim, GRUB2 oder ähnliche, überprüft er die Binärdatei der Anwendung anhand von zwei Secure-Boot-Datenbanken:

  • db - Liste der zulässigen Zertifikate oder PE-Authenticode-Hashes, denen die Plattform-Firmware vertraut.
  • dbx - Liste der verbotenen Zertifikate oder PE-Authenticode-Hashes.

Die Bedingungen sind, dass das überprüfte Image von der db als vertrauenswürdig eingestuft wird und gleichzeitig der Hash der Datei oder ihr Zertifikat nicht in der dbx-Datenbank aufgeführt sein darf. Basierend auf den Verifizierungsergebnissen meldet der UEFI-Bootmanager entweder eine Sicherheitsverletzung oder führt das verifizierte Image aus.

Figure 1. UEFI Secure Boot simplified scheme
Abbildung 1. Vereinfachtes Schema von UEFI Secure Boot (Quelle: UEFI Bootkits and Where UEFI Security Fails, S. 48)

Um sicherzustellen, dass UEFI Secure Boot den Bootvorgang der wichtigsten Betriebssysteme  absichern kann, werden die meisten neuen Geräte mit einer Reihe spezifischer UEFI-Zertifikate geliefert. Diese sind in der db-Datenbank registriert. Während diese Zertifikate je nach OEM und den spezifischen Anforderungen und dem Zweck des Geräts variieren können, bittet Microsoft die OEMs bei den meisten normalen Geräten (wie Laptops, Desktops, Servern usw.), die eigenen Zertifikate von Microsoft einzubinden. Aus diesem Grund spielt Microsoft eine wichtige Rolle bei der Absicherung der meisten UEFI-basierten Geräte. Denn mit den in db eingetragenen Microsoft-Schlüsseln kann Microsoft steuern, was beim Booten ausgeführt werden darf und was nicht.

Microsoft UEFI-Zertifikate

Wie oben erläutert, werden viele UEFI-Geräte mit den UEFI-Zertifikaten von Microsoft ausgeliefert. Im Folgenden sind zwei spezifische Zertifikate aufgeführt, die normalerweise zu den vertrauenswürdigen Zertifikaten auf solchen Geräten gehören:

  • Microsoft Windows Production PCA 2011
  • Microsoft Corporation UEFI CA 2011

Wichtig: Microsoft wird demnächst das Microsoft Windows Production PCA 2011-Zertifikat widerrufen und durch das Windows UEFI CA 2023-Zertifikat ersetzen (weitere Informationen). Hierbei handelt es sich um eine Reaktion auf die anfälligen Windows-Bootloader im Zusammenhang mit dem berüchtigten BlackLotus-Bootkit. Neue oder aktualisierte Windows-Geräte werden diesem neuen Zertifikat bereits vertrauen. Das Microsoft Corporation UEFI CA 2011-Zertifikat wird anscheinend immer noch zum Signieren neuer UEFI-Anwendungen verwendet; es soll jedoch in Zukunft durch ein neues Zertifikat namens Microsoft UEFI CA 2023 ersetzt werden. 

Während Microsoft das erste Zertifikat (PCA) verwendet, um seine eigenen UEFI-Boot-Anwendungen zu signieren, kommt das Zweite zum Einsatz, um UEFI-Boot-Software von Drittanbietern zu signieren. Dazu gehören Linux-Shims, verschiedene spezialisierte Wiederherstellungs-, Backup-, Festplattenverschlüsselungs- oder Wartungssoftware usw.

Das bedeutet: Jeder, der seine Boot-Software standardmäßig UEFI Secure Boot-gestalten möchte, kann Microsoft bitten, seine Binärdateien zu signieren. Dies geht ganz einfach über das  Windows Hardware Dev Center Dashboard. Wenn die Binärdateien die interne Prüfung von Microsoft bestehen, signiert Microsoft sie mit seinem UEFI-Zertifikat eines Drittanbieters. Somit sind die Dateien mit den meisten UEFI-Systeme kompatibel, die dem Zertifikat von Microsoft vertrauen (auf Windows 11 Secured-Core-PCs sollte das UEFI-Zertifikat von Microsoft nicht als standardmäßig vertrauenswürdig angesehen werden).

Aus den online verfügbaren UEFI-Signieranforderungen von Microsoft geht nicht hervor, was der interne Überprüfungsprozess beinhaltet. Man kann aber davon ausgehen, dass eine tiefergehende Analyse mit einschließt, anstatt nur die aufgelisteten Anforderungen durchzugehen.

Der manuelle Überprüfungsprozess wird mit jeder neu entdeckten Schwachstelle besser. Dennoch wäre es hilfreich, transparenter zu machen, was genau überprüft wird und welche Schritte der Prozess umfasst. So könnten auffällige Schwachstellen, wie die in diesem Bericht beschriebene, schneller erkannt und behoben werden.

Tiefergehende tecnische Informationen finden Sie im englischen Original-Blogpost auf Welivesecurity.com: Under the cloak of UEFI Secure Boot: Introducing CVE-2024-7344