Nel mondo della cybersecurity, non c’è nessuno che non stia parlando, in questo momento, della vulnerabilità più grave di sempre. Log4j, una libreria di logging diffusa in moltissime applicazioni Java, che secondo i ricercatori di sicurezza potrebbe permettere agli attaccanti di eseguire codice malevolo e prendere il controllo dei sistemi. Trattandosi di una libreria estremante utilizzata dagli sviluppatori Java, e inclusa in molti software open source, risiede non soltanto su server e applicazioni aziendali, ma anche su smartphone, computer, quasi tutti i device in circolazione. Java come noto è utilizzato da almeno 3 miliardi di dispositivi: per questo in molti hanno cominciato a parlare di “Apocalisse informatica”.
Come è stata divulgata la notizia dello Zero-day
Il primo alert del CSIRT nazionale è arrivato il 10 dicembre: una stima di impatto elevata (GRAVE/ROSSO 77,36/100) per la vulnerabilità con gravità “critica” identificata dalla CVE-2021-44228, relativa al prodotto Apache Log4j, che apriva il rischio di Arbitrary Code Execution su codice Java.
L’alert consigliava di implementare tempestivamente le azioni di mitigazione fornite da Apache. Il 12 dicembre, il CSIRT forniva maggiori dettagli: Log4j è una libreria java-based utilizzata per fornire capacità di logging a strumenti ed applicazioni. “La vulnerabilità individuata (nome “Log4Shell”) risiede nel modulo di messaggistica e consente l’esecuzione di codice arbitrario da remoto sul server che utilizza la libreria portando alla completa compromissione dello stesso senza necessità di autenticazione”.
#Apache: rilasciato pubblicamente un Proof of Concept per lo sfruttamento della CVE-2021-44228 relativa al prodotto #Log4j
Rischio: 🔴
Tipologia: Arbitrary Code Execution
👉 Aggiornamenti e mitigazioni disponibili pic.twitter.com/vXPUuukNPP
— CSIRT Italia (@csirt_it) December 10, 2021
Quali scenari di attacco si aprono
Quello che si è scoperto è quindi che una vulnerabilità di Log4j può aprire la possibilità ad un attaccante esterno di far eseguire qualsiasi comando alla macchina su cui risiede il software. “La vulnerabilità di livello critico, a cui è assegnato il punteggio massimo (CVSSv3: 10) in quanto permette l’esecuzione di codice da remoto (RCE) senza autenticazione, è nota col nome Log4Shell ed interessa applicazioni Java-based che utilizzano il prodotto Log4j 2 dalla versione 2.0 fino alla 2.14.1” ha riportato il CSIRT.
È come dire: le porte sono aperte, entrate pure tutti. Già ci sono segnali di sfruttamento del bug. “In questo momento quello che vediamo è che gli attaccanti usano questa vulnerabilità per fare attività di mining di criptovalute” ha spiegato Marco Ramilli, amministratore delegato di Yoroi, all’Agenzia AGI.
Il mining di bitcoin – o malicious cryptomining o cryptojacking (un attacco conosciuto già da anni e ai primi posti nelle classifiche) – è un’attività che a insaputa degli utenti, sfrutta la capacità di calcolo e l’energia dei computer presi di mira. “Ma potrebbero fare qualsiasi cosa: entrare nei server di un’azienda, vedere quello che c’è dentro, rubare segreti industriali oppure decidere di sferrare degli attacchi ransomware per monetizzare il proprio controllo dei sistemi” ha aggiunto Ramilli, ammettendo di aver visto un attacco di questo tipo “circa cinque, otto volte negli ultimi 20 anni”.
Sean Gallagher, senior threat researcher di Sophos, ha dichiarato che dal 9 dicembre Sophos ha rilevato centinaia di migliaia di tentativi di eseguire codice da remoto utilizzando la vulnerabilità Log4Shell. Inizialmente, questi erano test di exploit Proof-of-Concept (PoC) da parte di ricercatori di sicurezza e potenziali cybercriminali, tra gli altri, così come molte scansioni online per la vulnerabilità. Questo è stato rapidamente seguito da tentativi di installare cryptominer, tra cui la botnet Kinsing.
Le informazioni più recenti suggeriscono che gli aggressori stiano cercando di sfruttare la vulnerabilità per esporre le chiavi utilizzate dagli account Amazon Web Service. Ci sono anche segni di cybercriminali che cercano di sfruttare la vulnerabilità per installare strumenti di accesso remoto nelle reti delle vittime, forse Cobalt Strike, uno strumento chiave in molti attacchi ransomware. Sophos prevede che gli avversari intensifichino e diversifichino i loro metodi di attacco nel corso dei prossimi giorni e settimane, sfruttandoli anche per attacchi ransomware.
Come uscire da un problema così ampio?
Agli amministratori di sistema va ora il compito immane di aggiornare tutto il software che potrebbe contenere la libreria difettosa. L’Apache Software Foundation è stata la prima a rilasciare un aggiornamento di sicurezza di emergenza per correggere la vulnerabilità 0-day (etichettata come CVE-2021-44228) di Log4j, come parte della versione 2.15.0.
Come riporta il CSIRT, un ricercatore, tramite l’accesso agli avvisi pubblicati dai differenti produttori e riferiti alla vulnerabilità, ha raccolto le informazioni sulle specifiche misure di mitigazione disponibili per vari prodotti, creando un catalogo alfabetico che è possibile consultare facendo riferimento a quelli in uso. Si tratta di una lista, in fase di aggiornamento, che include oltre 150 prodotti, tra i quali emergono anche quelli di diversi vendor orientati alla sicurezza.
Per altre azioni di mitigazione, si rimanda sempre alle pagine ufficiali del CSIRT e dei singoli vendor.
In questo momento, tutti sono al lavoro per risolvere il problema: la società di videogiochi svedese Mojang Studios è stata la prima a rilasciare un aggiornamento di sicurezza Minecraft di emergenza (per risolvere il bug sui client Java Edition e sui server multiplayer del gioco).
In conclusione, alcune lezioni per il futuro …
Il fatto più imbarazzante però è che qualcuno lo aveva anche predetto: come riporta Marco Calamari su Zeus News, circa 10 anni fa, in occasione di un evento di sicurezza a Berlino, un esperto di sicurezza nello sviluppo web spiegò il fatto che le grandi vulnerabilità del web sarebbero derivate in futuro non tanto dal codice scritto dai programmatori delle applicazioni stesse, ma da errori presenti negli infiniti pezzi di software utilizzati per le stesse applicazioni, come librerie e middleware.
Con vulnerabilità sia nel codice delle librerie stesse, sia dovute ad errori di “interfacciamento” tra i diversi pezzi, per API mal documentate o la cui documentazione, per la fretta, nessuno ha avuto il tempo di leggere.
Fonte: L’insostenibile debolezza del middleware: log4j, Marco Calamari, ZEUS News 13-12-2021
Come ha commentato invece Stefano Zanero nella puntata dedicata a Log4J da Matteo Flora, il problema sta nel fatto che lo zero-day è facile da sfruttare e facilmente raggiungibile dall’aggressore. Perché sarà così difficile aggiornare il software? perché non sarà semplice sapere dove esattamente uno sviluppatore qualsiasi ha messo quelle righe con Log4j.
È prevedibile quindi che, dopo una prima fase in cui il problema sarà risolto in una grande quantità di programmi, riducendo almeno in parte la vastissima superfice d’attacco che è stata appena svelata, rimanga comunque una coda lunga di problemi che non saranno mai risolti del tutto. Per il futuro una lezione per tutti potrebbe essere, secondo Zanero, richiedere di assegnare a ogni prodotto un SBOM (software bill of materials), ossia, una lista, parte della scheda tecnica di un device qualsiasi, che descrive con attenzione quali sono TUTTE le librerie software utilizzate nel realizzarlo. Solo questo potrà aiutare in futuro a individuare una vulnerabilità creata nella supply chain del prodotto, bug che – finchè rimarrà nascosto nel codice – rappresenterà una vulnerabilità sfruttabile da esterni.
A cura di:
Elena Vaciago, @evaciago
