log4shell
IWS21

Da quando la vulnerabilità Log4J oppure Log4Shell è stata scoperta, per alcuni esperti di sicurezza è stato come vivere uno di quei film catastrofici nei quali il conto alla rovescia verso la fine incombe inesorabilmente sul mondo. Questo problema di sicurezza riguarda una delle librerie di log più diffuse in Java (ossia di raccolta dei messaggi di sistema sotto forma di elenco per analizzare gli eventi). È come una bomba che, nonostante le patch e gli aggiornamenti, sta per esplodere e secondo molti non è stata ancora capita la magnitudo e la portata delle singole criticità puntuali che affliggono ogni singolo sistema o piattaforma. Non a caso è stata definita la più grande problematica di cyber sicurezza dell’ultimo decennio. Come nei suddetti film, la fine incombe, si sa cosa succederà ma allo stato attuale le poche e limitate soluzioni permettono di rilevare potenziali attacchi e mitigare gli exploit per quanto possibile. Gli hacker più agguerriti sanno come trarne vantaggio e (forse) lo stanno già facendo in modi ancora tutti da esplorare.

Dice Lotem Finkelstein, Head of Threat Intelligence per Check Point Software Technologies: “Questa è chiaramente una delle vulnerabilità più gravi su Internet negli ultimi anni, e si sta diffondendo a vista d’occhio. Ad un certo punto, abbiamo visto più di 100 attacchi al minuto relativi alla vulnerabilità LogJ4. Stiamo assistendo a un’evoluzione continua, con nuove variazioni dell’exploit originale che vengono introdotte rapidamente: oltre 60 in meno di 24 ore. Il numero di combinazioni possibili fornisce all’hacker molte alternative per aggirare le protezioni appena introdotte. A differenza di altri grandi attacchi informatici che coinvolgono uno o un numero limitato di software, Log4j è fondamentalmente incorporato in ogni prodotto o servizio web basato su Java. È molto difficile rimediare manualmente. Quelli che non vogliono implementare una protezione sono probabilmente già controllati dagli hacker. Abbiamo già documentato più di 846.000 attacchi, dove più del 40% delle reti aziendali a livello globale sono state prese di mira. Questa vulnerabilità, a causa della complessità della patch e della facilità di sfruttamento, rimarrà con noi per gli anni a venire, a meno che non agiamo immediatamente per prevenire gli attacchi. Ora è il momento di agire. La minaccia è imminente, e considerando il periodo natalizio, i team di sicurezza potrebbero essere più lenti a implementare le misure di protezione. È come una pandemia informatica: altamente contagiosa, si diffonde rapidamente e ha più varianti, e quindi più modi per attaccare”.

Finora, i ricercatori hanno osservato gli aggressori che utilizzano la vulnerabilità Log4j per installare ransomware sui server honeypot, ossia sistemi resi deliberatamente vulnerabili allo scopo di tracciare nuove minacce. Una società di sicurezza informatica ha riferito che quasi la metà delle reti aziendali che stava monitorando è stata oggetto di diversi tentativi di sfruttare la vulnerabilità. Il ceo di Cloudflare ha annunciato all’inizio che la minaccia era così grave e l’azienda avrebbe implementato la protezione firewall per tutti i clienti, compresi quelli che non l’avevano pagata. Ma le notizie concrete sullo sfruttamento di Log4J rimangono scarse, probabilmente perché le vittime non sanno o non vogliono ancora riconoscere pubblicamente che i loro sistemi sono stati violati.

Qualcosa, però, si conosce e con certezza: la portata potenziale e reale della vulnerabilità è enorme. Un elenco di software interessati compilato dalla Cybersecurity and Infrastructure Security Agency (CISA) – e limitato alle sole piattaforme software aziendali – contiene più di 500 referenze: l’elenco dei software affetti da Log4J, con indicazione precisa la criticità è stata corretta, è consultabile in questa pagina. Un elenco esaustivo di tutte le applicazioni interessate potrebbe senza dubbio arrivare a molte altre migliaia.

Alcuni nomi che si individuano nell’elenco sopra indicato saranno familiari al pubblico: spiccano Amazon, IBM, Microsoft, SalesForce, McAfee, Lenovo, HPE e Cisco. Ma alcuni dei problemi più allarmanti sono relativi ai software che operano “dietro le quinte”, come per esempio le soluzioni di Broadcom, Red Hat e VMware, che di fatto rappresentano piattaforme aziendali di livello infrastrutturale su cui poggiano servizi e software. Ciò rende il processo di rilevamento ed eliminazione delle vulnerabilità ancora più difficile, anche dopo il rilascio di una patch per la libreria interessata e che ha dato origine a Log4J.

La patch per Log4J e le aspettative in parte deluse

Una seconda vulnerabilità che coinvolge Apache Log4J è stata rilevata nel corso della settimana dopo che gli esperti di sicurezza informatica hanno trascorso giorni a tentare di correggere o mitigare la vulnerabilità CVE-2021-44228. In termini tecnici, è emersa una nuova vulnerabilità denominata CVE 2021-45046, che è scaturita dopo la correzione di quella originaria CVE-2021-44228 in Apache Log4J 2.15.0 a sua volta identificata come “incompleta in alcune configurazioni non predefinite”. 

“Ciò potrebbe consentire agli aggressori (…) di creare dati di input dannosi utilizzando un modello di ricerca JNDI con conseguente attacco Denial of Service (DOS)”, si legge nella descrizione ufficiale CVE della vulnerabilità successiva alla correzione di quella originale di Log4Shell.  

Apache ha già rilasciato una ulteriore patch, Log4J 2.16.0, per risolvere una volta per tutte questo problema. Il CVE afferma che Log4j 2.16.0 risolve il problema rimuovendo il supporto per le routine di ricerca dei messaggi (semplificando, quelli generati per fotografare lo stato del sistema e gli eventi in corso) e disabilitando la funzionalità JNDI come impostazione predefinita. Si noti che la vulnerabilità può essere “mitigata” nelle versioni precedenti rimuovendo la classe JndiLookup dal classpath. In aggiunta, andrebbe disattivata completamente la funzione JNDI.

“Almeno una dozzina di gruppi di hacker stanno utilizzando queste vulnerabilità, quindi è necessario intraprendere un’azione immediata per correggere, rimuovere JNDI o rimuoverlo dal percorso di classe (preferibilmente tutto quanto sopra)”, spiegano gli esperti di sicurezza. 

Il difetto originale in Log4J, la libreria Java per la registrazione dei messaggi di errore nelle applicazioni, sta dominando i titoli online e offline da diversi giorni, ma i primi exploit risalgono a inizio dicembre. Quantomeno stando alle analisi di Cloudflare e a un allarme iniziale del CERT New Zealand, che ha innescato una catena di allerte da parte della CISA e del National Cyber ​​Security Centre del Regno Unito. Il National Cyber ​​Security Center olandese ha pubblicato un lungo elenco di software interessati dalla vulnerabilità.

Eset, società specializzata in sicurezza, ha pubblicato una mappa che mostra dove sono stati eseguiti i tentativi di sfruttamento di Log4J, con il volume più alto che si è verificato negli Stati Uniti, nel Regno Unito, in Turchia, in Germania e nei Paesi Bassi. Gli aggressori prendono di mira server fisici, server virtuali, telecamere IP, dispositivi di produzione e sistemi di presenza.

image001-4.png
Roman Kováč, Chief Research Officer di ESET, ha commentato i risultati: “Il volume delle nostre rilevazioni conferma che si tratta di un problema su larga scala che non si risolverà in breve tempo. Certamente, gli aggressori stanno testando molte varianti di exploit, ma non tutti i tentativi di sfruttamento sono necessariamente malevoli. Alcuni possono essere benigni, considerando che i ricercatori, le aziende di infosec e i penetration tester stanno anche testando gli exploit per scopi di difesa”.

Bitdefender spiega ancora meglio la problematica: “Log4j è una libreria open source, parte degli Apache Logging Services, scritta in Java. La versione originale del Java Development Kit (JDK) non includeva API di logging, quindi le librerie di logging Java hanno rapidamente guadagnato popolarità, compresa Log4j. La libreria Log4j è ampiamente utilizzata da altri framework, come Elasticsearch, Kafka e Flink, che sono alla base di molti siti e servizi web popolari. Java è un framework multipiattaforma, e questa vulnerabilità non è limitata alle applicazioni in esecuzione su uno specifico sistema operativo. Tutte le applicazioni che utilizzano il framework in esecuzione su sistemi operativi come Windows, Linux, macOS e FreeBSD sono vulnerabili. Java alimenta web cam, sistemi di navigazione per auto, lettori DVD e set-top box, vari terminali e persino parchimetri e dispositivi medici. Di conseguenza, questa vulnerabilità ha un effetto a catena molto significativo sulla supply chain del software, ed è difficile prevedere la portata totale e l’impatto a lungo termine della vulnerabilità”.

Log4Shell sta colpendo una parte immensa di Internet

Anche prendendo in esame gli standard delle vulnerabilità di alto profilo, stupisce come Log4Shell stia colpendo una parte insolitamente grande di Internet. È un riflesso del fatto che il linguaggio di programmazione Java è ampiamente utilizzato nel software aziendale e, per il software Java, la libreria Log4j è estremamente comune.

La scoperta di un bug facilmente sfruttabile trovato in un linguaggio prevalentemente aziendale fa parte di quella che gli analisti hanno definito una “tempesta quasi perfetta ” attorno alla vulnerabilità di Log4J. Qualsiasi azienda potrebbe utilizzare numerosi programmi contenenti la libreria vulnerabile, in alcuni casi con più versioni all’interno di un’applicazione.

Aparna Rayasam, SVP & GM Application Security di Akamai Technologies, spiega bene la portata del problema: “Sebbene Akamai abbia osservato per la prima volta dei tentativi di exploit sulla vulnerabilità log4j il 9 dicembre a seguito della pubblicazione diffusa dell’incidente, sono emersi degli indizi secondo cui questi tentativi potrebbero essere in atto da mesi. Stiamo espandendo la nostra analisi dei dati per ricercarne le prove. L’ampia visibilità di Akamai ci dà l’opportunità di eseguire ricerche di dati esaustive e ottenere visibilità sulle molteplici varianti man mano che si evolvono. Da quando la vulnerabilità è stata resa nota abbiamo osservato numerose varianti che cercano di sfruttarla, con un volume sostenuto di traffico in attacco di 250K richieste di exploit all’ora. La velocità con cui le varianti si stanno evolvendo è senza precedenti: più della metà degli attacchi visti finora provengono da aggressori precedentemente classificati come malintenzionati nel database di threat intelligence di Akamai. Continuiamo a sostenere la necessità di patch urgenti. Prevediamo, infatti, che a causa dell’enorme volume di sistemi senza patch, continueremo a osservare tentativi di exploit ancora per diversi mesi. I team di security research e incident response di Akamai continuano a monitorare e proteggere la nostra infrastruttura e i nostri clienti sfruttando la nostra visibilità e intelligence”.

Date le circostanze, concetti come “il più velocemente possibile” è un termine molto soggettivo. Gli aggiornamenti software per organizzazioni come banche, ospedali o agenzie governative sono generalmente condotti su una scala di settimane e mesi, non di giorni; in genere, gli aggiornamenti richiedono numerosi livelli di sviluppo, autorizzazione e test prima di essere introdotti in un’applicazione attiva.

Log4J: l’eterna battaglia tra open source, sicurezza e sottovalutazione dei rischi

Nel frattempo, le mitigazioni che possono essere eliminate rapidamente forniscono un passaggio intermedio cruciale, guadagnando tempo prezioso mentre le aziende grandi e piccole si affannano per identificare le vulnerabilità e distribuire gli aggiornamenti. È qui che le correzioni a livello di rete hanno un ruolo chiave da svolgere: poiché i programmi malware comunicano con i loro operatori su Internet, le misure che limitano il traffico Web in entrata e in uscita possono fornire un palliativo per limitare gli effetti dell’exploit.

Per esempio, cloudflare è stata un’organizzazione che si è mossa rapidamente, ha spiegato Graham-Cumming, aggiungendo nuove regole per il suo firewall che bloccava le richieste HTTP contenenti stringhe caratteristiche del codice di attacco Log4J. ExpressVPN ha anche modificato il suo software per proteggerlo da Log4Shell, aggiornando le regole VPN per bloccare automaticamente tutto il traffico in uscita sulle porte utilizzate da LDAP, un protocollo che l’exploit utilizza per recuperare risorse da URL remoti e scaricarle su una macchina vulnerabile.

Queste modifiche in genere avvengono più velocemente perché avvengono su server appartenenti alle società firewall o VPN e richiedono poca (se nessuna) azione da parte dell’utente finale. In altre parole, un’applicazione software obsoleta potrebbe ancora ricevere un livello di protezione decente da una VPN aggiornata, sebbene non sostituisca l’applicazione di patch adeguate.

Sfortunatamente, data la gravità della vulnerabilità, alcuni sistemi saranno compromessi, anche con soluzioni rapide implementate. E potrebbe volerci molto tempo, persino anni, prima che gli effetti si sentano pienamente.

“Gli aggressori sofisticati sfrutteranno la vulnerabilità, stabiliranno un meccanismo di persistenza e poi si sposteranno”, afferma Daniel Clayton, vicepresidente dei servizi di sicurezza informatica globale di Bitdefender. “Tra due anni sentiremo parlare di gravi violazioni e poi apprenderemo che sono state violate due anni fa”.

Il bug in Log4J evidenzia ancora una volta la necessità e la sfida di finanziare adeguatamente i progetti open source. Bloomberg ha pubblicato un articolo secondo cui molti degli sviluppatori coinvolti nella gara per sviluppare una patch per la libreria Log4J sono stati volontari non pagati, nonostante l’uso globale del software nelle applicazioni aziendali.

Una delle più recenti vulnerabilità a scuotere Internet, Heartbleed, è stata causata in modo simile da un bug in una libreria open source ampiamente utilizzata, OpenSSL. A seguito di questo, aziende tecnologiche come Google, Microsoft e Facebook si sono impegnate a investire più denaro in progetti open source fondamentali per l’infrastruttura Internet. Ma sulla scia di Log4J, è chiaro che la gestione delle correlazioni tra open source e sicurezza rimane un serio problema enorme e con gli approcci adottati finora non ci si avvicina a risolverlo. Anche perché c’è un segnale “debole” che non sfugge all’attenzione: tutti gli attacchi sofisticati passano da vulnerabilità relativamente semplici o basilari. A volte considerate così di secondo piano che, spesso, non sono aggiornate con la dovuta cura, perizia e tempestività. E sottovalutandole, si mette a repentaglio l’intera infrastruttura IT aziendale o privata.