CVE-2025-3052 — Updated!
Ricerca su CVE-2025-3052, una vulnerabilità del firmware Insyde che espone una primitiva di scrittura arbitraria in grado di modificare puntatori critici per la sicurezza.
🐞 CVE-2025-3052: Corruzione di Memoria in IhisiParamBuffer
Questo repository centralizza il materiale di ricerca relativo a CVE-2025-3052, una vulnerabilità di corruzione di memoria in un modulo UEFI firmato con il certificato di terze parti di Microsoft che consente a un attaccante di corrompere strutture firmware critiche per la sicurezza, neutralizzare l'applicazione di Secure Boot ed eseguire codice arbitrario non firmato prima del caricamento del sistema operativo. Include l'analisi tecnica della causa principale e della tecnica di sfruttamento, binari vulnerabili reali ed educativi, e documentazione di supporto pensata per aiutare i ricercatori a comprendere, riprodurre e sperimentare con questa classe di vulnerabilità.
📑 Indice
- Scoperta Originale & Riferimenti Ufficiali
- Binari Vulnerabili (Reali / Educativi)
- Panoramica della Vulnerabilità (Analisi, Sfruttamento, PoC)
🧠 Scoperta Originale & Riferimenti Ufficiali
CVE-2025-3052 è stata originariamente scoperta e divulgata in modo responsabile dal Binarly Research Team. Riferimenti ufficiali e della community:
- Binarly Research Blog (10 giugno 2025)
- Raccolta di riferimenti della community
🐜 Binari Vulnerabili
Questo repository include due binari vulnerabili, forniti con diversi obiettivi di ricerca e apprendimento.
🧨 Binario Vulnerabile Reale
Questo binario rappresenta la vulnerabilità così come esisteva in natura.
- Applicazione UEFI vulnerabile originale affetta da CVE-2025-3052.
- Destinato all'analisi reale e al reverse engineering.
- Firmato con il certificato UEFI di terze parti di Microsoft.
- Estratto da repository pubblici di malware:
🎓 Binario Vulnerabile Educativo
- Codice sorgente completamente compilabile di un'applicazione UEFI educativa semplificata.
- Riproduce la stessa premessa di vulnerabilità del binario reale.
- Progettato per aiutare i principianti:
- A progredire gradualmente verso l'analisi del binario originale.
- A evitare il pesante reverse engineering nelle fasi iniziali.
- A comprendere i meccanismi della vulnerabilità.
🧪 Panoramica della Vulnerabilità (Analisi, Sfruttamento, PoC)
CVE-2025-3052 è una vulnerabilità di bypass di Secure Boot che colpisce i sistemi UEFI, causata dalla gestione non sicura dei dati recuperati da una variabile NVRAM all'interno di un'applicazione UEFI firmata. La vulnerabilità consente a un attaccante di corrompere strutture firmware critiche per la sicurezza durante il processo di avvio, rompendo di fatto la catena di fiducia UEFI e consentendo l'esecuzione di codice non firmato prima del caricamento del sistema operativo.
Ciò che rende questa vulnerabilità particolarmente impattante non è solo la natura del bug in sé, una primitiva di corruzione di memoria, ma il contesto in cui esiste: un modulo UEFI firmato con il certificato UEFI di terze parti di Microsoft, considerato affidabile per impostazione predefinita sulla stragrande maggioranza dei sistemi moderni. Di conseguenza, lo sfruttamento avviene in una delle fasi di esecuzione più precoci e privilegiate della piattaforma, prima dei controlli di sicurezza a livello di sistema operativo.
🔐 Secure Boot & Certificati Microsoft
Secure Boot è una funzionalità di sicurezza fondamentale di UEFI progettata per far rispettare la catena di fiducia della piattaforma dal firmware al sistema operativo. Il suo scopo principale è impedire l'esecuzione di componenti di avvio non autorizzati o malevoli, come i bootkit, durante il processo di avvio.
Ad alto livello, Secure Boot funziona convalidando crittograficamente gli eseguibili UEFI prima che sia consentita la loro esecuzione. Questa convalida viene eseguita utilizzando due database mantenuti dal firmware:
- db: Contiene hash Authenticode attendibili e certificati root attendibili.
- dbx: Contiene hash e certificati revocati o esplicitamente non attendibili.
Un'applicazione UEFI può essere eseguita se:
- Il suo hash Authenticode corrisponde a una voce in db, oppure
- La sua catena di certificati si convalida fino a un certificato root attendibile presente in db, e non è presente in dbx.
Per impostazione predefinita, la maggior parte dei sistemi viene fornita con i seguenti certificati attendibili in db:
- Microsoft Corporation UEFI CA 2011 - utilizzato per firmare componenti UEFI di terze parti, incluso lo shim di Linux.
- Microsoft Windows Production PCA 2011 - utilizzato per firmare il bootloader di Windows.
- Uno o più certificati di proprietà dell'OEM.
I moduli vulnerabili associati a CVE-2025-3052 sono stati firmati utilizzando il certificato Microsoft Corporation UEFI CA 2011. Poiché questo certificato è ampiamente attendibile su vendor e piattaforme, qualsiasi applicazione firmata che lo utilizzi può essere eseguita sulla maggior parte dei sistemi UEFI senza interazione dell'utente. Questa ampia fiducia amplifica significativamente l'impatto di una vulnerabilità all'interno di un tale modulo, poiché aggira di fatto le garanzie di protezione previste da Secure Boot.
🔎 Scoperta del Modulo & Ricognizione
Il modulo UEFI vulnerabile è stato inizialmente scoperto durante l'analisi su larga scala di binari UEFI caricati su repository pubblici di malware, in particolare VirusTotal. Sebbene il primo invio pubblico del modulo sia avvenuto nel novembre 2024, l'ispezione della sua firma Authenticode ha rivelato che era stato firmato già nell'ottobre 2022, indicando che il binario potrebbe essere stato in circolazione per un periodo considerevole prima del rilevamento.
Il nome file originale osservato durante l'analisi era Dtbios-efi64-71.22.efi. L'esame delle stringhe incorporate, dei metadati del certificato e del comportamento del file ha suggerito fortemente che il modulo fosse stato sviluppato da DT Research, Inc, un vendor specializzato in dispositivi mobili da computing rugged.
Ulteriori reverse engineering hanno rivelato che il modulo è un'utilità di flashing del BIOS, progettata per leggere un'immagine firmware dal disco e scriverla nella ROM del sistema. Sebbene originariamente destinato all'hardware DT Research, il modulo non è limitato a una piattaforma specifica e può essere eseguito su qualsiasi sistema che consideri attendibile il certificato UEFI di terze parti di Microsoft.
Un indizio critico durante la ricognizione è stata la presenza della variabile NVRAM IhisiParamBuffer. Questa variabile è strettamente associata alle implementazioni firmware basate su Insyde ed era già stata coinvolta in altre vulnerabilità divulgate da Binarly (ad es., BRLY-2022-023 e BRLY-2023-005). La sua presenza ha immediatamente suggerito una potenziale classe di problemi legati alla NVRAM.
💥 Individuazione & Sfruttamento della Vulnerabilità
La causa principale di CVE-2025-3052 risiede nell'uso non sicuro dei dati letti da una variabile NVRAM senza convalida. Nello specifico:
- L'applicazione UEFI recupera il valore della variabile NVRAM IhisiParamBuffer.
- Questo valore viene trattato come un puntatore attendibile e memorizzato in una variabile globale all'indirizzo 0xf7a0.
- Il codice esegue successivamente un'operazione di scrittura in memoria a global + 0x18, impostando quell'indirizzo a zero.
- Seguono ulteriori operazioni di scrittura, tutte derivate dallo stesso valore NVRAM controllato dall'attaccante.
- Non viene applicato alcun controllo dei limiti, convalida di sanità o controllo degli accessi in nessun punto.
Di conseguenza, un attaccante che riesce a controllare la variabile IhisiParamBuffer ottiene la capacità di influenzare dove avvengono queste scritture in memoria. Sebbene la primitiva di scrittura sia alquanto limitata, consentendo tipicamente scritture di zero o piccole costanti a un indirizzo arbitrario, è comunque abbastanza potente da corrompere uno stato firmware critico.
Nel proof of concept di Binarly, l'attacco prende di mira la variabile globale gSecurity2, che contiene un puntatore al Security2 Architectural Protocol (per una spiegazione dettagliata di questa specifica tecnica di sfruttamento, fare riferimento al seguente repository "TheMalwareGuardian: Exploitation Technique SecureBoot Bypass gSecurity2 Corruption"). Questo protocollo viene consultato dal servizio LoadImage per far rispettare la policy di Secure Boot, il che significa che sovrascrivere gSecurity2 con un puntatore nullo disabilita di fatto i controlli di Secure Boot a runtime. Fondamentalmente, questo bypass è trasparente per il sistema operativo: una volta avviato, Secure Boot appare ancora abilitato a livello di sistema operativo anche se è stato completamente neutralizzato a livello di firmware.
Una sfumatura importante è che sulle piattaforme basate su Insyde, la variabile IhisiParamBuffer è tipicamente bloccata in sola lettura, il che impedisce di fatto lo sfruttamento su quei sistemi senza una vulnerabilità aggiuntiva. Ironia della sorte, ciò significa che il vendor il cui IBV ha introdotto in primo luogo il pattern della variabile vulnerabile è tra i meno esposti, mentre tutte le altre piattaforme rimangono a rischio. Nei casi in cui la variabile è bloccata, un bypass come BRLY-2023-005 può essere concatenato per ottenere l'accesso in scrittura alla variabile prima di procedere con lo sfruttamento. Sui sistemi in cui la variabile è direttamente scrivibile, l'attacco è semplice e altamente affidabile.
🎯 Flusso dell'Attacco
Quanto segue descrive l'attacco end-to-end che sfrutta CVE-2025-3052, assumendo un attaccante privilegiato con accesso a livello di sistema operativo:
- Impostare la variabile NVRAM: L'attaccante imposta la variabile NVRAM IhisiParamBuffer dal sistema operativo a un indirizzo di destinazione arbitrario, puntandola a gSecurity2.
- Registrare il payload: L'attaccante registra il modulo firmato vulnerabile nell'UEFI Boot Manager (o sostituisce un OS loader esistente con esso), e registra inoltre un secondo modulo non firmato contenente il payload effettivo.
- Riavviare: Dopo il riavvio del sistema, il firmware entra nella fase Boot Device Selection (BDS) e inizia a eseguire le voci di avvio registrate.
- Esecuzione: Il modulo firmato vulnerabile viene eseguito per primo. La sua primitiva di scrittura limitata viene utilizzata per sovrascrivere gSecurity2 con null, disabilitando l'applicazione di Secure Boot. Con i controlli neutralizzati, il firmware procede a caricare ed eseguire il modulo payload non firmato, concedendo all'attaccante l'esecuzione di codice arbitrario alla fine della fase DXE, prima che il sistema operativo abbia qualsiasi opportunità di stabilire le proprie difese.
📦 Moduli Affetti
Microsoft ha determinato che 14 diversi moduli UEFI erano affetti e ha mitigato il problema aggiungendo i loro hash al dbx di Secure Boot.
| Nome del Modulo | Hash Authenticode SHA-256 |
|---|---|
| BiosFlashShell-efi64-80.02.efi | C54A4060B3A76FA045B7B60EEAEBC8389780376BA3EF1F63D417BA1B5528E95 |
| BiosFlashShell-efi64-81.02.efi | CBFAA286144EB2D165A6B17245BAD4F73058436C7292BE56DC6EBA29A369ADDF |
| Dtbios-efi64-70.17.efi | 9D7E7174C281C6526B44C632BAA8C3320ADDD0C77DC90778CC14893882D74618 |
| Dtbios-efi64-70.18.efi | 9B1F35052CFC5FB06DABE5E8F7B747F081DA28D722DB59ADE253B9E38A7A3C76 |
| Dtbios-efi64-70.19.efi | E3CE55E584371D3F2FBCA2241EF0711FF80876EBF71BAB07D8ECEE645A40DCFC |
| Dtbios-efi64-70.20.efi | EE093913ABBD34CB8B5EA31375179A8B55A298353C03AFE5055AA4E8E3F705EF |
| Dtbios-efi64-70.21.efi | B4E1880425F7857B741B921D04FD9276130927CF90A427C454B970E7A2F442F9 |
| Dtbios-efi64-70.22.efi | CDA0B4A59390B36E1B654850428CBB5B4C7B5E4349E87ACDE97FB543736FF1D4 |
| Dtbios-efi64-71.17.efi | C87EFD057497F90321D62A69B311912B8EF8A045FE9C5E6BD5C8C1A4E6F39629 |
| Dtbios-efi64-71.18.efi | 9E19DD645235341A555D6AC0665591453AE13918ECD37DF22DFBEE91EAA9A2DA |
| Dtbios-efi64-71.19.efi | 63F67824FDA998798964FF33B87441857DA92F3A8EE3E04166EEC3156E4E6B82 |
| Dtbios-efi64-71.20.efi | 0BC4F078388D41AB039F87AE84CF8D39302CCBDD70C4ADEE02263EBF6A2DD328 |
| Dtbios-efi64-71.21.efi | E2AEC271B9596A461EB6D54DB81785E4E4C615CFDA5F4504BCC0A329248A4D36 |
| Dtbios-efi64-71.22.efi | 6B4328EBCBE46ED9118FF2D4472DE329D70BA83016DF7A6F50F8AF92342160A1 |
🤝 Ricerca & Collaborazione
Stai lavorando a qualcosa di simile? Stai facendo ricerca su UEFI, sicurezza del Kernel, sfruttamento o un altro interessante argomento 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.