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.
Per capire l’entità della vulnerabilità, osserva CybergOn in una nota, 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 e tra le aziende che sono state colpite vi sono Amazon, Apache, Apple, CloudFlare, Tencent, Tesla, Twitter, VMWare.
La lista dinamica dei servizi e delle applicazioni che utilizzano Log4j
Ma 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.
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.
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.
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.
Aggiornamento di nuove policy
Effettuare l’aggiornamento sia lato detection (firme IDS) sia lato prevention (IPS), in caso di pubblicazione di nuovi IoC.
Patch
Nel caso in cui non sia ancora stato fatto il 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.
Come funziona l’attacco che sfrutta Log4j
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 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.
Nella seconda fase “attacker.com” fornisce in riposta un oggettp Java, con codice arbitrario, e il server vulnerabile lo esegue.
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à.
