Apache log4j è una libreria Java, ora parte del progetto log4j della Apache Software Foundation, uno dei possibili tool per la gestione dei log in ambiente. Largamente utilizzata in molte applicazioni Java, negli anni il suo sviluppo è stato rallentato ed è divenuta difficile da manutenere a causa della necessità di restare retrocompatibile con versioni molto vecchie di Java. Ha terminato il proprio ciclo di vita nell’agosto 2015 in favore del nuovo progetto log4j 2, purtroppo nonostante questo è ancora implementata in moltissime applicazioni. Ma a che serve questa ormai tristemente celebre libreria? Una qualunque applicazione Java necessita di scrivere un log. Al crescere della complessità dell’applicazione, la quantità di messaggi scritti in uno o più log diventa pure complessa. Nel caso limite, possono insorgere problemi di prestazioni dovuti all’accumularsi di un numero di messaggi eccessivo. Log4j e gli altri possibili tool servono a meglio organizzare questo lavoro.
Già in Aprile è stata pubblicata una Proof of Concept che permetteva l’exploit di questa vulnerabilità. Purtroppo, dato che era stata rilasciata in lingua cinese, era riuscita a passare indisturbata sotto i radar della comunità InfoSec. La vulnerabilità, che purtroppo affligge anche la versione 2 di log4j, è stata registrata come cve-2021-44228. Sfruttando questo tallone di Achille, tutte le macchine virtuali che girano sotto VM Ware non sono più al sicuro, in questo caso particolare si parla di VMSA-2021-0028.
Questo exploit in log4j porta alla possibilità per un attaccante di poter eseguire arbitrariamente del codice (RCE, remote code execution) anche da remoto più o meno dappertutto: iCloud, Twitter, Steam, CloudFlare, Amazon, Tesla, Baidu, Tencent… tanto per nominare le aziende più rinomate. Tant’è che da alcuni analisti che ne hanno descritto la superficie d’attacco è stato definito come il più devastante 0-day RCE della storia dell’informatica.
A partire dalla versione 2.15.0 della libreria, la vulnerabilità è stata eliminata. Per scoprire se i tuoi sistemi sono vulnerabili esiste uno script in grado di eseguire il controllo.
Se non è possibile fare l’aggiornamento ad una versione sicura, i ricercatori di randori hanno pubblicato una guida per la mitigazione temporanea della vulnerabilità da eseguire immediatamente e raccomandano caldamente di monitorare strettamente le applicazioni impattate per ogni comportamento anomalo:
Innanzitutto, all’avvio della Java Virtual Machine, bisogna impostare come true questo parametro:
| log4j2.formatMsgNoLookups; |
La presenza di files JAR che appartengono a log4j può indicare che l’applicazione sia potenzialmente suscettibile a CVE-2021-44228. Nello specifico, i files da ricercare devono combaciare con questo pattern:
| log4j-core-*.jar; |
A seconda del tipo d’installazione, l’ubicazionedei files JAR corrispondenti può dare indicazioni su quali applicazioni debbano essere considerate vulnerabili. Ad esempio, in un sistema Windows, se il file si trova nella cartella C:\Program Files\ApplicationName\log4j-core-version.jar ciò indica che ApplicationName debba essere controllata accuratamente. Se si usa un sistema unix, con il comando lsof si può verificare quali processi abbiano il file JAR in uso, tramite questa sintassi:
| lsof /path/to/log4j-core-version.jar; |
