Vulnerabilità Log4Shell: cos’è e perché ha scatenato la tempesta nella sicurezza sul web

Nelle ultime settimane del 2021 più o meno tutti dovremmo aver sentito parlare di Log4Shell, ma cosa ha determinato tale risonanza a livello mediatico?

Spesso assuefatti dal modo con cui i media urlano qualcosa salvo trascinarlo nell’oblio all’affievolirsi del clickbaiting, possiamo essere propensi a sottovalutare la portata di una novità, ma nel caso di Log4Shell ciò equivarrebbe ad un errore fatale, soprattutto se il nostro scopo nella vita fosse quello di garantire la sicurezza di sistemi e applicazioni informatiche.

Ancor prima di entrare nel merito degli effetti dei possibili incidenti, Log4Shell rappresenta infatti la principale vulnerabilità informatica sin qui riscontrata per quanto concerne la possibile superficie di attacco, dal momento che è in grado di interessare qualsiasi applicazione web basata su Java.

Tale vulnerabilità può essere sfruttata dai cybercriminali per penetrare all’interno dei sistemi aziendali con una facilità a dir poco irrisoria.

Vediamo in cosa consiste Log4Shell e quali sono i risvolti più significativi sul fronte della cybersecurity, per conoscere i concetti di massima che caratterizzano una delle vulnerabilità più incredibili di tutti i tempi.

Cos’è la vulnerabilità Log4Shell

La vulnerabilità Log4Shell viene utilizzata per identificare un clamoroso bug della libreria Log4j (Logging for Java), che gestisce i log delle web application sviluppate con Java. Si tratta di una risorsa open source sviluppata e distribuita da Apache Software Foundation per gestire la fase di logging (https://logging.apache.org/log4j/2.x/).

Sfruttando la vulnerabilità di Log4j i cybercriminali possono sfruttare semplici richieste http verso un sito web (utilizzando il toolkit JNDI) per reimpostare i log (es. il Virtual Agent) e portare a termine un’ampia tipologia di attacchi, semplicemente dicendo al web server bersaglio cosa fare, ad esempio connettersi al server dell’attaccante (richiesta LDAP) e scaricare un RCE (Remote Control Execution) malevolo, che verrà automaticamente eseguito sul sistema della vittima.

Quale conseguenza di questa esecuzione di codice in remoto, il server a quel punto non detiene più alcun controllo su quel contenuto.

L’attaccante può quindi controllare il sistema per mettere a segno gli attacchi più comuni: ransomware, botnet, DDoS, esfiltrazione dei dati e chi più ne ha, più ne metta.

La probabilità di portare a termine con successo un exploit Log4j appare molto elevata qualora il server vittima:

• Utilizzi JNDI (Java Naming and Directory Interface) per effettuare una richiesta LDAP (oppure DNS, COS, RMI, ecc.) per scaricare un RCE malevolo;
• Esegua il RCE malevolo secondo le procedure tipiche di esecuzione del codice remoto non autorizzato.

La vulnerabilità Log4Shell è stata ufficialmente scoperta e resa nota lo scorso 9 dicembre, e categorizzata come CVE-2021-44228 nel registro del programma CVE, che si occupa di identificare, definire e catalogare pubblicamente le vulnerabilità alla sicurezza informatica dei sistemi. Tale vulnerabilità è stata notificata senza che fosse ancora disponibile una patch risolutiva, provocando una situazione di panico generalizzata e di toppe per certi aspetti sin peggiori del buco.

Il problema riguarda sostanzialmente Log4j 2.14.1 e le versioni precedenti, anche se i primi aggiornamenti pubblicati per cercare di risolvere il problema sono stati puntualmente vittime di attacchi zero-day, categorizzati come CVE-2021-45046 (Log4j 2.15.0) e CVE-2021-45105 (Log4j 2.16.0).

Nel momento in cui scriviamo l’ultima release ufficiale è Log4j 2.17.0, liberamente scaricabile dal repository del sito ufficiale, dove sono puntualmente disponibili tutte le versioni stabili del software (https://logging.apache.org/log4j/2.x/download.html).

La situazione è tuttavia in continua evoluzione, per cui è lecito attendersi novità importanti giorno dopo giorno.

Perché Log4shell è così pericoloso per cybersecurity

Il problema principale legato alla vulnerabilità Log4Shell è il fatto di interessare una delle tecnologie più diffuse in assoluto per quanto concerne il back-end delle applicazioni web. Si stima che Java esegua software su circa tre miliardi di dispositivi informatici, che spaziano dai server aziendali al più comune degli smartphone.

Con una vulnerabilità di questo genere, il semplice fatto di essere online rappresenta un’effettiva situazione di pericolo. Nessuno può considerarsi al sicuro: né i cittadini, né soprattutto le aziende pubbliche e private, che costituiscono dei ghiotti bersagli per i cybercriminali.

Come avviene ormai quotidianamente nel caso della stragrande maggioranza degli attacchi informatici, il bersaglio privilegiato è costituito dai dati digitali.

Non ci sarebbero dunque particolari novità da questo punto di vista. Ciò che varia è che questa volta si ha a che fare con una superficie vulnerabile senza precedenti, che rende in primo luogo complesso addirittura capire se si è rimasti o meno vittima di un attacco in grado di sfruttare la vulnerabilità Log4shell.

Log4Shell mette a nudo i limiti, o meglio, la croce e la delizia dei progetti open source di questa portata. Se da un lato la libreria Log4j ha consentito di delineare uno standard per i log di Java, dall’altro il suo codice è stato implementato in milioni e milioni di applicazioni senza che nessuno si curasse nel dettaglio della sua natura all’origine e delle possibili ripercussioni in termini di sicurezza nelle singole implementazioni.

Log4j ha esordito nel 2001, per cui sono vent’anni che girano applicazioni che lo vedono ancora attivo, su che non saranno con ogni probabilità più aggiornati, pur continuando a costituire una minaccia latente a bordo dei sistemi che li eseguono. Log4j è sempre stato supportato dalla Apache Software Foundation, che ha svolto un lavoro volontario enorme per portarla avanti in tutti questi anni.

Non è in sostanza accaduto, come nel caso di molti altri software open source, che lo sviluppo venisse preso in carico da società private in grado di dedicare risorse specifiche per mantenere l’iniziativa in maniera professionale.

Si pensi soltanto a quanto avviene nel mondo delle distribuzioni Linux. Con attenzioni differenti, probabilmente una falla di tale portata sarebbe emersa molto prima, riducendo sensibilmente l’esposizione in termini di cybersicurezza.

Appare quindi a dir poco paradossale che i giganti dell’informatica abbiano costruito applicazioni capaci di generare molti miliardi di dollari, senza entrare nel merito della sicurezza di un componente come Log4j.

Senza essersi accorti assolutamente di nulla. Non solo appare paradossale, ma lo è a tutti gli effetti, ed è quanto è successo da vent’anni a questa parte. Porvi rimedio non sarà così semplice.

Come mitigare gli effetti della vulnerabilità Log4Shell

Ad oggi la vulnerabilità Log4Shell può dirsi in parte risolta e lo sarà sempre più grazie al progressivo rilascio di nuove patch, anche se ha di fatto aperto una nuova era nella dimensione degli attacchi di sicurezza informatica, andando a colpire il cuore di uno degli strumenti più utilizzati in assoluto. Una di quelle cose che dovrebbe essere assolutamente sicura per design, ma che si è scoperto essere di una fragilità inaudita.

Intervenire per mettere in sicurezza miliardi di applicazioni web non è non sarà assolutamente semplice, per cui la rete rimarrà per lunghi periodi terra di conquista dei malintenzionati. I disagi potranno avere una coda lunga nell’ordine di diversi mesi, se non addirittura di anni.

Le buone prassi da seguire per mettere in sicurezza le proprie web application dagli attacchi Log4Shell sono le seguenti:

• Aggiornare Log4j installando la più recente patch disponibile tra quelle ufficialmente rilasciate dagli sviluppatori di Apache. Prima o poi, almeno per quanto riguarda lo sviluppo di nuove applicazioni, il problema verrà risolto;
• Cercare disattivare o rendere inaccessibili le applicazioni che supportano (al momento) Log4j 2.16.0 o precedenti, che non possono, per le ragioni più disparate, essere aggiornate alla versione ufficiale più recente;
• Impedire a JNDI di effettuare ricerche LDAP su server non verificati. Si tratta di una modifica piuttosto semplice, che si può eseguire impostando su “true” il valore di configurazione formatMsgNoLookups, in modo da prevenire qualsiasi rischio semplicemente evitando che vengano eseguite delle query LDAP verso server malevoli. Va inoltre eliminata la classe Java JndiLookup dal path delle classi stesse.

Al di là di queste semplici prassi, è opportuno cercare di mettere in sicurezza nel più breve tempo possibile tutti i server che possono essere vittime di questo genere di attacchi, soprattutto grazie ad un atteggiamento proattivo, tipiche dell’investigazione di un incidente di sicurezza informatica (incident response), con attività di vulnerability assessment e i relativi penetration test.

Per evitare che l’eventuale problema si ripeta è assolutamente necessario anche un atteggiamento di tipo reattivo, per conoscere la natura e la tipologia dell’attaccante, dell’attacco e capire esattamente come i criminali sono stati in grado di sfruttare la vulnerabilità Log4Shell, quali fossero i loro reali obiettivi e prendere decisioni consapevoli sia per mitigare gli attacchi che per scongiurare che si verifichino in un secondo momento.

Gli errori da non ripetere dopo il caso Log4Shell

Oltre al lecito interrogativo circa la sicurezza dei sistemi open source, di cui abbiamo ampiamente discusso nel corso dei precedenti parametri, la vulnerabilità Log4Shell lascia spazio a dubbi e riflessioni di varia natura, che è bene porsi anche sulla base del semplice buon senso di chi dovrebbe avere a cuore la sicurezza dei propri sistemi e dei dati che vi transitano, senza essere per forza un esperto o un professionista nell’ambito della sicurezza informatica.

In particolare, ci pare opportuno porre l’accento su due tra i moltissimi aspetti che andrebbero rilevati: le configurazioni di default e la complessità dei componenti di un software.

Nel caso di Log4j, come accade nel caso dei componenti di moltissimi software, abbiamo a che fare con una libreria implementata senza che molti ne conoscano nemmeno l’esistenza, per giunta in una configurazione di default che concede azioni e privilegi importanti, su cui sarebbe opportuno avere il pieno controllo, prima che i cybercriminali lo facciano al posto nostro. Molto spesso il fatto di avere delle funzionalità attive per default consente al software e alle macchine che lo eseguono di svolgere operazioni a noi del tutto inutili, che potrebbero tranquillamente essere disattivate evitando i rischi di una possibile vulnerabilità.

Prendere delle soluzioni software per personalizzarle soltanto in parte, ignorando parte dei componenti che contribuiscono all’esecuzione, rappresenta pertanto un rischio molto elevato. Siamo certi che mentre tutto il mondo della sicurezza informatica sta parlando di Log4Shell, ci sono sistemisti che nemmeno si pongono il problema, ignari del fatto che Log4j sia operativo sulle loro macchine.

Meno pratico, forse più concettuale, ma altrettanto determinante è la capacità di un componente di svolgere più funzioni all’interno del software. Non sempre ciò equivale ad una qualità positiva, perché come è avvenuto nel caso di Log4j, ciò si traduce in una fisiologica espansione della superficie di attacco: un effetto che risulterebbe più contenuto qualora un componente svolgesse soltanto una funzione, ossia quella di utilizzo prevalente.

In termini informatici, la specializzazione di ogni componente agevola in genere anche la manutenzione del codice e sarebbe per design più semplice da gestire anche nel caso in cui emergessero delle vulnerabilità.

Gli attacchi nation-state “made in China” e la notifica delle minacce di sicurezza informatico: Alibaba Cloud ancora nel mirino

Tra le varie curiosità che hanno infarcito le cronache della cybersicurezza in una chiusura di 2021 davvero col botto, figura la notizia pubblicata dal South China Morning Post (https://www.scmp.com/tech/big-tech/article/3160670/apache-log4j-bug-chinas-industry-ministry-pulls-support-alibaba-cloud), che vedrebbe il governo cinese aver temporaneamente sospeso la collaborazione con Alibaba Cloud dal momento che quest’ultima non avrebbe notificato la minaccia conseguente alla vulnerabilità di Log4J, pur avendola rilevata già nel mese di novembre, ben prima che la questione diventasse di dominio pubblico.

La questione è molto complessa e, come spesso accade negli episodi che riguardano la politica cinese, risulta molto difficile trarre una valutazione oggettiva “dall’esterno”. Da un lato Alibaba Cloud non sarebbe stato tenuto a segnalare la vicenda, in quanto la notifica di una vulnerabilità spetterebbe di base allo sviluppatore della tecnologia. Tuttavia, una recente legge impone alle aziende cinesi di comunicare qualsiasi vulnerabilità venuta a loro notizia utilizzando il National Vulnerability Database. Alibaba Cloud non avrebbe pertanto rispettato tale disposizione.

Si tratta finora di una delle più evidenti prese di posizione a livello internazionale per quanto riguarda il mancato rispetto di un obbligo di notifica in fatto di sicurezza informatica.

In ogni caso, non si tratta del primo scontro a viso aperto tra il governo cinese e Alibaba, se consideriamo le vicende legate alla “sparizione” di Jack Ma, a seguito di tensioni con il leader Xi Jinping e la sanzione di quasi tre miliardi di dollari inflitta ad inizio 2021 dalla SAMR, equivalente cinese dell’antitrust nostrano, per abuso di posizione dominante. Secondo vari esperti, il governo cinese userebbe sistematicamente la propria autorità per evitare che i propri colossi assumano un potere tecnologico ed economico tale da sfuggire o mettere in dubbio la sua egemonia.

Se da un lato la Cina vuole predicare bene in termini di cautele nei confronti della cybersicurezza, dall’altro pare razzolare piuttosto male nell’alimentare i focolai a livello internazionale. Secondo una fonte di Microsoft (https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/#nation-state), il gigante asiatico, insieme a Iran, Turchia e Korea del Nord sarebbe tra i principali finanziatori di attacchi nation-state nei confronti dei paesi avversari.

È infatti molto sospetta l’attività del gruppo criminale cinese Hafnium, estremamente noto per aver sfruttato in passato varie vulnerabilità di Microsoft Exchange, episodi per cui la Cina ha ricevuto l’esplicito disappunto di USA, Gran Bretagna ed Europa, le cui accuse sono state puntualmente smentite dalle fonti ufficiali del governo cinese. L’Iran avrebbe invece supportato l’attività del gruppo criminale Phosphorus, che nelle ultime settimane è stato molto attivo nel distribuire ransomware sfruttando le falle di Log4J.