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:
