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.
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à.
CVE-2025-3052 è stata originariamente scoperta e divulgata in modo responsabile dal Binarly Research Team. Riferimenti ufficiali e della community:
Questo repository include due binari vulnerabili, forniti con diversi obiettivi di ricerca e apprendimento.
Questo binario rappresenta la vulnerabilità così come esisteva in natura.
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 è 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:
Un'applicazione UEFI può essere eseguita se:
Per impostazione predefinita, la maggior parte dei sistemi viene fornita con i seguenti certificati attendibili in db:
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.
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.
La causa principale di CVE-2025-3052 risiede nell'uso non sicuro dei dati letti da una variabile NVRAM senza convalida. Nello specifico:
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.
Quanto segue descrive l'attacco end-to-end che sfrutta CVE-2025-3052, assumendo un attaccante privilegiato con accesso a livello di sistema operativo:
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 |
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.
