L’analisi di Akamai e le considerazioni di Trend Micro ampliano la conoscenza delle implicazioni legate agli attacchi che sfruttano Log4Shell e di quello che avrebbe potuto semplificare la difesa informatica.
Autore: Redazione SecurityOpenLab
Il 57% dell'infrastruttura di attacco che invia exploit Log4j era già nota da attacchi precedenti. Serviranno mesi per comprendere le conseguenze degli attacchi che si stanno verificando e che stanno diventando sempre più mirati. Dopo Stati Uniti, regno Unito e Canada, l’Italia è quarto il Paese più colpito da questa ondata di attacchi. Sono, in estrema sintesi, i risultati principali dell’analisi di threat intelligence condotta da Akamai in relazione all’escalation di attacchi che sfrutta la falla Log4Shell.
Il punto di vista di Akamai è interessante nella misura in cui l’azienda dispone di una rete che ha visibilità sul traffico web proveniente da 1,3 miliardi di dispositivi unici al giorno, con un traffico record di 182 Tbps. È analizzando questo traffico che gli esperti di security dell’azienda hanno calcolato il numero di tentativi di sfruttamento di Log4Shell e gli exploit impiegati.
Da questa analisi sono emersi tre aspetti principali:
Il dato più inquietante dell’analisi di Akamai è che circa il 57% dell'infrastruttura di attacco che inviava exploit Log4j era già nota da attacchi precedenti. Questo significa che l’ondata di attacchi è stato provocato da attori malevoli già esistenti che hanno semplicemente colto l’opportunità, oltre che da nuovi attaccanti.
Un’altra informazione interessante è quella relativa alla provenienza geografica degli attacchi. La prima ondata proveniva da Stati Uniti, Singapore, Germania e Brasile. Tuttavia le geografie erano altamente distribuite che alcuni attacchi sono partiti da server ospitati da cloud provider di alta caratura, 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. Questa frammentazione non consente di identificare o di risalire a nessuno degli attori malevoli coinvolti.
È già noto che l'evoluzione delle varianti di exploit di Log4j non ha precedenti nella storia. Il dato nuovo introdotto da Akamai è che gli aggressori hanno iniettato il payload dell'exploit in più punti di ingresso. Il luogo più comune in cui l'exploit è stato iniettato sono 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”. Ogni intestazione immaginabile è stata un obiettivo per l'iniezione, compresi Cookie, Referer, X-Forwarded-For e Connection.
La maggior parte degli attaccanti 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.
Oltre al beacon di blind reconnaissance, molti degli attaccanti stavano già cercando di esfiltrare dati utili come l'hostname della macchina e dati ambientali, anche estraendo le chiavi AWS per facilitare il take over dell'account AWS.
Sono stati utilizzati anche servizi di tunnel inversi 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 attaccante 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.
Come accennato a suo tempo, buona parte delle difficoltà che le aziende stanno incontrando e incontreranno nel tentativo di mettere tutti i propri asset in sicurezza è la mancanza di un inventario digitale. Su questo punto è tornata Trend Micro parlando di SBOM (Software Bill Of Materials). Consiste nel costruire una distinta base software che elenca tutti i componenti utilizzati per costruire le applicazioni.
Si potrebbe paragonare lo SBOM all’elenco degli ingredienti presente sulle confezioni di cibo: le persone lo consultano per controllare la presenza di allergeni o per sincerarsi di avere una dieta sana. Nell’ambito software, uno SBOM aiuta a diagnosticare il software contaminato da qualsiasi minaccia, in qualsiasi momento. Il problema è che oggi pochissime aziende dispongono di uno SBOM completo, e quello che sta accadendo è un chiaro segnale del fatto che predisporne uno è diventato prioritario.
Gli esperti sottolinea infatti che una efficiente sicurezza delle applicazioni comporta molto di più che verificare la presenza di vulnerabilità note o introdurre procedure di sicurezza esclusivamente nella fase di sviluppo. Per essere veramente pronte a rispondere a un attacco zero-day come Log4Shell, un'azienda deve obbligatoriamente disporre di una posizione di sicurezza sempre attiva, che raggiunga tutti gli angoli del suo portafoglio di asset.