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:

• La coda di attacco sarà molto lunga. A causa dell’ampio utilizzo di questo software e del gran numero di varianti di exploit, i tentativi di exploit proseguiranno per diversi mesi. È altamente probabile che molte delle violazioni verranno scoperte solo in futuro.
• I cyber criminali hanno utilizzato injection opportunistiche e i loro attacchi sono diventati più mirati. Gli attaccanti hanno cercato di identificare qualsiasi punto di injection disponibile. Sono partiti da quelli più scontati, come lo user agent, per poi mettersi alla ricerca dei parametri specifici delle organizzazioni target.
• Le conseguenze della fase di ricognizione potrebbero non essere pienamente comprese per mesi. La maggior parte dell'attività osservata da Akamai era di ricognizione/test. La percentuale di attacchi effettivi era molto inferiore. Questo significa che al momento non è possibile sapere quante violazioni siano realmente avvenute e quale ne sia stata la portata.

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.

Provenienza geografica degli attacchi

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.

Tecniche e tattiche d’attacco

È 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.

Log4Shell: un sintomo di un problema profondamente radicato

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.