Tutti ricordiamo Log4Shell, la vulnerabilità zero-day della libreria di log Log4j che, scoperta nel dicembre del 2021, ha potenzialmente compromesso milioni di dispositivi in tutto il mondo. In risposta a questa scoperta, Apache ha rilasciato diversi aggiornamenti software, mentre i team di sicurezza hanno adottato ulteriori misure per proteggere le loro reti.
Tuttavia, come previsto, gli attori malevoli hanno continuato a tentare di sfruttare Log4j.
Sfruttando i dati di telemetria è possibile fornire una migliore visibilità sui tentativi attivi ancora oggi, ottenendo in particolare informazioni sui tentativi di exploit di Log4j che hanno come obiettivo specifico gli ambienti OT/IoT.
Vulnerability management, questo sconosciuto: cosa ci insegna il caso Log4j
Indice degli argomenti
Vulnerabilità Log4Shell, lo stato dell’arte
La vulnerabilità di Log4j (CVE-2021-44228), contrassegnata da un punteggio di 10 su 10 del Common Vulnerability Scoring System (CVSS), è altamente sfruttabile e può consentire agli attori malintenzionati di eseguire codici da remoto su server vulnerabili.
Pochi giorni dopo la divulgazione iniziale, è stata rilasciata una seconda vulnerabilità di Log4j, tracciata come CVE-2021-45105, che ha introdotto la possibilità di lanciare attacchi Denial of Service (DoS).
Log4j utilizza una funzione nota come lookup. Esistono diversi lookup che possono essere utilizzati, ma i due sfruttati da Log4Shell sono:
- Il lookup di Java Naming and Directory Interface (JNDI) consente agli utenti di accedere a risorse memorizzate in remoto attraverso una connessione di rete. Ciò permette di ricercare facilmente le informazioni necessarie per stabilire una connessione.
- L’environment lookup che consente agli utenti di accedere alle variabili ambientali presenti sul computer da cui si utilizza Log4Shell. Ciò significa che tutte le variabili ambientali definite dall’utente e accessibili dal computer in uso possono essere consultate attraverso Log4Shell.
In questo caso, l’utility Log4j aveva abilitato la sostituzione del messaggio come impostazione predefinita. Ciò ha permesso agli attori delle minacce di incorporare codici malevoli all’interno di una richiesta, attivando l’esecuzione automatica di Log4j senza alcun intervento da parte dell’utente.
Le prime analisi dei ricercatori di sicurezza
Subito dopo la divulgazione di Log4Shell, sono state sviluppate regole di pacchetti per identificare potenziali attività Log4shell negli ambienti delle potenziali vittime. Sfruttando la telemetria anonima, è stato possibile ottenere preziose informazioni sulla diffusione dei tentativi di exploit di Log4j.
In particolare, tra il 16 maggio e il 16 novembre 2022 sono state registrati oltre 60.000 tentativi di primo e secondo livello in almeno 14 ambienti dei nostri clienti. Di seguito è riportata un’analisi degli exploit tentati utilizzando i seguenti protocolli:
Protocolli utilizzati nel primo e nel secondo tentativo di payload.
Posizione del primo e del secondo tentativo di payload.
In base alla telemetria, ci sono stati 40.000 tentativi di sfruttare il lookup JDNI nei server vulnerabili utilizzando TCP. Gli attori delle minacce preferiscono utilizzare TCP rispetto a UDP e HTTP perché consente loro di stabilire una connessione affidabile con il sistema di destinazione, il che rende più facile sfruttare le vulnerabilità di sicurezza note. TCP garantisce inoltre la sicurezza dei dati trasferiti tramite crittografia e autenticazione, consentendo agli attori delle minacce di trasferire i dati senza essere intercettati.
Sebbene vi siano stati tentativi di interrogare LDAPS, RMI e DNS, le minacce hanno tentato di interrogare LDAP circa 40.000 volte. LDAP è un protocollo standardizzato che può essere utilizzato su quasi tutti i sistemi operativi e su una varietà di linguaggi di programmazione, rendendo relativamente facile per gli attori delle minacce costruire applicazioni o script attorno al protocollo.
Una vulnerabilità ancora attuale e minacciosa
La vulnerabilità Log4Shell è, dunque, ancora presente e pericolosa perché consente ad attori malintenzionati di inviare comandi di shell attraverso i file di log. Ciò significa che un utente malintenzionato può eseguire qualsiasi comando su un sistema vulnerabile, consentendogli di fare qualsiasi cosa: apportare modifiche, rubare informazioni o lanciare un attacco informatico.
Log4Shell è pericolosa perché può essere difficile per i team di sicurezza tenerne traccia, rendendo difficile prendere provvedimenti adeguati. Questo perché il processo richiede agli sviluppatori di esaminare manualmente ogni file del codice sorgente dell’applicazione e di assicurarsi che tutte le dipendenze Log4j siano aggiornate all’ultima versione. Purtroppo, le aziende non hanno il tempo, le risorse e il livello di competenza necessari per eseguire questa operazione per tutte le applicazioni supportate.
Raccomandazioni per mitigare il rischio
Per mitigare il rischio attuale, le organizzazioni dovrebbero implementare Apache Log4j 2, un aggiornamento che fornisce molti miglioramenti rispetto al suo predecessore, Log4j 1.
Se le organizzazioni desiderano conoscere la versione corrente di Log4j utilizzata da applicazioni specifiche e le vulnerabilità ad essa associate, dovrebbero utilizzare un vulnerability scanner. Lo scanner analizza il codice dell’applicazione alla ricerca di codice potenzialmente vulnerabile o di dipendenze legate a Log4j e suggerisce le correzioni per i problemi riscontrati. Lo scanner può anche identificare le versioni obsolete di Log4j e consigliare l’aggiornamento alla versione più recente.
Per ulteriori mitigazioni relative alle vecchie versioni di Log4j che potrebbero essere ancora in uso, le organizzazioni dovrebbero controllare gli aggiornamenti disponibili sul sito ufficiale del progetto Log4j.
A scopo preventivo, le organizzazioni possono adottare una serie di misure per mantenere sicure le proprie reti, come ad esempio la modifica delle password predefinite, l’implementazione di firewall e IPS, la scansione e la correzione delle vulnerabilità e l’esecuzione di penetration test.
Le violazioni della rete si verificano spesso a causa di un’igiene informatica inadeguata, motivo per cui è essenziale che le organizzazioni si assicurino innanzitutto che il perimetro delle loro reti sia ben protetto prima di concentrarsi sulle misure di sicurezza interne.
Alcune best practice per la sicurezza interna includono: l’applicazione di controlli sugli accessi privilegiati, l’implementazione di IDS, l’utilizzo di threat intelligence per identificare le attività dannose all’interno della rete e l’esecuzione di regolari operazioni di threat hunting.
