Sono oltre 4.300.000 i tentativi di exploit della vulnerabilità Log4Shell bloccati da Check Point Research (CPR) al 20 dicembre. Di questi, più del 46% sono opera di gruppi noti. I tentativi di sfruttamento della falla interessano oltre il 48% delle reti aziendali a livello globale. Solo in Italia è coinvolto il 54% delle aziende. A questi dati sorprendenti si affianca quello della distribuzione geografica degli attacchi: al 20 dicembre erano oltre 90 in tutte le regioni. In alcuni casi sono stati raggiunti picchi che vedono oltre il 60% delle reti aziendali colpite, e molte distribuzioni che vedono oltre il 50% delle reti aziendali all'interno del Paese stesso.

Nuovo malware

Oltre agli sfruttamenti già noti, l’azienda di cybersecurity Cryptolaemus ha allertato circa il fatto che gli attaccanti ora sfruttano Log4Shell anche per infettare i dispositivi vulnerabili Windows con il trojan bancario Dridex e quelli Linux con Linux con Meterpreter. Originariamente sviluppato per rubare le credenziali bancarie online dalle vittime, Dridex nel tempo si è evoluto ed è impiegato come loader che scarica vari moduli. Viene usato per eseguire diversi tipi di attacchi: dall'installazione di payload aggiuntivi ai movimenti laterali, per arrivare all'attivazione di attacchi ransomware BitPaymer, DoppelPaymer, e altri.

https://twitter.com/Cryptolaemus1/status/1472939659760185346?s=20

La detection

Jonathan Tanner, Senior Security Researcher di Barracuda ha condiviso alcune considerazioni importanti sui modi in cui le aziende possono verificare la propria esposizione alla vulnerabilità Log4Shell. La prima cosa da controllare è se viene usata una qualsiasi versione di log4j precedente la 2.15.0, dipendenze incluse.

Anche qualora fosse installata la versione 2.15.0 o successive andrebbe comunque verificato che la proprietà di sistema formatMsgNoLookups non sia impostata su True, dato che questa versione non è vulnerabile quando il valore di default passa da True a False. In alcune versioni di log4j, per mitigare la vulnerabilità, questa proprietà può essere impostata manualmente su False.

Se l’applicazione non richiede LDAP per il suo legittimo utilizzo è anche possibile bloccare tutto il traffico LDAP con un firewall o un Web Application Filter per prevenire che venga raggiunto il codice remoto nel caso in cui la vulnerabilità venga sfruttata.

Queste operazioni però controllano solo se Log4j è in grado o meno di utilizzare la vulnerabilità RCE. Che il sistema sia o no veramente vulnerabile a un attacco è una questione molto più complicata in assenza di un test simile a quello per la vulnerabilità HeartBleed. Per sfruttare questa vulnerabilità il cybercriminale dovrebbe eseguire un attacco log injection. Riconoscerlo è un processo molto complicato, ma essenzialmente ovunque venga registrato l'input di un utente (o potenziale intruso) potrebbe essere vulnerabile a questo exploit.

Pertanto, eseguire un test per un RCE vorrebbe dire trovare il modo di fare una richiesta JNDI LDAP all’interno del log dal contesto dell’utente (ad esempio mediante un sito web o delle API se l’applicazione potenzialmente colpita è un’applicazione web).

Poiché questa vulnerabilità permette la Remote Code Execution, il rischio è alto nel caso in cui la vulnerabilità sia presente. Un criminale potrebbe ottenere l’accesso alla rete e da qui cercare di accedere a dati e risorse critiche.

Il ruolo dell’open source

Tanner ha inoltre pubblicato un commento interessante sul ruolo dell’open source, che questa vicenda ha portato in primo piano con una accezione negativa. È importante sapere che in generale, ogni software può essere vulnerabile agli attacchi. Spesso il software open source più diffuso può contare su un vasto ecosistema di sviluppatori alla ricerca di eventuali vulnerabilità.

Se da un lato è vero che il software open source fa notizia quando si trovano importanti buchi della sicurezza, non significa che sia meno sicuro (e in effetti è assai probabile che sia molto più sicuro di un codice proprietario o di librerie meno popolari). L’uso diffuso semplicemente aumenta la probabilità che queste vulnerabilità siano individuate, non necessariamente che esse esistano.

Quando utilizzano librerie open source, le aziende dovrebbero privilegiare grandi progetti, adeguatamente manutenuti e di buona reputazione, come log4j, per le ragioni già viste. Ovviamente, è comunque sempre possibile che ci siano delle vulnerabilità, ma è anche più probabile che la comunità le trovi e produca le patch, oltre che verifichi che il codice sia privo di bug che potrebbero creare vulnerabilità.

La catena di infezione

I tool di supporto

La diffusione di Log4j e la difficoltà di rintracciare ogni possibile asset compromesso o a rischio hanno spinto molte aziende di cyber security e pubblicare, talvolta anche a titolo gratuito, dei tool che possono essere di supporto per la detection. Le funzionalità di scansione offerte dalle applicazioni web sono essenziali per rilevare queste vulnerabilità.

Come ricorda Alessio Mercuri, Security Engineer di Vectra AI, Log4j rappresenta una porta aperta e privata di serratura che permette agli attaccanti di penetrare nei sistemi dell’organizzazione e di riscattarli. La prevenzione e la riduzione della superficie d’attacco esposta sarà un obiettivo raggiungibile solo a lungo termine, il focus attuale è rilevare velocemente i tentativi di attacco che sono andati a buon fine, ovvero un host compromesso all’interno della nostra infrastruttura.

Check Point Software Technologies ha pubblicato un AppSec gratuito di 30 giorni e protezione a vita gratuita contro gli exploit Log4j: si trova a questo indirizzo.

Trend Micro ha creato uno strumento di scansione rapido basato sul web per identificare le applicazioni server che potrebbero essere interessate da Log4Shell. Si può trovare a questo link.

Qualys ha reso disponibile gratuitamente per 30 giorni la propria soluzione Web Application Scanning (WAS), che analizza le applicazioni web e le API in merito alla vulnerabilità Log4Shell, per aiutare le aziende a proteggersi da Log4Shell. Si può attivare questo link. WAS utilizza payload appositamente creati per simulare lo stesso modello di attacco utilizzato dai cybercriminali. I siti vulnerabili vengono rapidamente e facilmente identificati per le opportune attività di remediation, chiudendo la porta agli aggressori prima ancora che gli utenti si accorgano di essere stati esposti.

Vectra AI ha pubblicato Vectra Cognito Detect, che evidenzia gli host con un comportamento sospetto osservando il traffico di rete e utilizzando l’apprendimento automatico e l’Intelligenza Artificiale per classificare il traffico. Grazie all’AI svolge un’attività di analisi comportamentale e individua i movimenti sospetti all’interno dell’infrastruttura IT.

È inoltre possibile identificare i tentativi di sfruttamento della vulnerabilità da parte degli attaccanti attraverso Vectra Cognito Recall, che crea un record completo dell’attività di rete e permette quindi di cercare segni di sfruttamento della minaccia nell’attività di rete. Vectra ha pubblicato e distribuito una query personalizzata in Recall, che può anche essere utilizzata come trigger di rilevamento per identificare ogni tentativo di sfruttamento in tempo reale. Questo può essere un contesto utile per gli analisti. In questo modo ogni tentativo di sfruttamento può essere catturato.