Apache Log4j è una piattaforma di log basata su Java che può essere utilizzata per analizzare file di log dei server web e delle singole applicazioni.
Sebbene non sia presente di default in un normale stack LAMP, il software è molto usato nelle imprese, nelle piattaforme di ecommerce e nei giochi come Minecraft i cui sviluppatori si sono affrettati ad applicare una patch correttiva.
Nelle scorse ore è stato pubblicato il codice exploit, battezzato Log4Shell, che può portare all’esecuzione di istruzioni arbitrarie, quindi potenzialmente nocive, su qualunque sistema vulnerabile.
Se da un lato Apache ha provveduto a rilasciare molto rapidamente Log4j 2.15.0, versione dell’applicazione che risolve il problema di sicurezza, sono tante le aziende che rimangono attaccabili con un’aggressione che viene definita molto semplice da porre in essere.
Basti pensare che per iniettare codice nocivo è sufficiente che un utente malintenzionato modifichi la stringa user agent del suo browser (Google ha annunciato che Chrome metterà da parte la stringa user agent).
Nel giro di poco tempo criminali informatici di tutto il mondo hanno iniziato a effettuare una scansione della rete alla ricerca di server vulnerabili che utilizzano Log4j con il preciso intento di diffondere malware o cryptominer, rubare dati sensibili e assumere il controllo del sistema remoto. In molti casi i sistemi vulnerabili vengono aggiunti alle note botnet Mirai e Muhstik.
Le botnet vengono utilizzate per installare malware su larga scala utilizzando le indicazioni ricevute da un server command and control oppure per lanciare attacchi DDoS.
I ricercatori del Microsoft Threat Intelligence Center riferiscono che la falla scoperta in Log4j viene utilizzata anche per la diffusione di Cobalt Strike, di per sé un software per il penetration testing assolutamente legittimo che però può essere sfruttato anche dai criminali informatici per monitorare le reti altrui ed eseguire comandi da remoto.
Molti altri attacchi si stanno via via aggiungendo perché per gli aggressori la falla scoperta in Log4j è un’opportunità troppo ghiotta per farsi largo nelle infrastrutture aziendali di terzi.
Per chi utilizza Log4j il miglior modo per scongiurare qualunque rischio di attacco consiste nell’aggiornare alla versione 2.15.0 o successiva. Nella versione 2.10 e seguenti si può impostare la proprietà di sistema log4j2.formatMsgNoLookups
a true o rimuovere la classe JndiLookup
dal “classpath”.
Se il server utilizza le runtime Java 8u121 e seguenti per impostazione predefinita le impostazioni che possono mostrare il fianco ad eventuali attacchi sono regolate su false mitigando i rischi.
Se non utilizzate Java sui server aziendali e non fate uso di framework a loro volta basati su Java non c’è bisogno di applicare alcun tipo di intervento.
Sui sistemi Linux si possono cercare eventuali occorrenze di Log4j tra i file presenti sul sistema digitando il comando seguente locate log4jgrep -v log4js
. Ovviamente il comando locate
deve essere presente sulla macchina in uso.
Segnaliamo inoltre due strumenti opensource sviluppati da Anchore che permettono di esaminare le dipendenze dei pacchetti software installati sulla macchina alla ricerca di eventuali riferimenti a Log4j.
I due tool (Syft e Grype) sono reperibili in questa pagina GitHub e hanno il grande vantaggio di esaminare il contenuto dei file JAR, compresi quelli “nidificati”.
Ulteriori informazioni possono essere trovate nella pagina GitHub che Cybereason ha creato per il suo strumento utile a proteggere i sistemi vulnerabili.