E’ stata scoperta una vulnerabilità “Zero-day” (LOG4SHell) nella popolare libreria di logging per Java log4j2 che si traduce in Remote Code Execution (RCE) registrando una determinata stringa.
Log4j2 è un framework di logging open source basato su Java comunemente incorporato nei server Web Apache e nelle applicazioni Web Spring-Boot. E di fatto utilizzato come strumento di logging in miriadi di applicazioni java che quotidianamente utilizziamo.
Volendo citare qualche progetto “noto” possiamo tirare in ballo il Rover Mars della NASA, Minecraft, una dozzina di applicativi Cisco, Apple iCloud e le auto di Tesla… Potremmo continuare per ore, la lista sarebbe davvero troppo lunga, ma credo sia sufficiente per comprendere l’entità del “danno“.
La vulnerabilità è stata segnalata con CVE-2021-44228 contro il jar log4j-core ed è stata classificata come “difetto critico”, le è stato assegnato un punteggio CVSS di base di livello 10, ovvero il più alto livello di gravità possibile.
Come già detto, molti servizi sono vulnerabili a questo exploit poiché log4j è un’utility di registrazione basata su Java e largamente utilizzata dalle community di sviluppo.
Chiunque utilizzi i servizi di framework Apache o qualsiasi applicazione di framework basata su ava SpringBoot utilizza log4j2 è probabile che sia vulnerabile.
L’exploit funziona quando c’è un servizio o un’applicazione in esecuzione con una versione vulnerabile di log4j2.
L’attaccante che può controllare i messaggi di registro o i parametri dei messaggi di registro può eseguire codice arbitrario sul server vulnerabile caricato dai server LDAP quando è abilitata la sostituzione della ricerca dei messaggi.
Versioni di Apache log4j2 affette dalla vulnerabilità
2.0 <= Apache log4j <= 2.14.1
Per porre rimedio a tale minaccia è necessario eseguire diversi step:
- Eseguire un comando search/grep su tutti i server per individuare qualsiasi file con il nome “log4j2“, quindi verificare se si tratta di una versione vulnerabile o meno
- Se la tua versione è vulnerabile allora devi aggiungere “
log4j.format.msg.nolookups=true” alla configurazione globale del tuo server/applicazione web - Per mitigare definitivamente il problema è stata rilasciata la versione 2.15.0 di log4j senza la vulnerabilità. log4j-core.jar è disponibile nella pagina Apache Log4j, puoi scaricarlo da questo link e aggiornare il tuo sistema.
Per un piacevolissimo approfondimento sull’argomento, sugli impatti che tale vulnerabilità può avere sull’intero mondo delle applicazioni java vi rimando al video di Matteo Flora, in cui la chiarissima spiegazione del prof. Stefano Zanero fugherà qualsiasi dubbio.
Aggiornamento 15.12.2021 – rilasciata versione 2.16.0
Ebbene, la patch rilasciata tempestivamente da Apache Foundation per risolvere la vulnerabilità riscontrata in log4j2.x+, log4j 2.15.0, sia a sua volta affetta da una vulnerabilità CVE-2021-45046 come per altro dichiarato dalla stessa Apache Foundation.
E’ pertanto necessario eseguire l’aggiornamento alla versione 2.16.0 di log4j. Per il dettaglio sulle compatibilità dlele versioni per Java 7 e Java 8 vi rimando al link originale di Apache che trovate qui.
Intanto in rete circolano vignette satiriche e meme che mettono in dubbio le previste ferie natalizie dei devops e gli addetti ai lavori in generale.
Aggiornamento 18.12.2021 – rilasciata versione 2.17.0
Nemmeno il tempo di di completare i check sulla 2.16.0 che viene subito scoperta una nuova vulnerabilità, in realtà si tratta di una “nuova” falla introdotta nei tentativi di fixare le vulnerabilità scoperte in precedenza che hanno dato vita all’ormai noto #Log4Shell.
Nello specifico la vulnerabilità (CVE-2021-45105) introdotta sarebbe in grado di regenerate dei DoS (Denial of Service). Questo è quanto dichiarato dall’Apache Software Foundation nel suo comunicato che annuncia la release 2.17.0:
Le versioni da 2.0-alpha1 a 2.16.0 di Apache Log4j2 non proteggevano dalla ricorsione incontrollata delle ricerche autoreferenziali. Quando la configurazione della registrazione utilizza un layout di pattern non predefinito con una ricerca di contesto (ad esempio, $${ctx:loginId}), gli aggressori con il controllo sui dati di input di Thread Context Map (MDC) possono creare dati di input dannosi che contengono una ricerca ricorsiva, con conseguente StackOverflowError che terminerà il processo. Questo è anche noto come attacco DOS (Denial of Service).
Sono giorni di grande fermento per Log4j e per qualche milione di di “addetti ai lavori”, siamo alla terza versione in meno di una settimana e c’è già chi è pronto a scommettere che anche questa versione non durerà per molto.
Aggiornamento 29.12.2021 – rilasciata versione 2.17.1
Apache Software Foundation ha rilasciato una nuova versione della popolare libreria per il logging. Si tratta di Log4j 2.17.1 per risolvere un difetto di esecuzione del codice arbitrario scoperto di recente, tracciato come CVE-2021-44832, che insiste sulla versione 2.17.0.
CVE-2021-44832 è la quinta vulnerabilità scoperta nelle ultime settimane. Come i problemi rilevati nelle versioni precedenti, anche questa vulnerabilità potrebbe essere sfruttata dagli attaccanti per eseguire codice dannoso sui sistemi attaccati.
Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
La vulnerabilità ha ricevuto un punteggio CVSS di 6.6 e ha un impatto su tutte le versioni di log4j da 2.0-alpha7 a 2.17.0. mentre le versioni 2.3.2 e 2.12.4. non ne sono influenzate.
La vulnerabilità è stata scoperta da Checkmarx Yaniv Nizry, un ricercatore di sicurezza informatica, che l’ha prontamente segnalata ad Apache lo scorso 27 dicembre.