La vulnerabilità Log4j, o " Log4Shell", è considerata una dei problemi del software più catastrofici di sempre. Apache ha risolto il problema nel dicembre 2021, tuttavia rimane una fonte di preoccupazione per i team addetti alla sicurezza. In effetti, è ancora tra le vulnerabilità di sicurezza più utilizzate.
Log4Shell persiste perché il pacchetto software Apache Log4j 2 interessato è una delle librerie di logging più utilizzate al mondo. Secondo il Dipartimento per la sicurezza interna degli Stati Uniti, ci vorranno circa dieci anni per individuare e risolvere ogni istanza di Log4Shell.
Nel frattempo, i team addetti alla sicurezza possono adottare alcune misure per accelerare la mitigazione e la correzione di Log4Shell nelle loro reti.
Unisciti ai leader della sicurezza che si affidano alla newsletter Think per ricevere notizie selezionate su AI, cybersecurity, dati e automazione. Impara velocemente da tutorial e articoli informativi consegnati direttamente nella tua casella di posta. Leggi l'Informativa sulla privacy IBM.
Prima di approfondire come rilevare e applicare patch per Log4Shell, è importante comprendere la natura di questa vulnerabilità.
Log4j è un logger open source (gestito dalla Apache Software Foundation) che registra informazioni ed eventi in un programma. Log4j non è un software autonomo, bensì un pacchetto di codice che gli sviluppatori possono collegare alle proprie app Java. Il framework Apache Log4j è utilizzato in alcuni dei principali servizi web, da infrastrutture di rete come Amazon Web Services (AWS) e soluzioni Cisco ad app popolari come Twitter e Minecraft.
Alcune versioni di Log4j, in particolare Log4j 2.17.0 e precedenti, presentano gravi vulnerabilità. La più pericolosa di queste è Log4Shell (CVE-2021-44228; valutazione CVSS: 10), una vulnerabilità zero-day di esecuzione di codice remoto (RCE) riscontrata nelle versioni 2.14.1 e precedenti di Log4j.
Log4Shell è il risultato del modo in cui le versioni vulnerabili di Log4j gestiscono la Java Naming and Directory Interface (JNDI), un'API utilizzata dalle app Java per accedere alle risorse in hosting su server esterni. I criminali informatici possono assumere il controllo quasi totale dei sistemi vulnerabili, inviando comandi di ricerca JNDI dannosi tramite Log4j. Questi comandi inducono l'app a eseguire codice arbitrario che può fare quasi tutto: rubare dati, installare ransomware, mettere offline i dispositivi e molto altro.
Un tipico attacco informatico Log4Shell funziona così:
Mentre Apache lavorava per applicare patch a Log4Shell, i ricercatori di sicurezza hanno identificato una serie di difetti correlati in alcune versioni di Log4j. Questi includono:
Trovare ogni istanza vulnerabile di Log4j in una rete può essere difficile. Si stima che Log4j sia presente in milioni di app, il che significa che i team addetti alla sicurezza hanno moltissimi asset da ispezionare.
Inoltre, Log4j è spesso presente come dipendenza indiretta. Ciò significa che non è contenuto direttamente nel codice sorgente di un asset, ma appare come una dipendenza di un pacchetto software o di un'integrazione su cui l'asset si basa. Google segnala che la maggior parte delle istanze Log4j vulnerabili si trovano a più di un livello di profondità nella catena delle dipendenze e alcune raggiungono anche nove livelli.
Detto questo, i team addetti alla sicurezza possono rilevare le vulnerabilità di Log4j con le tattiche e gli strumenti giusti.
Ogni versione di Log4j 2 dalla 2.0-beta9 alla 2.17 è vulnerabile a Log4Shell o a una falla correlata. In altre parole, i team addetti alla sicurezza devono trovare e risolvere qualsiasi versione di Log4j precedente alla 2.17.1.
Log4Shell e i relativi difetti sono presenti solo nei file "Log4j-Core", che forniscono le funzionalità principali di Log4j. I difetti non sono presenti nei file “Log4j-api”, che controllano l’interfaccia tra le app e i logger Log4j.
Log4j può apparire negli asset controllati dall'azienda, negli asset di terze parti utilizzati dall'azienda (ad esempio, nei cloud service) e negli asset utilizzati dai fornitori di servizi con accesso alla rete aziendale. Sebbene sia più probabile che Log4j appaia nelle app basate su Java, può essere presente anche nelle app non Java tramite dipendenze e integrazioni.
Nelle app Java, librerie come Log4j sono spesso impacchettate in file Java Archive, o "file JAR". I file JAR possono contenere altri file JAR, che a loro volta possono contenere i propri file JAR e così via. Per trovare tutte le versioni vulnerabili di Log4j, i team addetti alla sicurezza devono ispezionare tutti i livelli dei file JAR, non solo i file di primo livello.
Gli esperti consigliano di utilizzare una combinazione di tecniche per individuare le vulnerabilità di Log4j.
Ricerche manuali. I team addetti alla sicurezza possono cercare manualmente le falle di Log4j. Possono utilizzare strumenti di sviluppo come Apache Maven per generare alberi delle dipendenze che mappano tutte le dipendenze in un'app, oppure possono utilizzare threat intelligence esterna per identificare gli asset interessati. Ad esempio, la Cybersecurity and Infrastructure Security Agency (CISA) ha compilato un elenco di software noti per essere affetti da Log4Shell. L'elenco è disponibile su GitHub .
Sui sistemi operativi Linux, Microsoft Windows e macOS, i team addetti alla sicurezza possono cercare nelle directory dei file le istanze di Log4j utilizzando l'interfaccia a riga di comando.
Strumenti di scansione delle vulnerabilità. In seguito alla scoperta di Log4Shell, alcune organizzazioni hanno rilasciato strumenti gratuiti progettati per trovare le vulnerabilità di Log4j. Tra gli esempi figurano lo sniffer Log4j di Palantir e lo scanner del CERT Coordination Center.
Sebbene siano ancora disponibili scanner specializzati, molte soluzioni di sicurezza standard, come gli scanner di vulnerabilità, le piattaforme di gestione della superficie di attacco (ASM) e le soluzioni di rilevamento e risposta degli endpoint (EDR), possono ora rilevare le vulnerabilità Log4j.
Poiché Log4Shell può nascondersi in profondità nelle catene di dipendenze, i team addetti alla sicurezza possono integrare le scansioni automatiche con metodi più pratici, come i penetration test.
Rilevamento delle minacce. Secondo la CISA, è noto che gli aggressori usano Log4Shell per entrare in una rete e poi applicare patch agli asset che hanno compromesso per coprire le loro tracce. Per questo motivo, si consiglia ai team addetti alla sicurezza di presumere che sia già avvenuta una violazione e di cercare attivamente i segnali dell'utilizzo di Log4Shell.
Gli strumenti di cybersecurity come le soluzioni di gestione delle informazioni di sicurezza e degli eventi(SIEM) e le piattaforme di rilevamento e risposta esteso (XDR) possono aiutare a rilevare attività anomale associate a Log4Shell, come voci di log strane o pattern di traffico sospetti. I team addetti alla sicurezza dovrebbero avviare procedure complete di risposta agli incidenti e di indagine per ogni possibile accenno di Log4Shell, data la gravità delle conseguenze di un attacco.
I team addetti alla sicurezza hanno alcune opzioni per affrontare le vulnerabilità di Log4j.
Per la correzione completa di Log4Shell e dei relativi difetti, le organizzazioni devono aggiornare tutte le istanze di Log4j nelle loro reti alla versione più recente (o almeno alla versione 2.17.1). Le ultime versioni di Log4j rimuovono le funzioni che gli aggressori possono utilizzare e rimuovono il supporto per i protocolli comunemente usati, come LDAP.
Non è disponibile un'unica patch a livello di sistema e l'aggiornamento di Java non risolve il problema. I team addetti alla sicurezza devono aggiornare ogni istanza di Log4j in ogni asset interessato.
I ricercatori nel campo della sicurezza concordano sul fatto che le patch siano la soluzione ideale. Se l'applicazione delle patch non è fattibile, le organizzazioni possono utilizzare altre misure di mitigazione per ridurre al minimo le possibilità di attacco.
Disabilitare la ricerca dei messaggi nelle app vulnerabili. Gli aggressori utilizzano una caratteristica di Log4j chiamata "message lookup substitution" per inviare comandi dannosi alle app vulnerabili. I team addetti alla sicurezza possono disabilitare manualmente questa funzione modificando la proprietà di sistema "Log4j2.formatMsgNoLookups" su "true" o impostando il valore della variabile di ambiente "LOG4J_FORMAT_MSG_NO_LOOKUPS" su "true".
Sebbene la rimozione della funzione di message lookup substitution renda più difficile l'attacco da parte degli aggressori, non è infallibile. I criminali informatici possono comunque utilizzare CVE-2021-45046 per inviare ricerche JNDI dannose alle app con impostazioni non predefinite.
Rimuovere la classe JNDIlookup dalle app vulnerabili.In Log4j, la classe JNDIlookup regola il modo in cui il logger gestisce le ricerche JNDI. Se questa classe viene rimossa dalla directory delle classi di Log4j, le ricerche JNDI non possono più essere eseguite.
Apache sottolinea che è possibile utilizzare il seguente comando per rimuovere la classe JNDIlookup dalle app vulnerabili:
zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class
Sebbene questo metodo sia più efficace rispetto alla disabilitazione della ricerca dei messaggi, non impedisce agli aggressori di organizzare altri tentativi di exploit, come attivare attacchi denial-of-service tramite ricerche ricorsive.
Bloccare il potenziale traffico di attacco Log4Shell. I team addetti alla sicurezza possono utilizzare firewall delle applicazioni web (WAF), sistemi di rilevamento e prevenzione delle intrusioni (IDPS), EDR e altri strumenti di cybersecurity per intercettare il traffico da e verso i server controllati dagli aggressori, bloccando protocolli di uso comune come LDAP o RMI. I team addetti alla sicurezza possono anche bloccare gli indirizzi IP associati agli attacchi o le stringhe che gli aggressori usano comunemente nelle richieste dannose, come «jndi», «ldap» e «rmi».
Tuttavia, gli aggressori possono aggirare queste difese utilizzando nuovi protocolli e indirizzi IP oppure offuscando le stringhe dannose.
Mettere in quarantena gli asset colpiti. Se tutto il resto fallisce, i team addetti alla sicurezza possono mettere in quarantena gli asset interessati, in attesa di una patch. Un modo per farlo è posizionare gli asset vulnerabili in un segmento di rete isolato a cui non è possibile accedere direttamente da Internet. È possibile posizionare un WAF attorno a questo segmento di rete per una protezione aggiuntiva.
Uno degli aspetti più complicati della correzione di Log4Shell è che non sempre ci sono delle patch. Nel novembre 2022, Tenable ha segnalato che il 29% degli asset ancora vulnerabili a Log4Shell erano "ricorrenti", ovvero erano stati corretti, ma la falla si era ripresentata. Le ricorrenze si verificano quando gli sviluppatori utilizzano accidentalmente librerie software che contengono versioni senza patch di Log4j per creare o aggiornare app.
Sebbene gli sviluppatori possano esaminare più da vicino i framework che utilizzano, è facile non notare le versioni vulnerabili di Log4j quando sono contenute in diversi livelli nei file JAR.
L'implementazione di programmi formali di gestione delle vulnerabilità e gestione delle patch può offrire ai team addetti alla sicurezza un modo più efficace per monitorare gli asset in caso di ritorno delle vulnerabilità di Log4j. La scansione regolare delle vulnerabilità e i test di penetrazione possono aiutare a rilevare rapidamente nuove vulnerabilità, Log4Shell o altro. La gestione delle patch garantisce che le nuove vulnerabilità vengano chiuse non appena i vendor rilasciano le correzioni.