I browser Web sono installati su miliardi di dispositivi in tutto il mondo, il che li rende obiettivi primari per i criminali informatici. Poiché i principali browser web hanno una base di utenti enorme, una singola vulnerabilità può avere conseguenze di vasta portata. Mantenere aggiornati i browser è fondamentale per rimanere protetti dalle minacce in continua evoluzione.
Per illustrare la gravità delle vulnerabilità nei browser web, i nostri collaboratori hanno condotto un'analisi approfondita di CVE-2024-6778, una vulnerabilità nei browser basati su Chromium, che colpisce in particolare Chrome DevTools. Questo blog fornisce un esame dettagliato degli aspetti tecnici della vulnerabilità, dell'impatto potenziale e delle strategie di mitigazione.
CVE-2024-6778: contesto
CVE-2024-6778 è una vulnerabilità race condition scoperta in Chrome DevTools. Consente agli aggressori di iniettare HTML o JavaScript dannoso in pagine del browser privilegiate tramite estensioni del browser dannose. Secondo il NVD (National Vulnerability Database), questa vulnerabilità è stata classificata come di gravità elevata, con un punteggio CVSS di 8,8.
La classificazione di gravità elevata di questa vulnerabilità è dovuta al suo potenziale di consentire l'esecuzione di codice remoto, che può compromettere i sistemi, danneggiare la riservatezza e ridurre la disponibilità.
Panoramica sulla sicurezza di Chromium
Per comprendere meglio le implicazioni di CVE-2024-6778, è importante conoscere gli aspetti chiave del modello di sicurezza di Chromium. Chromium è la base open-source di browser come Google Chrome, Microsoft Edge, Opera e Brave. Impiega un modello multi-processo in cui ogni scheda, detta anche renderer, e i vari componenti del browser vengono eseguiti in processi isolati per migliorare la stabilità e la sicurezza, limitando la portata di potenziali compromissioni.
Un elemento fondamentale della sicurezza di Chromium è il suo meccanismo di sandboxing, che limita i processi di rendering dall'accesso diretto alle risorse di sistema. Tutte le interazioni sono invece gestite attraverso canali IPC (Inter-Process Communication) per garantire che vengano eseguite solo operazioni autorizzate.
Non tutti i componenti di Chromium sono soggetti a sandboxing completo. Le pagine WebUI, come chrome://settings e chrome://downloads, sono rese all'interno dei processi di rendering ma operano con restrizioni sandbox parziali. Questo processo consente loro di accedere alle API del browser che di solito non sono accessibili via web.
Ad esempio, la pagina chrome://policy svolge un ruolo fondamentale negli ambienti aziendali, poiché consente agli amministratori e agli utenti di configurare e applicare i criteri di sicurezza del browser. Questi criteri sono gestiti anche attraverso i Criteri di gruppo nei sistemi Windows.
Poiché chrome://policy può interagire direttamente con il sistema operativo, è un obiettivo prezioso per gli aggressori. Con la vulnerabilità CVE-2024-6778 che sfrutta una condizione di gara all'interno di Chrome DevTools, gli aggressori possono iniettare codice dannoso in queste pagine, ponendo seri rischi per la sicurezza.
Analisi tecnica di CVE-2024-6778
Scoperta
Questa vulnerabilità è stata scoperta in una funzione di test introdotta nella versione 117 di Chrome Enterprise. Questa funzione consente di testare i criteri attraverso la pagina chrome://policy/test. A causa della limitata documentazione ufficiale su questa funzione, i nostri ricercatori hanno condotto un esame approfondito del codice sorgente di Chromium, integrato da approfondimenti dell'autore del CVE, per comprenderne appieno l'implementazione e identificare le vulnerabilità di sicurezza associate.
Componenti della gestione dei criteri
L'analisi del codice sorgente da parte dei borsisti OPSWAT ha rivelato che all'interno di chrome://policy/test, i criteri vengono gestiti utilizzando la funzione PoliticaInfo e comunicate tra la WebUI e i processi del browser attraverso l'interfaccia PolicyTestBrowserProxy classe. Il PoliticaInfo è definita come segue:
Da un ulteriore esame della classe responsabile della gestione di queste polizze è stato individuato un metodo denominato applicaPoliticheDiProva. Questo metodo sfrutta un'API privata, impostaPoliticheLocalTestper applicare dinamicamente un elenco di criteri.
Per capire come vengono elaborate le richieste di policy attraverso questa API, i ricercatori analizzano il file GestireSetLocalTestPolicies all'interno del metodo Gestore di politiche classe:
Il GestireSetLocalTestPolicies recupera i dati della politica dagli argomenti forniti e ottiene un puntatore al file Fornitore di politiche di test locali tramite il connettore dei criteri globali del browser. Quindi, verifica l'esistenza di questo provider prima di istruire il profilo utente corrente a utilizzarlo.
Questa verifica è risultata insufficiente, in quanto si limita ad assicurare che fornitore_locale_di_prova è non nullo prima di applicare le politiche. La creazione e l'inizializzazione di fornitore_locale_di_prova sono controllati dal CreaSeConsentito metodo:
All'interno del CreaSeConsentito il valore di ritorno dipende interamente dal risultato del metodo IsPolicyTestingEnabled funzione. Questa funzione determina se un Fornitore di politiche di test locali viene creata, in base a una combinazione di preferenze dell'utente e del canale di rilascio del browser:
Da quando pref_servizio è costantemente impostato su null ogni volta che IsPolicyTestingEnabled() viene chiamata, la prima condizione viene aggirata, lasciando che la decisione di abilitazione si basi esclusivamente sul canale di rilascio del browser.
Nelle build di Chromium senza marchio, il canale di rilascio è predefinito a Canale::UNKNOWN. Secondo la logica della funzione, Canale::UNKNOWN è trattato allo stesso modo di Canale::DEFAULTche abilita la funzione di verifica dei criteri per impostazione predefinita. L'analisi del flusso di codice ha rivelato che l'API privata impostaPoliticheLocalTest può essere invocato tramite la WebUI per applicare i criteri senza alcuna restrizione di accesso significativa.
Sfruttamento
Identificando e sfruttando questa API privata, un utente malintenzionato può applicare arbitrariamente i criteri attraverso la WebUI, consentendo la manipolazione di impostazioni quali BrowserSwitcherEnabled, BrowserSwitcherUrlList, Percorso alternativo del browser, e Parametri del browser alternativo per eseguire i comandi. Ad esempio, impostando Percorso alternativo del browser a powershell e Parametri del browser alternativo a ["calc"], è possibile eseguire comandi di shell arbitrari quando viene visitato un URL specifico.
Applicazione di un criterio utente dannoso arbitrario tramite API privata
Per dimostrare come sia possibile applicare i criteri utilizzando il metodo privato impostaPoliticheLocalTest API identificata nell'analisi precedente, il seguente codice JavaScript è uno script che imposta l'opzione Permetti l'uovo di Pasqua del dinosauro e la applica efficacemente attraverso la WebUI invocando impostaPoliticheLocalTest:
Il criterio può essere applicato con successo per disabilitare l'opzione Permetti l'uovo di Pasqua del dinosauro impostazione.
Per ottenere un impatto maggiore, un attaccante può prendere di mira il BrowserSwitcher politica:
Questo criterio consente al browser di richiamare un percorso alternativo se l'URL corrisponde a determinate condizioni. Può essere sfruttato configurando questo percorso in modo che punti a un eseguibile di sistema per eseguire comandi del sistema operativo. Il seguente codice JavaScript dimostra questo approccio:
Questo script esegue le seguenti operazioni:
- Abilita la funzione
BrowserSwitcherfunzione per example.com - Imposta il percorso del browser alternativo a powerShell
- Esegue
calcoloogni volta che si accede all'URL specificato.
Simulazione di estensione Chrome dannosa
L'identificazione dell'API privata che consente l'applicazione dei criteri introduce un vettore di attacco significativo per gli avversari. Per sfruttare efficacemente questa vulnerabilità, un aggressore dovrebbe sviluppare un'estensione Chrome dannosa che utilizzi l'API Chrome DevTools per eseguire codice JavaScript dannoso.
Per dimostrare il potenziale impatto sul mondo reale, i nostri collaboratori hanno simulato uno scenario in cui un'estensione Chrome dannosa viene installata su un browser vulnerabile e utilizzata per eseguire l'attacco.Le API chrome.devtools nelle estensioni di Chrome consentono agli sviluppatori di estendere e interagire con l'interfaccia DevTools di Chrome.
Tuttavia, l'esecuzione dell'API di DevTools attraverso un'estensione presenta alcune sfide che devono essere aggirate. Innanzitutto, l'API di DevTools è operativa solo quando DevTools è aperto e sta ispezionando attivamente un sito web. In secondo luogo, l'API di DevTools non consente l'esecuzione di codice sull'interfaccia utente web, WebUI. Questa limitazione contribuisce a mantenere la sicurezza e l'integrità dell'interfaccia Web durante i processi di sviluppo e di ispezione.
Segni che indicano l'esecuzione di Javascript tramite API reload
Un'ulteriore analisi ha rivelato che la funzione chrome.devtools.inspectedWindow.reload manca della verifica per confermare se un'estensione è autorizzata a eseguire script sulla pagina ispezionata. L'unico livello di difesa è il server delle estensioni devtools, che blocca l'accesso quando l'URL della pagina ispezionata viene modificato.
Le pagine about:blank ereditano i permessi e l'origine della pagina che le ha aperte. Ciò significa che la possibilità di eseguire codice su about:blank quando si viene reindirizzati dai segnali della WebUI è una potenziale vulnerabilità.
Esecuzione del codice sulla webUI tramite l'API reload
La condizione di gara in chrome.devtools.inspectedWindow.reload() consente l'esecuzione di codice sulle pagine WebUI di Chrome (ad esempio, chrome://policy), che di solito sono protette. L'exploit sfrutta la capacità dell'API di ricarica di iniettare JavaScript durante le transizioni di pagina. Ecco come funziona:
- Destinazione webUI: Aprire una pagina WebUI (ad esempio, chrome://policy) in una scheda e collegare DevTools.
- Iniettare script: Utilizzare l'API reload() con un file
Script iniettatoper eseguire JavaScript arbitrario durante il ricaricamento. - Exploit Race Condition: La race condition si verifica quando il reload si attiva prima che i meccanismi di sicurezza della WebUI si inizializzino completamente, consentendo l'esecuzione dello script iniettato.
Nel contesto della navigazione dalla pagina about:blank a chrome://policy:
Poiché viene verificato solo l'URL anziché l'origine della pagina, dopo la navigazione esiste un breve periodo in cui l'origine riflette la nuova pagina, mentre l'URL rimane invariato.
Se chrome.devtools.inspectedWindow.reload viene invocato durante questa finestra, potrebbe eseguire involontariamente JavaScript nella pagina di destinazione.
Migliorare l'affidabilità per le condizioni di gara
Lo sfruttamento della condizione di gara è intrinsecamente inaffidabile a causa della sua dipendenza dalla tempistica. Inoltre, ricariche rapide o script malformati possono causare crash della pagina. Un nuovo approccio per migliorare l'affidabilità consiste nell'indurre intenzionalmente un arresto anomalo della pagina, poiché i comandi emessi tramite DevTools vengono in genere annullati durante un arresto anomalo, ma Pagina.ricarica mappato su chrome.devtools.inspectedWindow.reload() viene inserito nella whitelist ed eseguito dopo il ricaricamento della pagina.
Di seguito viene illustrato un modello di flusso di lavoro per bloccare una pagina mediante l'invio di comandi successivi:
Una dichiarazione di debugger in uno script di contenuto può provocare un crash
L'uso del debugger per due volte in rapida successione interrompe il processo di navigazione in uno script di contenuto. Può portare a un arresto anomalo del sistema, posizionando stato_di_impegno_di_navigazione in uno stato non previsto. Questo problema si presenta quando RenderFrameImpl::SynchronouslyCommitAboutBlankForBug778318 viene eseguito, modifica di _navigation_commit_state a un valore inaspettato.
La prima invocazione mette in pausa l'esecuzione, lasciando stato_di_impegno_di_navigazione in uno stato incoerente, e il secondo fa una pausa durante l'esecuzione del CHECK_EQ fallendo la convalida dello stato e causando un arresto anomalo.
Bonifica
Trascurare di aggiornare regolarmente la versione del browser può lasciare il dispositivo esposto a gravi minacce alla sicurezza, soprattutto quelle legate alle CVE (Common Vulnerabilities and Exposures). Per ridurre questo rischio, MetaDefender Endpoint™ offre una solida protezione rilevando la versione del browser e verificando la presenza di vulnerabilità, comprese le CVE note come CVE-2024-6778.
MetaDefender Endpoint assicura che le applicazioni siano aggiornate e segnala eventuali versioni obsolete o infette. Inoltre, elenca le applicazioni installate con vulnerabilità note, classificate per gravità CVE, e consiglia le correzioni per mitigare efficacemente le potenziali minacce. Per vedere una demo dal vivo su come MetaDefender Endpoint può aiutarvi a ridurre i rischi, contattate oggi stesso uno dei nostri esperti.
