Analisi e sfruttamento di CVE-2025-4275 (Hydr0ph0bia), una debolezza della catena di fiducia del Secure Boot in cui le variabili del firmware vengono utilizzate per introdurre certificati controllati dall'attaccante e considerati attendibili dai successivi componenti di avvio.
Questo repository contiene materiale di ricerca relativo a CVE-2025-4275, una vulnerabilità di bypass del Secure Boot che interessa firmware compatibili UEFI basati su Insyde H2O. Centralizza l'analisi tecnica della vulnerabilità, i binari coinvolti nel problema, nonché documentazione e strumenti pensati per aiutare i ricercatori a comprendere meglio, studiare e sperimentare questa vulnerabilità sia in contesti reali che educativi.
CVE-2025-4275 è stata originariamente scoperta e divulgata in modo responsabile da Nikolaj Schlej, con il coordinamento gestito tramite CERT/CC. Riferimenti ufficiali e della community:
CVE-2025-4275, soprannominata Hydroph0bia (un gioco di parole su Insyde H2O), è una vulnerabilità di bypass del Secure Boot che interessa firmware compatibili UEFI costruiti sulla piattaforma Insyde H2O. La vulnerabilità deriva da un difetto di progettazione nel sottosistema di aggiornamento del firmware: un certificato di firma che dovrebbe essere caricato in una variabile NVRAM volatile da un driver attendibile può invece essere pre-popolato come variabile non volatile da un attaccante, facendo sì che il firmware consideri attendibile codice esterno arbitrario come se fosse stato firmato da Insyde stessa.
Ciò che rende questa vulnerabilità particolarmente impattante è la combinazione della sua semplicità e della sua portata. Lo sfruttamento richiede solo privilegi di amministratore locale, sufficienti per scrivere file sulla EFI System Partition e creare variabili NVRAM, e interessa qualsiasi sistema che esegua firmware Insyde H2O costruito prima del 10 giugno 2025. L'attacco è indipendente dall'OEM, il che significa che si applica ampiamente ad Acer, Dell, Framework, Fujitsu, HP, Huawei, Lenovo e qualsiasi altro vendor che distribuisca firmware basato su Insyde.
UEFI fornisce un'interfaccia astratta per l'archiviazione di variabili non volatili nota come NVRAM. Una particolarità di lunga data di questa interfaccia è che una variabile non volatile con un dato nome e GUID può coesistere con, e oscurare, una variabile volatile con la stessa identità. Se il codice si aspetta una variabile volatile (creata a runtime da un driver attendibile) ma esiste già una variabile non volatile con lo stesso nome, la versione non volatile può essere utilizzata al suo posto. Questo comportamento, talvolta chiamato NVRAM variable shadowing, è il fondamento di questa vulnerabilità.
Il sottosistema di aggiornamento del firmware di Insyde H2O si basa su due variabili NVRAM per comunicare un certificato di firma tra i driver:
Nel flusso previsto, entrambe le variabili vengono create come volatili da BdsDxe durante il processo di aggiornamento del firmware. SecurityStubDxe le consuma poi per verificare che isflash.bin sia firmato dal certificato di Insyde prima di consentirne l'esecuzione. Il difetto critico è che SecurityStubDxe non convalida se queste variabili siano volatili o non volatili prima di considerare attendibile il loro contenuto.
La causa principale di CVE-2025-4275 è che SecurityStubDxe utilizza una funzione di libreria generica per leggere SecureFlashSetupMode e SecureFlashCertData invece di chiamare direttamente il servizio runtime GetVariable. Ciò significa che non è in grado di distinguere tra una variabile volatile impostata da un BdsDxe attendibile e una non volatile pre-popolata da un attaccante (per una spiegazione dettagliata di questa specifica tecnica, fare riferimento al seguente repository "TheMalwareGuardian: Exploitation Technique NVRAM Variable Shadowing").
Di conseguenza, un attaccante con privilegi di amministratore locale può:
Al successivo avvio, SecurityStubDxe troverà entrambe le variabili, le tratterà come legittime e considererà attendibile qualsiasi eseguibile UEFI firmato con il certificato dell'attaccante, aggirando di fatto completamente il Secure Boot. Non è richiesta alcuna interazione a livello di firmware, accesso hardware o sfruttamento di una primitiva di corruzione della memoria. La superficie d'attacco è semplicemente l'interfaccia di scrittura NVRAM UEFI, accessibile da una sessione OS privilegiata.
La vulnerabilità è stata scoperta durante una revisione di sicurezza di un HUAWEI MateBook 14 2023, che eseguiva un firmware basato su Insyde H2O con Secure Boot, password del firmware e altre moderne funzionalità di sicurezza abilitate. Nonostante queste protezioni, lo sfruttamento completo è stato ottenuto utilizzando solo privilegi di amministratore a livello di OS.
La fase iniziale di sfruttamento richiede un piccolo strumento Windows (SFCD) che:
