Log4Shell: Identificare tentativi di exploit e mitigare i rischi

In queste due righe giusto qualche osservazione per capire come comportarsi con Log4Shell, non ho potuto essere più tempestivo poiché sono stato gli ultimi giorni a lavorare proprio su questa vulnerabilità, anzi se hai necessità contattaci.

Log4Shell è la vulnerabilità 0-day CVE-2021-44228 che affligge la diffusissima libreria java Log4j sviluppata dalla Apache Software Foundation.

A differenza di quanto ho letto da più parti, NON ha nulla a che fare con i WebServer Apache ma è un problema delle applicazioni JAVA, log4j è una libreria sviluppata dalla Apache Software Foundation ed è presente in buona parte delle applicazioni java, in molte delle quali è stata installata indirettamente perché dipendenza necessaria ad altra roba ed infatti uno dei problemi di questa vulnerabilità è la difficoltà di capire se si è esposti o meno. Molte macchine eseguono log4j senza che gli amministratori lo sappiano.

Log4Shell è quindi una vulnerabilità 0-day molto seria perché riguarda un linguaggio molto diffuso quale il multipiattaforma JAVA e non è scontato sapere se sui propri server è in esecuzione o meno Log4j, ma soprattutto Log4Shell è una vulnerabilità molto pericolosa perché un server LDAP può eseguire dei comandi arbitrari sulla macchina compromessa.

Per maggiori dettagli su Log4Shell è possibile leggere l'analisi di Cloudflare su Log4J e volendo approfondire si può leggere la procedura dettagliata dell'utilizzo dell'Exploit 0-day Log4Shell.

Come spesso accade in queste situazioni in giro si legge di tutto e molti giornali online pubblicano notizie con titoloni clickbait catastrofistici. Log4Shell è sicuramente una vulnerabilità molto seria ma già ci sono delle patch per mitigare il problema e dei sistemi per mitigare l'accesso abusivo ed è bene prendere tempestivamente le adeguate contromisure poiché i bot hanno già iniziato a scansionare la rete alla ricerca di obiettivi vulnerabili.

Come identificare tentativi di sfruttamento di Log4Shell su server Linux

Per verificare se qualche bot ha scansionato un server Linux alla ricerca della vulnerabilità Log4Shell è come sempre possibile guardare i log di sistema.

Con il seguente comando è possibile cercare tentativi di exploit nei log recenti in /var/log:

sudo egrep -I -i -r '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+' /var/log

Con il seguente comando è possibile cercare tentativi di exploit offuscati nei log recenti in /var/log:

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):'" \;

Con il seguente comando è possibile cercare tentativi di exploit nei log logrotati e gzippati recenti in /var/log:

sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+'

Con il seguente comando è possibile cercare tentativi di exploit offuscati nei log logrotati e gzippati recenti in /var/log:

sudo find /var/log/ -name '*.gz' -type f -exec sh -c "zcat {} | sed -e 's/\${lower://'g | tr -d '}' | egrep -i 'jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):'" \;

Qui è possibile reperire altre informazioni utili.

Guardando nei log si troveranno quasi sicuramente dei tentativi di intrusione e ciò significa che si deve immediatamente correre ai ripari, occorre quindi capire se i propri servizi sono vulnerabili a Log4Shell ed eventualmente occorre intervenire immediatamente per mitigare i rischi.

Come capire se si è vulnerabili a Log4Shell

Se non fosse abbastanza chiaro è importante tener presente che questa vulnerabilità interessa le infrastrutture lato server, e non client.

Come prima cosa è importante sottolineare che le versioni di Log4j interessate da questa vulnerabilità sono le versioni dalla 2.0-beta-9 alla 2.14.1. Le versioni 1.x di Log4j non hanno alcun meccanismo di JNDI lookup e quindi non soffrono di questa vulnerabilità, Log4j 1.2.17 non è più comunque manutenuta poiché fuori supporto e quindi questo porta tutta un'altra serie di implicazioni relative alla sicurezza.

Avendo ben chiaro quali sono le versioni di Log4j vulnerabili è di conseguenza palese che è a rischio qualsiasi infrastruttura esegua un software che utilizza una di queste librerie e l'individuazione di questi software non è proprio semplice ed immediata a causa delle dipendenze innestate di Java, è probabile quindi che si stia usando una delle librerie incriminate senza nemmeno esserne a conoscenza.

Se su un sistema si utilizza del software Java, data l'alta diffusione di Log4j, conviene sempre effettuare tutte le verifiche del caso perché molto probabilmente si è vulnerabili.

Per capire con certezza se si è vulnerabili occorre quindi effettuare un'analisi sui sistemi.

Se non si ha piena cognizione del software che gira su un sistema, se si è quindi in dubbio sul fatto che possa essere in esecuzione un software Java vulnerabile, allora è possibile utilizzare Syft e Grype per effettuare una scansione del sistema alla ricerca della libreria Log4j.

Volendo si può anche ricorrere al portale Huntress Log4Shell Vulnerability Tester che offre un sistema semplice e veloce per l'analisi remota dei sistemi.

Se invece si ha conoscenza degli applicativi Java in esecuzione su un server ma si hanno dubbi sul fatto che questi applicativi possano utilizzare o meno Log4j è allora possibile effettuare un'analisi abbastanza semplice su di essi esplodendoli e cercando in essi eventuali riferimenti alla libreria incriminata.

Nel dettaglio un qualsiasi .jar può essere unzippato e quindi basta cercare in esso eventuali riferimenti a Log4J per capire se è vulnerabile o meno.

Ipotizziamo ad esempio di avere il software java pincopallo.jar, la prima cosa da fare è unzipparlo:

unzip pincopallo.jar -d /tmp/pincopallo

in modo da poter cercare in esso eventuali librerie log4j:

find /tmp/pincopallo/ -name *log4j*

o eventuali riferimenti alle librerie log4j:

grep -rnw '/tmp/pincopallo' -e 'log4j'

che molto probabilmente saranno nel percorso /tmp/pincopallo/META-INF/.

Se si continuano avere dubbi sulla presenza della libreria Log4j nei software in uso è allora bene chiede agli sviluppatori o ai vendor.

Come mitigare i rischi della vulnerabilità Log4Shell

Dopo aver capito come individuare eventuali tentativi di exploit e come analizzare se si è vulnerabili vediamo cosa fare per mitigare i rischi.

Sembra banale ma la cosa migliore da fare per annullare i rischi è aggiornare i propri software alle versioni che utilizzano una delle nuove librerie Log4j rilasciate da Apache in questi giorni, l versione Log4j 2.15.0 oppure la nuovissima Log4j 2.16.0 dove è ora disabilitato di default JNDI.

Qualora non dovesse essere possibile aggiornare i propri software con delle versioni sicure è allora necessario mettere in atto delle misure per mitigare i rischi:

• Aggiornare JDK ad una delle seguenti versioni: 8u191, 7u201, 6u211, 11.0+
• Aggiungere il parametro di avvio -Dlog4j2.formatMsgNoLookups=true agli argomenti JVM
• Impostare la variabile d'ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS=true;
• Rimuovere JndiLookup.class da ogni log4j-core-*.jar presente sul sistema col seguente comando (qui maggiori dettagli):

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

I sistemi già compromessi da Log4Shell posso utilizzare Logout4Shell.

Qui e qui due elenchi in continuo aggiornamento di softwares vulnerabili a Log4Shell.

Log4Shell è una vulnerabilità molto seria ma non è la prima vulnerabilità 0-day né sarà l'ultima e come sempre in questi casi la cosa principale è agire tempestivamente, se hai necessità di un intervento per prevenire danni da Log4Shell contattaci.