Log4Shell, perché è forse il bug più grave di sempre

Non solo Log4Shell è una delle più estese vulnerabilità zero-day mai scoperte, diffusa ubiquamente su un imprecisato numero di server, ma è anche destinata a creare problemi nel lungo termine. A qualche giorno dal pubblico disvelamento di questa vulnerabilità di criticità massima, alcune voci autorevoli stanno sottolineando che il problema non è affatto risolto, nonostante la disponibilità di una patch. “Questa vulnerabilità è una tra le più gravi che abbia visto in tutta la vita, se non la più grave”, ha dichiarato alla Cnn la direttore della Cybersecurity and Infrastructure Security Agency (Cisa), Jan Easterly.

Come sottolineato da Bitdefender, Java è un framework multipiattaforma, che funziona su sistema operativo Windows, Linux, macOS, FreeBSD e altri ancora, e questo peggiora lo scenario del rischio, estendendolo non soltanto a server e Pc ma anche a Web cam, sistemi di navigazione per auto, set-top box e a varie tipologie di terminali connessi, persino parchimetri e dispositivi medici. Bitdefender ha rimarcato che questa vulnerabilità esercita “un effetto a catena molto significativo sulla supply chain del software”, ed è difficile prevedere quale sarà il suo impatto a lungo termine.

Alcuni ambiti destano particolare preoccupazione. Gli ambienti OT (Operational Technology) e i sistemi di controllo industriale sono spesso un crogiuolo di tecnologie eterogenee e non è facile ottenere la piena visibilità su tutte le parti di software in uso e sugli eventi in corso sulle reti. Ci vorranno mesi o anche anni, secondo gli addetti ai lavori, prima che molte reti industriali risolvano questo bug. “Essendo stata per decenni una ubiqua soluzione di logging per lo sviluppo di Enterprise Java, Log4j può potenzialmente diventare una vulnerabilità che permarrà negli ambienti dei sistemi di controllo industriale (Ics) per i prossimi anni”, ha scritto Dragos, società di cybersicurezza specializzata in reti industriali. Gli esperti di Dragos si dicono abbastanza certi del fatto che i percorsi di exploit più semplici saranno presto risolti con adeguate patch, ma nel tempo i cybercriminali svilupperanno exploit più complessi, che avranno maggiore probabilità di colpire direttamente le reti OT.

Purtroppo questi rischi non sono solo teoria. A poche ore dalla circolazione della notizia sulla vulnerabilità già si erano verificati numerosissimi tentativi di attacco che cercavano di sfruttarla. Check Point, per esempio, ha riferito di aver registrato migliaia di tentativi di attacco nella sola giornata del 10 dicembre (a 24 ore dal disvelamento della vulnerabilità), diventati poi oltre 40mila il giorno dopo. A 72 ore dalla notizia, il numero degli attacchi osservati aveva superato quota 800mila ed erano già in circolazione una sessantina di diverse varianti dell’exploit originario.

Bitdefender ha osservato tentativi di diffondere Khonsari, una nuova famiglia di ransomware, per colpire i sistemi con sistema operativo Windows (la maggior parte degli attacchi aveva finora ha preso di mira i server Linux). Altri gruppi di criminali stanno cercando di sfruttare la vulnerabilità per distribuire il trojan di accesso remoto Orcus. Inoltre non sarebbe troppo complesso distribuire su server affetti dal problema un attacco cosiddetto di reverse bash shell, nel quale si guadagna un “punto d’appoggio” da sfruttare poi in un successivo momento. Ciliegina sulla torta, dalle analisi di Bitdefender risulta che diverse botnet (fra cui Muhstik) stiano già utilizzando la vulnerabilità per inserire delle backdoor nei server bersaglio e per espandere le loro reti.

“È importante dare priorità alle applicazioni esterne e interfacciate con Internet rispetto a quelle interne, per via della loro esposizione su Internet, per quanto entrambe siano vulnerabili”, ha spiegato Sergio Caltagirone, vice president of threat intelligence di Dragos. Si raccomanda, quindi, che tutti gli ambienti industriali aggiornino le applicazioni che impiegano Apache Log4j, seguendo le indicazioni dei vendor di riferimento, ma continuino anche a monitorare i segnali indicativi di un possibile exploit in corso o già avvenuto.