Gli esperti di sicurezza informatica commentano il gap di sicurezza log4j per il quale BSI ha dichiarato il livello di allerta rosso. Gli esperti di Barracuda Networks, Radar Cyber Security e ForeNova forniscono una valutazione della situazione.
Jonathan Tanner, ricercatore senior sulla sicurezza presso Barracuda Networks
Jonathan Tanner, Senior Security Researcher presso Barracuda Networks: "Poiché questa vulnerabilità consente l'esecuzione di codice in modalità remota, i rischi sono piuttosto elevati." (Immagine: Barracuda Networks).
In che modo le aziende possono identificare questa vulnerabilità nella loro tecnologia e quali sono i rischi se non viene risolta?
“Per prima cosa dovresti verificare se viene utilizzata una versione di log4j precedente alla 2.15.0, anche nelle dipendenze. Sia Maven che Gradle, entrambi strumenti di gestione della build basati su Java, offrono la possibilità di stampare l'intero albero delle dipendenze per un progetto. In questo modo è possibile determinare se viene utilizzata o meno una versione vulnerabile di log4j. Anche con la versione 2.15.0 o successiva, assicurati che la proprietà di sistema formatMsgNoLookups non sia impostata su 'true'.
L'unico motivo per cui questa versione non è vulnerabile è che ha impostato il valore predefinito da true a false. In alcune versioni di log4j, questa proprietà può essere facilmente impostata su false manualmente per mitigare la vulnerabilità. Se l'applicazione non richiede LDAP come parte del suo uso legittimo, è anche possibile bloccare tutto il traffico LDAP con un firewall o un filtro dell'applicazione Web per impedire il raggiungimento del codice remoto in caso di sfruttamento della vulnerabilità.
Tuttavia, questi controllano solo se log4j è in grado di sfruttare questa vulnerabilità RCE o meno. Se un sistema sia veramente vulnerabile o meno a un attacco è una questione molto più complicata senza un singolo test come le vulnerabilità come HeartBleed. Per sfruttare questa vulnerabilità, un utente malintenzionato dovrebbe eseguire un attacco di log injection. Trovarli è un processo molto più complesso, ma in pratica qualsiasi luogo in cui viene registrato l'input di un utente (o potenziale aggressore) può essere vulnerabile a questo attacco.
Quindi, per testare un RCE effettivo, si dovrebbe provare a trovare un modo per effettuare una richiesta LDAP JNDI all'interno dei log dal contesto utente stesso (ad esempio tramite il sito Web o l'API se l'applicazione potenzialmente interessata è un'applicazione Web). Poiché questa vulnerabilità consente l'esecuzione di codice in modalità remota, i rischi sono piuttosto elevati. Un utente malintenzionato potrebbe potenzialmente penetrare nella rete e tentare di accedere a risorse e dati importanti da lì.
Che ruolo ha svolto l'open source in questa vulnerabilità e quali sono le principali considerazioni sulla sicurezza per le organizzazioni che utilizzano strumenti come log4j?
“Poiché log4j è una libreria open source molto popolare, il numero di applicazioni vulnerabili era sicuramente più alto. In generale, qualsiasi software può essere vulnerabile agli attacchi e il popolare software open source spesso ha un ampio ecosistema che cerca e risolve le minacce alla sicurezza. Anche se il software open source cattura la maggior parte dei titoli quando vengono rilevate vulnerabilità importanti, ciò non significa che sia proporzionalmente meno sicuro (in effetti, è probabilmente molto più sicuro del codice proprietario o delle librerie meno popolari). La distribuzione diffusa aumenta solo la probabilità che vengano rilevate vulnerabilità, non necessariamente la probabilità che esistano.
Quando cercano librerie open source, le aziende dovrebbero scegliere progetti grandi, affidabili e ben mantenuti come log4j per i motivi di cui sopra. Ovviamente possono ancora esserci vulnerabilità, ma è più probabile che la comunità trovi e corregga tali vulnerabilità e verifichi anche che il codice sia privo di bug che potrebbero causare vulnerabilità in primo luogo, rispetto a progetti più piccoli.
Anche per coloro le cui applicazioni non sono vulnerabili a CVE-2021-44228 o che non utilizzano affatto log4j per la registrazione, questa vulnerabilità è sicuramente un campanello d'allarme che l'iniezione di log è un potenziale metodo che gli aggressori potrebbero utilizzare. Vale la pena verificare che tutto l'input utente registrato sia correttamente disinfettato in ogni applicazione, indipendentemente dal sistema di registrazione o persino dal linguaggio di programmazione utilizzato. Mentre altre forme di iniezione sono molto più comuni e sono al centro dell'interesse, l'iniezione di log è ancora una forma di attacco di iniezione e quindi rientra nelle prime 10 vulnerabilità di OWASP.
In che modo le aziende possono identificare questa vulnerabilità nella loro tecnologia e quali sono i rischi se non viene risolta?
“Per prima cosa bisogna verificare se viene utilizzata una versione di log4j precedente alla 2.15.0, anche nelle dipendenze. Sia Maven che Gradle, entrambi strumenti di gestione della build basati su Java, offrono la possibilità di stampare l'intero albero delle dipendenze per un progetto. In questo modo è possibile determinare se viene utilizzata o meno una versione vulnerabile di log4j. Anche con la versione 2.15.0 o successiva, assicurati che la proprietà di sistema formatMsgNoLookups non sia impostata su 'true'. L'unico motivo per cui questa versione non è vulnerabile è che ha impostato il valore predefinito da true a false.
In alcune versioni di log4j, questa proprietà può essere facilmente impostata su false manualmente per mitigare la vulnerabilità. Se l'applicazione non richiede LDAP come parte del suo uso legittimo, è anche possibile bloccare tutto il traffico LDAP con un firewall o un filtro dell'applicazione Web per impedire il raggiungimento del codice remoto in caso di sfruttamento della vulnerabilità. Tuttavia, questi controllano solo se log4j è in grado di sfruttare questa vulnerabilità RCE o meno. Se un sistema sia veramente vulnerabile o meno a un attacco è una questione molto più complicata senza un singolo test come le vulnerabilità come HeartBleed.
Per sfruttare questa vulnerabilità, un utente malintenzionato dovrebbe eseguire un attacco di log injection. Trovarli è un processo molto più complesso, ma in pratica qualsiasi luogo in cui viene registrato l'input di un utente (o potenziale aggressore) può essere vulnerabile a questo attacco. Quindi, per testare un RCE effettivo, si dovrebbe provare a trovare un modo per effettuare una richiesta LDAP JNDI all'interno dei log dal contesto utente stesso (ad esempio tramite il sito Web o l'API se l'applicazione potenzialmente interessata è un'applicazione Web).
Poiché questa vulnerabilità consente l'esecuzione di codice in modalità remota, i rischi in caso di vulnerabilità sono piuttosto elevati. Un utente malintenzionato potrebbe potenzialmente penetrare nella rete e tentare di accedere a risorse e dati importanti da lì.
Altro su Barracuda.com
Lothar Haensler, COO di Radar Cyber Security
Lothar Hänsler, COO di Radar Cyber Security: "La vulnerabilità è relativamente facile da sfruttare, gli attacchi possono essere facilmente nascosti." (Immagine: Radar Cyber Security).
comunque cosa è successo
“Lo scorso fine settimana è stata scoperta una vulnerabilità nel modulo log4j2 di Apache.org a cui è stato rapidamente assegnato un punteggio CVSS di 10, il livello di criticità più elevato. Autorità come l'Ufficio federale per la sicurezza delle informazioni (BSI) hanno rapidamente aumentato la loro valutazione del rischio, che inizialmente era arancione, a rosso".
Cosa rende questa vulnerabilità così speciale?
“Le vulnerabilità sono relativamente facili da sfruttare, gli attacchi possono essere facilmente oscurati (offuscamento). Inoltre, le misure difensive non sono facili da attuare. Uno dei motivi è che tutte le strategie di mitigazione possono avere rischi ed effetti collaterali sulle applicazioni interessate dalla vulnerabilità. Tuttavia, le valutazioni nei gruppi di esperti sono molto dinamiche e, di conseguenza, ci sono anche diverse prospettive sulle strategie di mitigazione”.
Cosa ha fatto esattamente Radar Cyber Security?
"Durante il fine settimana, abbiamo prima analizzato la situazione dei dati con una risposta agli incidenti, stimato l'impatto, utilizzato varie fonti di informazioni da piattaforme internazionali come i Computer Emergency Response Team (CERT) e progettato una strategia per affrontare questa minaccia. Infine, lunedì mattina, abbiamo inviato un avviso di sicurezza a tutti i nostri clienti. Il nostro Cyber Defense Center (CDC) è stato impostato in modalità di allerta alta.
Ora presta particolare attenzione al verificarsi della vulnerabilità nel modulo log4j2, senza trascurare la posizione di sicurezza complessiva. Abbiamo aggiornato i moduli di rilevamento per verificare e segnalare gli exploit di questa vulnerabilità ai nostri clienti. Questo va dalla gestione delle vulnerabilità ai classici servizi SIEM fino ai singoli strumenti di analisi della rete. Allo stesso tempo, abbiamo avviato un'analisi dei nostri sistemi. Dopo la prima scansione presso un primo cliente, sono stati identificati due incidenti critici in brevissimo tempo. Altri servizi speciali analizzano se i clienti sono specificamente interessati da questa vulnerabilità. In casi estremi, potrebbe essere necessario spegnere i sistemi”.
Altro su RadarCS.com
Paul Smith, direttore dei servizi professionali di ForeNova
Paul Smit, direttore dei servizi professionali di ForeNova: "La vulnerabilità zero-day in log4j è estremamente pericolosa perché può essere sfruttata direttamente senza ricaricare esplicitamente il codice dannoso." (Immagine: ForeNova).
“La vulnerabilità zero-day nella libreria Java log4j ampiamente utilizzata è estremamente pericolosa perché la vulnerabilità può essere sfruttata direttamente senza ricaricare esplicitamente il codice dannoso. Tuttavia, se ciò accadrà immediatamente o meno, lo si potrà vedere solo quando sarà troppo tardi. Un endpoint può essere compromesso, ma non ancora sotto gli occhi degli hacker. In questo momento, sta diventando evidente la necessità per le piccole e medie imprese di considerare il rilevamento e la risposta della rete e il rilevamento e la risposta degli endpoint insieme come una strategia di difesa completa. EDR verifica se il malware è stato installato e organizza la difesa sull'endpoint.
Guarda il passato con NDR
Con NDR, puoi anche vedere retrospettivamente nei dati di registrazione a quali sistemi gli hacker hanno cercato di accedere dall'esterno. Il rapporto di mancato recapito rileva anche il traffico tipico derivante da tale tentativo di accesso, ad esempio la comunicazione con i server C2C, la scansione delle porte e il traffico specifico. Il rapporto di mancato recapito consente inoltre il blocco e la segmentazione delle reti o la quarantena dei sistemi, una misura che deve essere adottata in caso di dubbio. Una soluzione NDR come NovaComand analizza anche i dati di telemetria dagli endpoint. NovaCommand ha rilasciato una patch e aggiornato le regole per rilevare un simile attacco. NovaCommand attiva anche altre soluzioni di terze parti per bloccare e segmentare i sistemi e le sezioni di rete interessati.
Altro su ForeNova.com
Articoli relativi all'argomento