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:
Dopo il riavvio, SecurityStubDxe legge entrambe le variabili e inizia a considerare attendibile qualsiasi cosa firmata con il certificato dell'attaccante. Una dimostrazione pratica di questa prima fase è il caricamento di un driver UEFI CrScreenshotDxe firmato con un certificato personalizzato, che cattura con successo uno screenshot della schermata del BIOS Setup, con Secure Boot abilitato, come prova dell'esecuzione di codice arbitrario nell'ambiente firmware.
Una sfumatura importante: la variabile IhisiParamBuffer presente in CVE-2025-3052 è spesso bloccata sulle piattaforme basate su Insyde, rendendo lo sfruttamento diretto più difficile in quei contesti. CVE-2025-4275 non richiede che tale variabile sia scrivibile e non dipende da alcuna primitiva di corruzione della memoria. L'attacco funziona su qualsiasi sistema Insyde H2O in cui l'attaccante possa scrivere sulla NVRAM, che è il comportamento predefinito su firmware non patchato.
Quanto segue descrive l'attacco end-to-end per la fase iniziale di bypass del Secure Boot, assumendo un attaccante privilegiato con accesso a livello di OS:
Il bypass del Secure Boot ottenuto nella Parte 1 apre la porta a una seconda fase decisamente più impattante: la presa di controllo completa del volume DXE, ottenuta dirottando il processo di aggiornamento del firmware Insyde stesso.
Il sottosistema di aggiornamento del firmware in Insyde H2O funziona come segue: l'updater dell'OS colloca una capsula firmware e l'applicazione di aggiornamento firmata (isflash.bin) sulla EFI System Partition, quindi imposta un flag SecureFlashTrigger=1 all'interno della variabile NVRAM SecureFlashInfo. Al successivo avvio, il firmware rileva il trigger, disabilita le protezioni di scrittura della flash durante la fase PEI e infine chiama LoadImage su isflash.bin dopo averlo verificato rispetto al certificato Insyde, lo stesso meccanismo di certificato che CVE-2025-4275 consente a un attaccante di sostituire.
Sono necessari tre ulteriori passaggi tecnici per escalare dal bypass del Secure Boot alla presa di controllo del DXE:
Una volta soddisfatte tutte e tre le condizioni, il firmware si riavvia in modalità aggiornamento, carica l'isflash.bin personalizzato dell'attaccante (firmato con il certificato dell'attaccante, ora considerato attendibile grazie alla SecureFlashCertData shadowed) e lo esegue con la flash SPI non protetta. Da questa posizione, l'attaccante può scrivere contenuto arbitrario nel volume DXE, installando driver persistenti o modificando componenti del firmware in modi che sopravvivono alla reinstallazione dell'OS e alla maggior parte dei controlli di sicurezza.
Insyde ha rilasciato una correzione come parte del ciclo di patch del 10 giugno 2025. La correzione è stata analizzata confrontando due aggiornamenti BIOS Dell consecutivi (uno pre-patch, uno post-patch) utilizzando report generati da UEFITool e il diffing binario tramite Diaphora.
Le modifiche erano concentrate in tre driver:
La correzione è efficace presupponendo che un attaccante non possa aggirare VariablePolicy o LibSetSecureVariable. Tuttavia, l'implementazione predefinita di VariablePolicy in EDK2 utilizza internamente un flag globale, strutturalmente simile a InsydeVariableLock sconfitto nella Parte 2. La modifica fisica della NVRAM tramite hardware di programmazione SPI aggirerebbe comunque completamente la correzione, sebbene gli attacchi fisici siano convenzionalmente fuori ambito per i modelli di minaccia del Secure Boot.
La remediation raccomandata dal ricercatore, rimuovere completamente la NVRAM dal meccanismo di relay del certificato tra BdsDxe e SecurityStubDxe, è stata tentata da Insyde ma ha causato regressioni ed è stata rinviata a un futuro ciclo di ingegnerizzazione.
Qualsiasi vendor che distribuisca firmware basato su Insyde H2O costruito prima del 10 giugno 2025 è potenzialmente interessato. Stato confermato al momento della divulgazione:
| Vendor | Stato |
|---|---|
| Dell | Corretto - aggiornamenti BIOS rilasciati poco dopo la fine dell'embargo |
| Lenovo | Vulnerabile - correzioni annunciate, distribuzione dal 2025-07-30 in poi |
| Framework | Vulnerabile - nessuna stima di distribuzione fornita al momento della divulgazione |
| Acer | Nessun advisory o correzione pubblicati al momento della divulgazione |
| Fujitsu | Nessun advisory o correzione pubblicati al momento della divulgazione |
| HP | Nessun advisory o correzione pubblicati al momento della divulgazione |
| Huawei | Vendor del dispositivo di test originale - stato della correzione sconosciuto |
Stai lavorando a qualcosa di simile? Fai ricerca su UEFI, sicurezza del Kernel, exploitation o un altro interessante tema di sicurezza? Se hai bisogno di una mano per sviluppare un exploit, esplorare una tecnica o semplicemente vuoi scambiare idee, non esitare a contattarmi. Sono sempre aperto a discutere di ricerca, aiutare dove posso e collaborare a progetti interessanti. Sentiti libero di contattarmi su LinkedIn.
