È di nuovo allerta per una seconda vulnerabilità (CVE-2021-45046) scoperta nella libreria Java Log4j, dopo che la scorsa settimana la Apache Foundation aveva già rilasciato la versione 2.15 della sua utility di logging per affrontare la famigerata vulnerabilità Log4Shell (CVE-2021-44228) che consente di attaccare server e applicazioni basati su Java, da remoto, esponendo oltre 3 miliardi di dispositivi in tutto il mondo.
Tuttavia, questo aggiornamento ha risolto solo parzialmente la vulnerabilità. Nella versione 2.15 di Log4j, infatti, solo un aspetto della funzionalità di recupero dei log mediante il tag JNDI (Java Naming and Directory Interface) era disabilitato per impostazione predefinita.
Ricordiamo che JDNI è un’API utilizzata da Log4j per recuperare oggetti da server remoti da utilizzare nei record dei log.
La Apache Foundation ha quindi rilasciato una seconda correzione della libreria Log4j, ora disponibile in versione 2.16, che disabilita tutto il supporto JNDI per impostazione predefinita e rimuove completamente la gestione della ricerca dei messaggi.
Vulnerabilità Log4Shell: tutti i dettagli e come mitigare il rischio
Indice degli argomenti
Perché la patch per Log4Shell non basta a mitigare il rischio
Il rilascio del secondo aggiornamento si è reso necessario perché la versione 2.15 può ancora essere sfruttata in determinate configurazioni non di fabbrica.
A causa di ciò, lo sfruttamento della nuova vulnerabilità CVE-2021-45046 (alla quale è stato assegnato un grado di rischiosità più basso della precedente del valore di 3.7 su 10 sulla scala CVSS) potrebbe consentire a un attaccante remoto di sfruttare il modulo JNDI Lookup per eseguire un attacco Denial of Service (DoS) con l’obiettivo di infiltrarsi nei sistemi esposti e prenderne il controllo.
Apache ha riconosciuto che JNDI “ha seri problemi di sicurezza”, quindi è stata presa la decisione di disabilitarlo per impostazione predefinita.
“CVE-2021-44228 ci ha mostrato che JNDI ha seri problemi di sicurezza. Sebbene abbiamo eliminato ciò che sapevamo, è stato deciso di disabilitarlo completamente per impostazione predefinita per una maggiore sicurezza dell’utente, soprattutto perché la maggior parte delle persone lo utilizza molto di rado”, ha affermato Apache.
Pertanto, nella versione 2.16.0 JNDI è disabilitato.
Problemi di sicurezza anche per le vecchie versioni di log4j
Altro problema emerso è anche CVE-2021-4104, che affligge le versioni 1.x della libreria log4j (con punteggio 6.6 su 10), anche se è giusto ribadirlo questo problema preoccupa meno in quanto le versioni 1.x sono meno utilizzate perché decisamente obsolete, ma non si può escludere che ci siano vecchi applicativi ancora in uso, che le sfrutta.
Questa vulnerabilità è perfettamente legata alla seconda appena scoperta nella libreria Java, ma non riceverà mai una patch perché le versioni 1.x non sono più supportate dal team Apache.
Ad ogni modo, per quei sistemi che ancora oggi sono costretti ad adoperare questa versione di log4j, è possibile mitigare il rischio con questa soluzione:
- commentare o rimuovere JMSAppender nella configurazione log4j, se utilizzato;
- rimuovere la classe JMSAppender dal classpath. Per esempio così: zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class;
- limitare l’accesso per l’utente del sistema operativo sulla piattaforma che esegue l’applicazione per impedire la modifica della configurazione di Log4j da parte dell’attaccante (terzo).
Cosa impariamo dalle vulnerabilità in log4j
Quindi abbiamo imparato in meno di una settimana che i problemi noti con log4j sono ormai tre. Due dedicati alle versioni 2.x, attualmente maggiormente in produzione e uno, forse meno comune, che riguarda le versioni 1.x.
Con JNDI abilitato, gli aggressori possono forzare l’utility log4j a estrarre il codice Java da un server sotto il suo controllo ed eseguirlo, compromettendo il dispositivo. Per fare ciò, gli aggressori devono inserire un testo appositamente predisposto, ad esempio, nel nome di un account dell’applicazione o in una query di ricerca su un sito il cui server utilizza questo sistema. Quando viene registrato da log4j, questo attiverà l’esecuzione del codice remoto.
Il Java Naming and Directory Interface (JNDI) è un insieme di API Java organizzate come un servizio di directory che consente ai client Java di aprire e visualizzare dati e oggetti per nome.
Come qualsiasi altra API Java, un insieme di interfacce, JNDI è indipendente dall’implementazione sottostante.
Oltre a ciò, fornisce un’implementazione dell’interfaccia del provider di servizi (SPI) che consente di associare i servizi di directory a un framework.
