La vulnerabilità Log4Shell, la brutta sorpresa di fine 2021

Di Steve Povolny e Douglas McKee · 19 gennaio 2022

Panoramica

Il 9 dicembre, su Twitter è stata pubblicata una vulnerabilità (CVE-2021-44228) che interessava la libreria di registrazione Apache Log4j insieme a una prova di concetto (PoC) su GitHub. Il bug è stato portato all'attenzione di Apache per la prima volta il 24 novembre da Chen Zhaojun, un membro del team di sicurezza di Alibaba Cloud.

È probabile che questa vulnerabilità abbia un impatto importante a causa del suo effetto su tutti i prodotti che integrano la libreria Log4j nelle loro applicazioni, inclusi prodotti e servizi di giganti di Internet come Apple iCloud, Steam, Samsung Cloud e migliaia di altri prodotti e servizi. Questo è solo l'inizio, poiché Java è ampiamente utilizzato in applicazioni che interessano quasi tutti i settori. Tuttavia, le aziende possono implementare determinate precauzioni e strategie per creare resilienza e proteggersi da queste nuove e crescenti minacce, compresa la protezione proattiva.

Di cosa si tratta?

La vulnerabilità è dovuta al modo in cui la funzione Java Naming and Directory Interface (JNDI) risolve le variabili. Quando un riferimento JNDI viene scritto in un registro, la funzione JNDI recupera tutti gli elementi necessari per risolvere la variabile. Per completare il processo, scarica ed esegue tutte le classi remote necessarie. Questo vale sia per le applicazioni lato server che lato client poiché i requisiti principali per la vulnerabilità sono un campo di inserimento controllato dal criminale informatico e la conseguente trasmissione al registro.

Per orchestrare questo attacco, il criminale informatico può utilizzare numerose ricerche JNDI differenti. La ricerca più comunemente osservata attualmente sia nella prova di concetto che nello sfruttamento attivo è su LDAP. Tuttavia, anche altre ricerche come RMI e DNS sono validi vettori di attacco. Vale la pena notare che i semplicistici vettori di attacco basati su LDAP/RMI funzionano solo con le vecchie versioni di JDK. Alcune pubblicazioni hanno dimostrato metodi per aggirare questa limitazione al fine di indurre l'esecuzione di codice, sebbene ciò renda l'attacco più complesso.

Le vulnerabilità di deserializzazione degli oggetti Java non rappresentano un nuovo tipo di vulnerabilità o attacchi. Precedenti ricerche offensive come “marshalsec” possono essere applicate a questa vulnerabilità per semplificare l'esecuzione del codice.

Evoluzione e risposta

• Il 14 dicembre è stato confermato che Log4j versione 1.2 è vulnerabile ad attacchi simili tramite il componente JMSAppender, oggetto del bollettino CVE-2021-4104. È importante sottolineare che questa versione non è facilmente sfruttabile come le versioni da 2.0-alpha1 a 2.16.0. Affinché lo sfruttamento abbia esito positivo, JMSAppender deve essere abilitato e impostato con le configurazioni TopicBindingName o TopicConnectionFactoryBindingName che consentono a JMSAppender di eseguire query JNDI. Questa non è la configurazione predefinita.

A seguito di questa conferma, Apache ha rilasciato una nuova versione di Log4j, versione 2.16.0. Questo aggiornamento ha disabilitato JDNI per impostazione predefinita, richiedendo all'utente di abilitare esplicitamente la funzione JNDI e ha rimosso completamente il supporto per la ricerca dei messaggi.

• Il 18 dicembre una nuova vulnerabilità di negazione di servizio (Denial of Service, DoS) che interessava le versioni da 2.0-alpha1 a 2.16.0 di Log4j è stata identificata e denominata CVE-2021-45105. Per eliminare i rischi posti dalla vulnerabilità originale di Log4j, Apache ha disabilitato completamente le ricerche JNDI nella versione 2.16.0, ma le ricerche autoreferenziali erano ancora possibili nelle configurazioni non predefinite. Quando una variabile annidata viene sostituita dalla classe StrSubstitutor, la stessa chiama in modo ricorsivo la classe substitute(). Quando questa variabile nidificata fa riferimento alla variabile sostituita in modo ricorsivo, provoca una ricorrenza infinita e una condizione di negazione di servizio (DoS) sul server. Le ricerche attuali indicano che ciò non comporta l'esecuzione di codice, a differenza delle vulnerabilità precedenti.

A questo punto, Apache ha rilasciato una nuova versione di Log4j, versione 2.17.0, per correggere l'ultima vulnerabilità DoS. Sono state create due classi aggiuntive a partire da StrSubstitutor per gestire l'analisi delle stringhe di caratteri che possono contenere l'input dell'utente. Queste aggiunte non consentono una valutazione ricorsiva. Poiché lo sfruttamento di questa vulnerabilità porta a una condizione DoS, è considerata meno critica rispetto alle vulnerabilità segnalate in precedenza in Log4j, che possono portare all'esecuzione di codice da remoto.

È importante notare che affinché l'exploit abbia successo, devono essere soddisfatte diverse condizioni non standard. Poiché la situazione di Log4j continua ad evolversi, consigliamo di eseguire l'aggiornamento alla versione 2.17.1, ove possibile. Suggeriamo inoltre di cogliere questa opportunità per rivedere le strategie e le pratiche di sicurezza generali all'inizio del nuovo anno.

Una prospettiva positiva per il futuro

Sono disponibili molte informazioni sui diversi modi per eliminare i rischi associati a questa vulnerabilità, con la possibilità per gli esseri umani e le macchine di imparare e adattarsi costantemente insieme. Di fronte a minacce sempre più dinamiche, strategie e processi devono fare lo stesso per garantire l’ottimizzazione e la protezione delle operazioni aziendali. Log4j offre alle aziende la possibilità di non vedere più le minacce come un inevitabile svantaggio, ma piuttosto come un'opportunità per crescere, imparare e adattarsi per rafforzare la resilienza e sviluppare un vantaggio.

Abbiamo monitorato da vicino questa vulnerabilità da quando è diventata nota, riconoscendo che la sicurezza deve evolversi insieme alle minacce che evolvono rapidamente come Log4j. Il nostro obiettivo iniziale era determinare la facilità d'uso utilizzando il PoC pubblico, che abbiamo riprodotto e confermato. Per questo, abbiamo utilizzato il container Docker pubblico e un'architettura client-server che utilizza LDAP e RMI, nonché lo strumento marshalsec per sfruttare la versione 2.14.1 di Log4j.

Abbiamo in programma di testare le varianti dell'exploit fornito utilizzando altri servizi come DNS. Nel frattempo, abbiamo rilasciato la firma di rete KB95088 per i clienti che utilizzano la soluzione Network Security Platform (NSP). Questa firma rileva i tentativi di sfruttare la vulnerabilità CVE-2021-44228 in LDAP. Può essere estesa per includere altri protocolli o servizi. E per completare la copertura possono essere pubblicate anche altre firme.

Cerchi altre risorse?

Puoi seguire il nostro resoconto su questa vulnerabilità dal nostro bollettino sulla sicurezza qui mentre un elenco crescente di PoC e strumenti è disponibile qui:

• https://github.com/pedrohavay/exploit-CVE-2021-44228
• https://github.com/christophetd/log4shell-vulnerable-app
• https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
• https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22
• https://rules.emergingthreatspro.com/open/
• https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
• https://github.com/corretto/hotpatch-for-apache-log4j2
• https://github.com/nccgroup/log4j-jndi-be-gone