Dark background with blue code overlay
Blog

Le raccomandazioni di Akamai per mitigare le vulnerabilità di Log4j

Akamai blue wave

Written by

Aparna Rayasam, SVP & GM Application Security, Akamai

December 16, 2021

log4j.png

Analisi riassuntiva

Una vulnerabilità RCE (Remote Code Execution) critica (CVE-2021-44228) è stata divulgata pubblicamente in Log4j, un'utilità di registrazione open source ampiamente utilizzata nelle applicazioni, tra cui molte applicazioni di grandi aziende. 

La vulnerabilità consente ai criminali di estrapolare le informazioni desiderate ed eseguire codice dannoso sui sistemi su cui sono presenti le applicazioni che utilizzano la libreria manipolando i messaggi del registro. Sono stati già segnalati server che eseguono scansioni su Internet nell'intento di localizzare le loro vulnerabilità, i cui tentativi di sfruttamento in numero allarmante vengono osservati dai nostri team addetti all'intelligence sulle minacce. Log4j è integrato in molti dei framework più comuni e in diverse applicazioni Java, il che rende il rischio di attacco estremamente diffuso.

La vasta gamma di soluzioni per la sicurezza di Akamai, incluse le soluzioni per la sicurezza di applicazioni e API, Enterprise Threat Protector e Guardicore Segmentation, è ben posizionata per aiutare a soddisfare questa vulnerabilità in vari modi. Si consiglia vivamente alle organizzazioni di aggiornare Log4j alla sua versione più recente (2.16.0). Poiché questa vulnerabilità cresce rapidamente, i team Akamai continueranno a sviluppare e implementare misure di mitigazione nell'intento di assistere i nostri clienti. 

Cosa si intende per vulnerabilità di Log4j?

Il 9 dicembre 2021, è stata segnalata una vulnerabilità critica relativa all'esecuzione di codice remoto non autenticato e all'esfiltrazione di dati (CVE-2021-44228) in Log4j, causando preoccupazioni a causa della modo con cui viene comunemente utilizzata la funzione di registrazione open source. Questo utilizzo diffuso, insieme alla facilità di poter sfruttare la vulnerabilità, rende il suo impatto particolarmente significativo. Poiché questa vulnerabilità viene attualmente sfruttata, i team addetti alla sicurezza in tutto il mondo lavorano alla ricerca e alle relative soluzioni di mitigazione.

Un sistema compromesso consente ad un criminale di esfiltrare i dati e fornire da remoto il software eseguito da Log4j. In tal modo, un criminale può eseguire comandi arbitrari all'interno di un server, rendendo visibili informazioni e segreti e facendo partire dal server ulteriori attacchi sferrati potenzialmente contro sistemi protetti in una rete senza accesso diretto a Internet.

Gli sviluppatori Java usano ampiamente Log4j per semplificare la registrazione di errori e informazioni di debug. Di conseguenza, i fornitori di prodotti il cui software è basato su Java potrebbero risultare vulnerabili. Anche se un'applicazione non usa direttamente Log4j, molti comuni strumenti e framework lo usano internamente e, pertanto, possono introdurre questa vulnerabilità nelle loro applicazioni.  

Perché la vulnerabilità Log4j è grave?

Anche se Akamai ha osservato il 9 dicembre per la prima volta i tentativi di sfruttamento della vulnerabilità di Log4j, ci sono prove evidenti che fanno pensare che questa vulnerabilità sia stata sfruttata mesi prima. Dalla pubblicazione di questa vulnerabilità, abbiamo registrato diverse varianti che tentano di sfruttarla sferrando attacchi ad un ritmo sostenuto pari a circa 2 milioni di tentativi all'ora. Le varianti si evolvono con una velocità senza precedenti. 

Più della metà (circa il 57%) degli attacchi registrati finora provengono da criminali già inclusi nel database di intelligence sulle minacce di Akamai. Possiamo prevedere che, a causa dell'enorme volume di sistemi privi di patch, continueremo a registrare tentativi di sfruttamento della vulnerabilità nei prossimi mesi. I team addetti alla risposta agli incidenti e alla ricerca sulla sicurezza di Akamai continuano a monitorare e proteggere la nostra infrastruttura e i nostri clienti, sfruttando la nostra esclusiva visibilità e la nostra impareggiabile intelligence.

Benché l'azione più importante da intraprendere in caso di vulnerabilità sia proteggere i sistemi infetti con le patch, i ricercatori che si occupano di sicurezza sanno che ci vuole tempo. In molti casi, le organizzazioni potrebbero anche non conoscere quali sono i loro sistemi vulnerabili. In tal caso, è necessario implementare ulteriori soluzioni di mitigazione per ridurre la superficie di attacco per quanto possibile.

Per assistere in questa operazione, Akamai suggerisce vari metodi. Attualmente, la massima quantità di traffico in termini di attacchi da noi osservati come associati a Log4j riguarda le applicazioni web, pertanto l'operazione maggiormente significativa che le organizzazioni possono intraprendere dopo l'applicazione delle patch consiste nello sfruttare i sistemi di protezione di applicazioni web e API di Akamai. Leggete come e cosa fare all'interno della vostra azienda man mano che i vettori di attacco si evolvono. 

Mitigazione degli abusi di Log4j con la suite di soluzioni per la protezione di app e API di Akamai

Akamai continua ad aggiornare le regole WAF (Web Application Firewall) per fornire una protezione da questo exploit e dalle sue diverse varianti. Tale aggiornamento comprende l'aggiornamento della regola 3000014 all'interno di due soluzioni di Akamai: Kona Rule Set e Adaptive Security Engine. Per i clienti che utilizzano i gruppi di attacchi automatizzati, abbiamo aggiornato il gruppo Command Injection. Tutti i clienti che attualmente hanno tali regole o gruppi di attacchi attivate in modalità RIFIUTA riceveranno una protezione automatica in linea per i seguenti motori e versioni di protezione:

  • Kona Rule Set: qualsiasi versione con data 29 ottobre 2019 o successiva

  • Gruppi di attacchi automatizzati: tutte le versioni

  • Motore di sicurezza adattiva: tutte le versioni

Molti server, soprattutto quelli che si trovano in ambienti ad alto rischio, ad esempio direttamente accessibili da Internet, potrebbero essere già stati compromessi Per identificare gli indicatori di compromesso, è possibile utilizzare il seguente comando che mostra i tentativi di sfruttamento delle vulnerabilità:

sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns)://' /var/log

Per saperne di più sui sistemi di protezione di applicazioni web e API di Akamai, potete leggere ulteriori informazioni o potete contattarci.

Anche se i sistemi di protezione WAF possono risultare altamente efficaci per i server web in questa fase, le organizzazioni devono anche considerare percorsi alternativi degli attacchi che potrebbero aver condotto ad un compromesso. A tal fine, si consiglia di utilizzare la microsegmentazione per guadagnare visibilità su possibili vulnerabilità e per ridurre i rischi e la diffusione. 

Rilevamento degli abusi di Log4j con Enterprise Threat Protector

I ricercatori sulle minacce di Akamai hanno esaminato i dati DNS, proxy e sinkhole dei clienti alla ricerca di comportamenti anomali correlati ai tentativi di utilizzo della vulnerabilità di Log4j da parte dei criminali. Nei dati DNS, sorprendentemente si è visto che le query DNS per i domini contenevano la stringa "jndi:ldap". Si tratta di query DNS non valide che contengono caratteri errati nel nome del dominio e, pertanto, non possono essere risolte. Inoltre, abbiamo registrato una quantità di traffico verso domini dannosi noti che era stato reindirizzato ai server sinkhole. Questi domini ospitavano codice Java dannoso che veniva utilizzato per sfruttare i server vulnerabili. Tutti questi fattori indicano un abuso potenziale delle reti dei clienti. 

Mitigazione degli abusi di Log4j con la soluzione Akamai Guardicore Segmentation

I clienti che utilizzano la soluzione Akamai Guardicore Segmentation possono sfruttare la sua visibilità a livello dei processi per identificare le applicazioni vulnerabili e i rischi alla sicurezza nell'ambiente, al fine di attuare un controllo accurato sul traffico di rete per fermare gli attacchi sferrati contro i sistemi vulnerabili, senza interrompere le normali operazioni aziendali.

Cosa può subire una minaccia Identificare i processi Java vulnerabili e gli abusi di Log4j

Per proteggersi dai tentativi di abuso di Log4j, è necessario identificare prima i processi potenzialmente vulnerabili. A tal fine, è richiesta una profonda visibilità sul traffico di rete al livello dei processi, che viene fornita da Akamai Guardicore Segmentation. Una visibilità accurata sul traffico e sui collegamenti Internet ci consente di comprendere chiaramente quali sono i passaggi necessari per la mitigazione senza interrompere le operazioni aziendali. 

Fermare gli attacchi bloccando i vettori di attacco e gli IoC dannosi

È fondamentale riuscire a intraprendere le azioni necessarie una volta identificate le applicazioni vulnerabili. Mentre è in corso lo sviluppo delle patch, Akamai Guardicore Segmentation offre una serie di opzioni utili per segnalare, fermare e prevenire gli attacchi. Una soluzione con un controllo dettagliato e preciso sul traffico e sulle comunicazioni di rete è decisamente richiesta per bloccare o isolare in modo "chirurgico" i vettori di attacco senza interrompere o quasi le normali funzioni aziendali. Tra queste ricordiamo:

  • Blocco IoC automatico con TIFW (Threat IntelligenceFirewall) e DNS Security 

  • Quarantena totale dei server compromessi 

  • Blocco del traffico in entrata e uscita verso risorse vulnerabili 

  • Blocco del traffico in uscita dalle applicazioni Java a Internet

Inoltre, i clienti di Guardicore Hunt vedono monitorare e indagare costantemente il proprio ambiente da parte di un team di ricercatori sulla sicurezza altamente motivati. Vengono immediatamente inviati avvisi sui rischi alla sicurezza e i passaggi di mitigazione suggeriti.  

Se volete saperne di più su Akamai Guardicore Segmentation, potete leggere ulteriori informazioni o potete contattarci.

Conclusione

Akamai continuerà a condividere le sue conoscenze man mano che gli exploit di Log4j vengono strettamente monitorati ed esaminati e fornirà aggiornamenti tempestivi ai propri sistemi di protezione e funzionalità.



Akamai blue wave

Written by

Aparna Rayasam, SVP & GM Application Security, Akamai

December 16, 2021