Vulnerabilità Apache Log4j: le 5 cose da fare

Il 9 dicembre è stata resa pubblica una vulnerabilità (CVE-2021-44228) che coinvolge la libreria Java Apache Log4j, largamente utilizzata a livello mondiale.

La vulnerabilità di livello critico, a cui è stato assegnato il punteggio massimo (CVSSv3: 10), permette la Remote Code Execution (RCE) senza autenticazione, consentendo all’attaccante l’esecuzione di codice arbitrario a danno dell’applicazione affetta.

Tale vulnerabilità è stata soprannominata Log4Shell ed interessa le versioni dalla 2.0-beta 9 alla 2.14.1 della libreria.

Chi è stato o potrebbe essere colpito

Per capire l’entità della vulnerabilità basti pensare che Java viene usato in oltre 3.5 miliardi di siti web e Log4j è una delle librerie più usate per il logging.

Anche Ingenuity, l’elicottero della NASA atterrato sul suolo di Marte lo scorso febbraio, usa Log4j nel proprio software, come la stessa Apache ha reso noto sul proprio account Twitter. Altre aziende che sono state colpite sono:

• Apple
• Tencent
• Twitter
• CloudFlare
• Amazon
• Tesla
• Apache
• Redis
• VMWare

Una lista, in continuo aggiornamento, dei servizi e delle applicazioni che utilizzano Log4j è invece consultabile cliccando qui.

Le grandi aziende non sono le sole ad essere impattate: la vulnerabilità, infatti, riguarda anche il singolo utente. Se gli attaccanti colpiscono l’azienda, anche chi usufruisce dei servizi di quell’azienda potrebbe veder compromessi i propri dati personali.

5 cose da fare

Se da un lato Apache ha provveduto a rilasciare la versione Log4j 2.15.0 per risolvere il problema di sicurezza, dall’altro sono tante le aziende che rimangono facilmente attaccabili.

Sui nostri clienti a servizio sono state eseguite le seguenti analisi, che consigliamo di effettuare:

1. OSINT del perimetro pubblico:

Utilizzando tool esterni (ad esempio, Shodan) si possono valutare le esposizioni dei propri IP pubblici. È necessario poi bloccare sull’IPS o sul firewall tutte le connessioni da e verso gli indirizzi IP segnalati come IoC.

2. Scansione del perimetro interno:

Questo può essere effettuato tramite un vulnerability assessment puntuale sugli applicativi e sui sistemi. La verifica va fatta non solo su perimetro esterno ed interno, ma anche su tutti i servizi cloud. Anche in questo caso si può provvedere a isolare le macchine vulnerabili.

3. Detection sulla rete:

Tramite IDS e tramite l’analisi e correlazione dei logs di sistema e applicativi, un team di specialisti può individuare tempestivamente i tentativi di compromissione dei sistemi aziendali e prevenire o limitare i danni.

4. Aggiornamento di nuove policy:

Consigliamo di effettuare l’aggiornamento sia lato detection (firme IDS) sia lato prevention (IPS), in caso di pubblicazione di nuovi IoC.

5. Patch:

Nel caso in cui non sia ancora stato fatto, il nostro consiglio è quello di installare Log4j 2 nella versione 2.15.0 rilasciata da Apache. Un’ulteriore vulnerabilità, meno impattante della Log4Shell, è uscita ieri; pertanto può essere applicata direttamente la patch 2.16.0 che risolve anche quest’ultima. Nel caso l’attività di patching non fosse possibile, si può ridurre la superficie di attacco tramite le azioni di mitigation consigliate da Log4j qui.

Le organizzazioni con applicazioni web e non basate su Java dovrebbero valutare di contattare i fornitori o assicurarsi di aver eseguito l’ultima versione disponibile delle applicazioni in uso.

In caso di compromissione o per effettuare vulnerability assessment su perimetro pubblico e interno, può essere fatta una richiesta al nostro SOC, scrivendo una mail a sos@cybergon.com.

Come funziona l’attacco che sfrutta Log4j

Già il 24 novembre 2021, Chen Zhaojun, del team Alibaba Cloud Security, aveva dato comunicazione della vulnerabilità Log4Shell; l’exploit in the wild della stessa è, tuttavia, iniziato alcuni giorni dopo.

L’attacco può essere diviso in due diverse fasi.

Nella prima l’attaccante manda una richiesta ad un server vulnerabile con un campo, in questo caso User-Agent, che sa o che ipotizza che verrà passato dal server stesso a Log4j.

Log4j riceve la stringa passata dall’attaccante e contatta “attacker.com” tramite JNDI (Java Naming and Directory Interface).

Img source: fastly.com

Nella seconda fase “attacker.com” fornisce in risposta un oggetto Java, con codice arbitrario, e il server vulnerabile lo esegue.

Img source: fastly.com

Nonostante l’attacco possa sembrare relativamente semplice, questa vulnerabilità risulta complessa da gestire: la difficoltà sta nel capire se nello sviluppo dei propri software è stato utilizzato Log4j e in che versione.

La pericolosità di Log4Shell non riguarda solo il fatto che gli attaccanti possono avere il controllo del sistema, ma piuttosto si concentra sulla facilità con cui esperti e non traggono vantaggio sfruttando questa vulnerabilità.