CVE-2025-4275 — Updated!
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.
🐞 CVE-2025-4275: Hydroph0bia SecureFlash Certificate Shadowing
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.
📑 Indice
- Scoperta Originale & Riferimenti Ufficiali
- Panoramica della Vulnerabilità (Analisi, Sfruttamento, PoC)
🧠 Scoperta Originale & Riferimenti Ufficiali
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:
- Blog del Ricercatore - Parte 1 (bypass del Secure Boot)
- Blog del Ricercatore - Parte 2 (DXE volume takeover)
- Blog del Ricercatore - Parte 3 (analisi della patch)
- Advisory ufficiale Insyde (10 giugno 2025)
- Raccolta di riferimenti della community
🧪 Panoramica della Vulnerabilità (Analisi, Sfruttamento, PoC)
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.
🔐 NVRAM & Secure Boot in Insyde H2O
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:
- SecureFlashSetupMode: una variabile trigger letta da SecurityStubDxe per attivare la verifica basata su certificato.
- SecureFlashCertData: una variabile che trasporta il certificato di firma in formato EFI_SIGNATURE_LIST, utilizzata per autenticare l'applicazione di aggiornamento del firmware (isflash.bin).
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.
💣 NVRAM Variable Shadowing
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ò:
- Creare una variabile trigger SecureFlashSetupMode non volatile prima che inizi il flusso di aggiornamento del firmware.
- Creare una variabile SecureFlashCertData non volatile contenente un certificato controllato dall'attaccante in formato EFI_SIGNATURE_LIST.
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.
💥 Individuazione & Sfruttamento della Vulnerabilità
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:
- Acquisisce il privilegio SeSystemEnvironmentPrivilege necessario per chiamare SetFirmwareEnvironmentVariable.
- Crea la variabile non volatile SecureFlashCertData contenente un certificato controllato dall'attaccante.
- Crea la variabile trigger non volatile SecureFlashSetupMode impostata a 1.
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.
🎯 Attacco (Parte 1 - Bypass del Secure Boot)
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:
- Generare un certificato personalizzato: L'attaccante genera una coppia di chiavi e incapsula il certificato pubblico nel formato EFI_SIGNATURE_LIST.
- Impostare le variabili NVRAM: Utilizzando lo strumento SFCD da una sessione di Windows Administrator, l'attaccante crea le variabili non volatili SecureFlashCertData (contenente il certificato personalizzato) e SecureFlashSetupMode (impostata a 1).
- Firmare un payload: L'attaccante firma qualsiasi applicazione o driver UEFI con la propria chiave privata personalizzata.
- Registrare il payload: Il payload firmato viene registrato come driver UEFI tramite il meccanismo dell'opzione di avvio DriverXXXX, oppure inserito come voce di avvio nell'UEFI Boot Manager.
- Riavviare: Al successivo avvio, SecurityStubDxe legge le variabili NVRAM shadowed, considera attendibile il certificato dell'attaccante e consente l'esecuzione del payload firmato indipendentemente dallo stato del Secure Boot.
🔺 Escalation (Parte 2 - DXE Volume Takeover)
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:
- Aggirare la cancellazione di SecureFlashCertData : SecureFlashDxe tenta di eliminare la variabile del certificato prima di chiamare LoadImage, utilizzando una chiamata SetVariable naked che non può rimuovere le variabili speciali Insyde Authenticated Write (AW). L'attaccante reimposta il certificato come variabile speciale con attributo AW per sopravvivere a questo tentativo di cancellazione.
- Sbloccare InsydeVariableLock: VariableRuntimeDxe imposta un flag globale (InsydeVariableLock) che impedisce la creazione di variabili AW dopo l'avvio di BDS. Registrando un driver UEFI tramite DriverXXXX (che viene eseguito prima che questo lock sia attivato), l'attaccante individua il flag in memoria analizzando la catena di hook BdsArchProtocol->Entry e lo commuta da 1 a 0.
- Impostare SecureFlashInfo: La variabile SecureFlashInfo è normalmente protetta da VariableLockProtocol, ma questo lock viene attivato solo a ReadyToBoot. Un driver registrato tramite DriverXXXX viene eseguito prima di questo evento e può liberamente impostare SecureFlashTrigger=1 per avviare il flusso di aggiornamento del firmware.
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.
🩹 Fix (Parte 3 - Analisi della Patch)
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:
- BdsDxe: Sostituita la chiamata naked gRT->SetVariable (che non poteva rimuovere le variabili speciali con attributo AW) con una chiamata LibSetSecureVariable che utilizza la comunicazione SMM e può rimuovere tali variabili.
- SecureFlashDxe: Applicata la stessa sostituzione con LibSetSecureVariable, aggiunta la cancellazione esplicita di SecureFlashSetupMode e SecureFlashCertData all'entry point del driver, e registrata una VariablePolicy per entrambe le variabili per bloccarne la creazione da codice a livello di OS.
- SecurityStubDxe: Correzione minore non correlata al gestore dell'evento `ExitBootServices; il percorso della vulnerabilità principale rimane strutturalmente invariato.
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.
📦 Vendor Interessati
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 |
🤝 Ricerca & Collaborazione
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.