Analyse und Ausnutzung von CVE-2025-4275 (Hydr0ph0bia), einer Schwachstelle in der Secure-Boot-Vertrauenskette, bei der Firmware-Variablen genutzt werden, um vom Angreifer kontrollierte Zertifikate einzuschleusen, denen nachfolgende Boot-Komponenten vertrauen.
Dieses Repository enthält Forschungsmaterial zu CVE-2025-4275, einer Secure-Boot-Umgehungs-Schwachstelle, die UEFI-kompatible Firmware auf Basis von Insyde H2O betrifft. Es bündelt die technische Analyse der Schwachstelle, die an dem Problem beteiligten Binärdateien sowie Dokumentation und Werkzeuge, die Forschern helfen sollen, diese Schwachstelle sowohl in realen als auch in edukativen Kontexten besser zu verstehen, zu untersuchen und mit ihr zu experimentieren.
CVE-2025-4275 wurde ursprünglich von Nikolaj Schlej entdeckt und verantwortungsvoll offengelegt, wobei die Koordination über CERT/CC erfolgte. Offizielle und Community-Referenzen:
CVE-2025-4275, getauft auf den Namen Hydroph0bia (ein Wortspiel mit Insyde H2O), ist eine Secure-Boot-Umgehungs-Schwachstelle, die UEFI-kompatible Firmware auf Basis der Insyde-H2O-Plattform betrifft. Die Schwachstelle rührt von einem Designfehler im Firmware-Update-Subsystem her: Ein Signaturzertifikat, das eigentlich von einem vertrauenswürdigen Treiber in eine flüchtige NVRAM-Variable geladen werden soll, kann stattdessen von einem Angreifer als nicht-flüchtige Variable vorab angelegt werden, wodurch die Firmware beliebigen externen Code so vertraut, als wäre er von Insyde selbst signiert worden.
Besonders wirkungsvoll wird diese Schwachstelle durch die Kombination aus ihrer Einfachheit und ihrer Reichweite. Für die Ausnutzung sind lediglich lokale Administratorrechte erforderlich, genug, um Dateien auf die EFI-Systempartition zu schreiben und NVRAM-Variablen anzulegen, und sie betrifft jedes System, das mit Insyde-H2O-Firmware läuft, die vor dem 10. Juni 2025 erstellt wurde. Der Angriff ist OEM-unabhängig, das heißt, er gilt gleichermaßen für Acer, Dell, Framework, Fujitsu, HP, Huawei, Lenovo und jeden anderen Hersteller, der Insyde-basierte Firmware ausliefert.
UEFI bietet eine abstrakte Schnittstelle zu nicht-flüchtigem Variablenspeicher, bekannt als NVRAM. Eine seit Langem bestehende Eigenheit dieser Schnittstelle ist, dass eine nicht-flüchtige Variable mit einem bestimmten Namen und GUID neben einer flüchtigen Variable mit derselben Identität koexistieren und diese überlagern kann. Wenn Code eine flüchtige Variable erwartet (die zur Laufzeit von einem vertrauenswürdigen Treiber erstellt wird), aber bereits eine nicht-flüchtige Variable mit demselben Namen existiert, kann stattdessen die nicht-flüchtige Version verwendet werden. Dieses Verhalten, manchmal NVRAM-Variablen-Shadowing genannt, ist die Grundlage dieser Schwachstelle.
Das Firmware-Update-Subsystem von Insyde H2O stützt sich auf zwei NVRAM-Variablen, um ein Signaturzertifikat zwischen Treibern zu übermitteln:
Im erwarteten Ablauf werden beide Variablen von BdsDxe während des Firmware-Update-Prozesses als flüchtig erstellt. SecurityStubDxe verwendet sie dann, um zu überprüfen, dass isflash.bin von Insydes Zertifikat signiert ist, bevor deren Ausführung zugelassen wird. Der kritische Fehler besteht darin, dass SecurityStubDxe nicht validiert, ob diese Variablen flüchtig oder nicht-flüchtig sind, bevor sie deren Inhalt vertraut.
Die Grundursache von CVE-2025-4275 ist, dass SecurityStubDxe eine generische Bibliotheksfunktion verwendet, um SecureFlashSetupMode und SecureFlashCertData zu lesen, anstatt den GetVariable-Runtime-Dienst direkt aufzurufen. Das bedeutet, dass es nicht zwischen einer flüchtigen Variable, die von einem vertrauenswürdigen BdsDxe gesetzt wurde, und einer nicht-flüchtigen Variable, die von einem Angreifer vorab angelegt wurde, unterscheiden kann (für eine detaillierte Erklärung dieser speziellen Technik siehe das folgende Repository "TheMalwareGuardian: Exploitation Technique NVRAM Variable Shadowing").
Infolgedessen kann ein Angreifer mit lokalen Administratorrechten:
Beim nächsten Start wird SecurityStubDxe beide Variablen finden, sie als legitim behandeln und jedem UEFI-Executable vertrauen, das mit dem Zertifikat des Angreifers signiert ist, wodurch Secure Boot vollständig umgangen wird. Es ist keine Interaktion auf Firmware-Ebene, kein Hardwarezugriff und keine Ausnutzung eines Speicherkorruptions-Primitivs erforderlich. Die Angriffsfläche ist schlicht die UEFI-NVRAM-Schreibschnittstelle, die aus einer privilegierten OS-Sitzung heraus zugänglich ist.
Die Schwachstelle wurde während einer Sicherheitsüberprüfung eines HUAWEI MateBook 14 2023 entdeckt, das mit Insyde-H2O-basierter Firmware lief, bei der Secure Boot, Firmware-Passwort und andere moderne Sicherheitsfunktionen aktiviert waren. Trotz dieser Schutzmaßnahmen wurde eine vollständige Ausnutzung allein mit Administratorrechten auf OS-Ebene erreicht.
Die anfängliche Ausnutzungsphase erfordert ein kleines Windows-Tool (SFCD), das:
Nach einem Neustart liest SecurityStubDxe beide Variablen und beginnt, allem zu vertrauen, was mit dem Zertifikat des Angreifers signiert ist. Eine praktische Demonstration dieser ersten Phase ist das Laden eines mit einem benutzerdefinierten Zertifikat signierten CrScreenshotDxe-UEFI-Treibers, der erfolgreich einen Screenshot des BIOS-Setup-Bildschirms aufnimmt, während Secure Boot aktiviert ist, als Nachweis für beliebige Codeausführung in der Firmware-Umgebung.
Eine wichtige Nuance: Die in CVE-2025-3052 vorhandene Variable IhisiParamBuffer ist auf Insyde-basierten Plattformen häufig gesperrt, was eine direkte Ausnutzung dort erschwert. CVE-2025-4275 erfordert nicht, dass eine solche Variable beschreibbar ist, und hängt von keinem Speicherkorruptions-Primitiv ab. Der Angriff funktioniert auf jedem Insyde-H2O-System, auf dem der Angreifer in den NVRAM schreiben kann, was das Standardverhalten bei ungepatchter Firmware ist.
Das Folgende beschreibt den End-to-End-Angriff für die anfängliche Phase der Secure-Boot-Umgehung, unter der Annahme eines privilegierten Angreifers mit Zugriff auf OS-Ebene:
Die in Teil 1 erreichte Secure-Boot-Umgehung öffnet die Tür zu einer deutlich wirkungsvolleren zweiten Phase: der vollständigen Übernahme des DXE-Volumes, erreicht durch die Übernahme des Insyde-Firmware-Update-Prozesses selbst.
Das Firmware-Update-Subsystem in Insyde H2O funktioniert wie folgt: Der OS-Updater platziert eine Firmware-Kapsel und die signierte Updater-Anwendung (isflash.bin) auf der EFI-Systempartition und setzt dann ein Flag SecureFlashTrigger=1 innerhalb der NVRAM-Variable SecureFlashInfo. Beim nächsten Start erkennt die Firmware den Auslöser, deaktiviert während PEI die Flash-Schreibschutzmechanismen und ruft schließlich LoadImage für isflash.bin auf, nachdem sie diese gegen das Insyde-Zertifikat verifiziert hat, denselben Zertifikatsmechanismus, den CVE-2025-4275 einem Angreifer erlaubt zu ersetzen.
Drei zusätzliche technische Schritte sind erforderlich, um von der Secure-Boot-Umgehung zur DXE-Übernahme zu eskalieren:
Sobald alle drei Bedingungen erfüllt sind, startet die Firmware in den Update-Modus neu, lädt die benutzerdefinierte isflash.bin des Angreifers (signiert mit dem Zertifikat des Angreifers, das nun aufgrund der überlagerten SecureFlashCertData vertrauenswürdig ist) und führt sie aus, während der SPI-Flash ungeschützt ist. Aus dieser Position kann der Angreifer beliebige Inhalte in das DXE-Volume schreiben, persistente Treiber installieren oder Firmware-Komponenten so verändern, dass sie eine Neuinstallation des Betriebssystems und die meisten Sicherheitskontrollen überstehen.
Insyde veröffentlichte einen Fix als Teil des Patch-Zyklus vom 10. Juni 2025. Der Fix wurde analysiert, indem zwei aufeinanderfolgende Dell-BIOS-Updates (eines vor dem Patch, eines nach dem Patch) mithilfe von UEFITool-generierten Berichten und Binär-Diffing via Diaphora verglichen wurden.
Die Änderungen konzentrierten sich auf drei Treiber:
Der Fix ist unter der Annahme wirksam, dass ein Angreifer VariablePolicy oder LibSetSecureVariable nicht umgehen kann. Die Standardimplementierung von VariablePolicy in EDK2 verwendet jedoch intern ein globales Flag, das strukturell dem in Teil 2 überwundenen InsydeVariableLock ähnelt. Eine physische NVRAM-Bearbeitung über SPI-Programmierhardware würde den Fix ebenfalls vollständig umgehen, obwohl physische Angriffe herkömmlicherweise außerhalb des Geltungsbereichs von Secure-Boot-Bedrohungsmodellen liegen.
Die vom Forscher empfohlene Behebung, den NVRAM vollständig aus dem Zertifikatsweiterleitungsmechanismus zwischen BdsDxe und SecurityStubDxe zu entfernen, wurde von Insyde versucht, verursachte jedoch Regressionen und wurde auf einen zukünftigen Entwicklungszyklus verschoben.
Jeder Hersteller, der Insyde-H2O-basierte Firmware ausliefert, die vor dem 10. Juni 2025 erstellt wurde, ist potenziell betroffen. Bestätigter Status zum Zeitpunkt der Offenlegung:
| Hersteller | Status |
|---|---|
| Dell | Behoben - BIOS-Updates kurz nach Ende des Embargos veröffentlicht |
| Lenovo | Anfällig - Fixes angekündigt, Bereitstellung ab 2025-07-30 |
| Framework | Anfällig - zum Zeitpunkt der Offenlegung keine Angabe zum Liefertermin |
| Acer | Zum Zeitpunkt der Offenlegung kein Advisory oder Fix veröffentlicht |
| Fujitsu | Zum Zeitpunkt der Offenlegung kein Advisory oder Fix veröffentlicht |
| HP | Zum Zeitpunkt der Offenlegung kein Advisory oder Fix veröffentlicht |
| Huawei | Hersteller des ursprünglichen Testgeräts - Fix-Status unbekannt |
Arbeiten Sie an etwas Ähnlichem? Forschen Sie zu UEFI, Kernel-Sicherheit, Exploitation oder einem anderen interessanten Sicherheitsthema? Wenn Sie Unterstützung bei der Entwicklung eines Exploits, beim Erkunden einer Technik benötigen oder einfach Ideen austauschen möchten, zögern Sie nicht, sich zu melden. Ich bin immer offen für den Austausch über Forschung, helfe, wo ich kann, und arbeite gerne an interessanten Projekten mit. Kontaktieren Sie mich gerne auf LinkedIn.
