Alcuni cybercriminali stanno attivamente sfruttando una vulnerabilità critica in Apache Log4j, una libreria di log utilizzata in milioni di applicazioni basate su Java, comprese quelle basate sul Web. Le aziende dovrebbero verificare immediatamente se le loro app, in particolare quelle accessibili al pubblico, utilizzano questa libreria e dovrebbero implementare le apposite mitigazioni il prima possibile.

Un exploit proof-of-concept per la vulnerabilità, ora identificato come CVE-2021-44228, è stato pubblicato il 9 dicembre mentre gli sviluppatori di Apache Log4j stavano ancora lavorando al rilascio di una versione con patch. Gli attacchi sono iniziati subito dopo, rendendo il difetto un problema zero-day (senza patch) al momento dello sfruttamento. Apache da allora ha rilasciato Log4j 2.15.0, che include un fix.

L’exploit Log4Shell

La vulnerabilità può portare all’esecuzione di codice remoto sui server sottostanti che eseguono applicazioni vulnerabili e lo sfruttamento del problema non richiede l’autenticazione. Il difetto è valutato con la gravità massima di 10 sulla scala CVSS.

“Un utente malintenzionato che può controllare i messaggi di registro o i parametri dei messaggi di registro può eseguire codice arbitrario caricato dai server LDAP quando è abilitata la sostituzione della ricerca dei messaggi”, hanno affermato gli sviluppatori di Apache. “Dalla versione log4j 2.15.0 questo comportamento è stato disabilitato per impostazione predefinita.”

Ciò significa generalmente che se un utente può generare una richiesta che include input appositamente predisposti e tale richiesta viene registrata tramite Log4j, la vulnerabilità potrebbe essere sfruttata. Poiché la maggior parte delle applicazioni è progettata per accettare l’input dell’utente in vari modi, lo sfruttamento è un gioco da ragazzi.

Gli sviluppatori attribuiscono il merito a Chen Zhaojun del Cloud Security Team di Alibaba di aver originariamente segnalato il problema a novembre. Sulla base dei commenti degli sviluppatori nel bug tracker, il rilascio di una versione con patch è stato ritardato perché i ricercatori hanno trovato un modo per aggirare la correzione inizialmente proposta e ciò ha richiesto ulteriore lavoro e e nuovi processi di revisione.

Impatto duraturo

La vulnerabilità non riguarda solo le applicazioni e i servizi basati su Java che utilizzano direttamente la libreria, ma anche molti altri componenti Java popolari e framework di sviluppo che si basano su di essa, inclusi Apache Struts2, Apache Solr, Apache Druid, Apache Flink, ElasticSearch, Apache Kafka e molti altri.

La comunità sta ancora lavorando per valutare la superficie di attacco, ma è probabile che sia enorme a causa del complesso ecosistema di dipendenze. Alcuni dei componenti interessati sono estremamente popolari e vengono utilizzati da milioni di applicazioni e servizi aziendali.

I servizi gestiti da Apple, Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu e altri sono stati segnalati come vulnerabili. “Mi aspetto che tutto ciò avrà un impatto duraturo” ha affermato Chris Wysopal, CTO della società di sicurezza delle applicazioni Veracode. “Potrebbero esserci applicazioni su cui avete una buona visibilità e che potete rintracciare piuttosto rapidamente, ma è difficile trovare tutte le vostre applicazioni Java. L’altra sfida è ovviamente rappresentata dalle applicazioni dei fornitori scritte in Java. Molti software pacchettizzati usano infatti Java, quindi mi aspetto che molti chiederanno ai loro fornitori quando le patcheranno”.

È probabile che le aziende saranno impegnate per mesi a inseguire e applicare patch alle applicazioni vulnerabili. Sfortunatamente, non riuscire a correggere tempestivamente i difetti attivamente sfruttati può portare a gravi violazioni. La principale violazione di Equifax del 2017 è stata il risultato della mancata correzione di una vulnerabilità Struts2 sfruttata attivamente per 2 mesi in un’applicazione pubblica.

Gli aggressori stanno già scansionando Internet alla ricerca di applicazioni e servizi che potrebbero essere vulnerabili al CVE-2021-44228 e il servizio di monitoraggio del traffico GreyNoise sta segnalando che il numero di tentativi di sfruttamento sta aumentando.

Che rimedi attuare?

Ci sono alcuni casi in cui gli exploit attuali potrebbero non funzionare anche se Log4j è vulnerabile, ad esempio se il sistema host utilizza una versione di Java superiore a 6u212, 7u202, 8u192 o 11.0.2. Questo perché queste versioni hanno aggiunto una protezione migliorata per il caricamento di classi remote JNDI (Java Naming and Directory Interface), che è necessario affinché l’exploit funzioni.

Inoltre, nelle versioni di log4j successive alla 2.10, il problema può essere mitigato impostando la proprietà di sistema formatMsgNoLookups su true, impostando il parametro JVM -Dlog4j2.formatMsgNoLookups=true o rimuovendo la classe JndiLookup dal classpath.

Tuttavia, la soluzione migliore è aggiornare a log4j 2.15.0 perché qualcuno potrebbe trovare un percorso alternativo per raggiungere il codice vulnerabile che non si basa su JNDI. Se ciò accadesse, le mitigazioni proposte che si basano sulla limitazione di JNDI diventerebbero inefficaci.