Nonostante siano disponibili patch da oltre due anni, circa il 38% delle applicazioni che utilizzano la libreria Apache Log4j impiegano una versione vulnerabile a problemi di sicurezza, inclusa la critica vulnerabilità Log4Shell, identificata come CVE-2021-44228.

Dettagli sulla vulnerabilità Log4Shell

Log4Shell è una falla di esecuzione remota di codice (RCE) non autenticata che consente il controllo completo sui sistemi con Log4j dalla versione 2.0-beta9 fino alla 2.15.0. Scoperta come zero-day attivamente sfruttata il 10 dicembre 2021, ha avuto un impatto diffuso, facilità di sfruttamento e gravi implicazioni per la sicurezza, attirando l’attenzione di numerosi attori minacciosi.

Risposta alla Vulnerabilità

Nonostante le numerose campagne di sensibilizzazione rivolte ai responsabili dei progetti e agli amministratori di sistema, molte organizzazioni hanno continuato a utilizzare versioni vulnerabili di Log4j a lungo dopo la disponibilità delle patch.

Dati e Statistiche

Un rapporto della società di sicurezza delle applicazioni Veracode, basato su dati raccolti tra il 15 agosto e il 15 novembre, evidenzia che il 2,8% delle applicazioni utilizza varianti di Log4J vulnerabili a Log4Shell. Un ulteriore 3,8% utilizza Log4j 2.17.0, vulnerabile a CVE-2021-44832, mentre il 32% impiega la versione 1.2.x di Log4j, che ha raggiunto la fine del supporto nell’agosto 2015 e presenta molteplici vulnerabilità gravi.

Questo dato si avvicina a quello riportato dagli esperti di gestione della catena di fornitura del software di Sonatype nel loro dashboard Log4j, dove il 25% dei download della libreria nell’ultima settimana riguarda versioni vulnerabili.

Pratiche di Sicurezza Inadeguate

L’uso continuato di versioni obsolete della libreria indica un problema persistente, attribuito da Veracode alla riluttanza degli sviluppatori ad aggiornare le librerie di terze parti per evitare complicazioni. Il 79% degli sviluppatori sceglie di non aggiornare mai le librerie di terze parti dopo la loro inclusione iniziale nel codice, anche se il 65% degli aggiornamenti delle librerie open-source contiene modifiche minori e correzioni improbabili di causare problemi funzionali.

Raccomandazioni

La raccomandazione per le aziende è di scansionare il proprio ambiente, individuare le versioni delle librerie open-source in uso e sviluppare un piano di aggiornamento d’emergenza per tutte.

I dati mostrano che Log4Shell non è stato il campanello d’allarme che molti nel settore della sicurezza speravano. Log4j continua a essere una fonte di rischio in 1 caso su 3 e può essere facilmente uno dei molteplici modi in cui gli aggressori possono sfruttare per compromettere un obiettivo.

Un attore di minaccia precedentemente non documentato, denominato Aeroblade, è stato collegato a un attacco informatico contro un’organizzazione aerospaziale negli Stati Uniti, sospettato di essere parte di una missione di cyber spionaggio.

Dettagli dell’Attacco di Aeroblade

Il team di ricerca e intelligence di BlackBerry sta monitorando il cluster di attività di Aeroblade. L’origine dell’attore è attualmente sconosciuta e non è chiaro se l’attacco sia stato riuscito.

L’attore ha utilizzato il spear-phishing come meccanismo di consegna: un documento armato, inviato come allegato email, contiene una tecnica di iniezione di template remoto incorporata e un codice macro VBA maligno, per consegnare la fase successiva all’esecuzione del payload finale.

Infrastruttura di Rete e Fasi dell’Attacco

L’infrastruttura di rete utilizzata per l’attacco è stata attivata intorno a settembre 2022, con la fase offensiva dell’intrusione che si è verificata quasi un anno dopo, a luglio 2023. L’attacco iniziale, avvenuto a settembre 2022, è iniziato con un’email di phishing contenente un allegato di Microsoft Word che, una volta aperto, ha utilizzato una tecnica chiamata iniezione di template remoto per recuperare un payload della fase successiva che viene eseguito dopo che la vittima abilita le macro.

Capacità di Raccolta Informazioni

La catena di attacco ha infine portato al dispiegamento di una libreria a collegamento dinamico (DLL) che funziona come un reverse shell, connettendosi a un server di comando e controllo (C2) codificato e trasmettendo informazioni di sistema agli attaccanti. Le capacità di raccolta di informazioni includono anche l’enumerazione dell’elenco completo delle directory sull’host infetto, indicando che potrebbe trattarsi di uno sforzo di ricognizione effettuato per vedere se la macchina ospita dati di valore e aiutare gli operatori a pianificare i loro prossimi passi.

Tecniche Anti-Analisi e Persistenza

La DLL fortemente offuscata è dotata anche di tecniche anti-analisi e anti-disassemblaggio per renderla difficile da rilevare e smontare, evitando l’esecuzione in ambienti sandboxati. La persistenza è ottenuta tramite un Task Scheduler, in cui viene creato un task denominato “WinUpdate2” per essere eseguito ogni giorno alle 10:10.

Una nuova ricerca ha scoperto che oltre 15.000 repository di moduli Go su GitHub sono vulnerabili a un attacco chiamato repojacking. Più di 9.000 repository sono vulnerabili a repojacking a causa di cambiamenti nel nome utente di GitHub, mentre più di 6.000 sono vulnerabili a causa della cancellazione dell’account. Collettivamente, questi repository rappresentano non meno di 800.000 versioni di moduli Go.

Cos’è il RepoJacking?

Repojacking, una combinazione delle parole “repository” e “hijacking” (dirottamento), è una tecnica di attacco che consente a un malintenzionato di sfruttare i cambiamenti del nome utente dell’account e le cancellazioni per creare un repository con lo stesso nome e il precedente nome utente per organizzare attacchi alla catena di fornitura di software open-source.

Vulnerabilità dei Moduli Go

I moduli scritti nel linguaggio di programmazione Go sono particolarmente suscettibili a repojacking, poiché, a differenza di altre soluzioni di gestione dei pacchetti come npm o PyPI, sono decentralizzati in quanto vengono pubblicati su piattaforme di controllo versione come GitHub o Bitbucket. Un attaccante può registrare il nome utente non più utilizzato, duplicare il repository del modulo e pubblicare un nuovo modulo su proxy.golang.org e go.pkg.dev.

Misure di prevenzione di GitHub

Per prevenire che gli sviluppatori scarichino pacchetti potenzialmente non sicuri, GitHub ha messo in atto una contromisura chiamata “popular repository namespace retirement” che blocca i tentativi di creare repository con i nomi di spazi dei nomi ritirati che sono stati clonati più di 100 volte prima che gli account dei proprietari venissero rinominati o cancellati. Tuttavia, questa protezione non è utile per i moduli Go, poiché sono memorizzati nella cache dal modulo mirror, eliminando la necessità di interagire o clonare un repository.

Risposta e mitigazione

Jacob Baines, chief technology officer di VulnCheck, ha affermato che mitigare tutti questi repojacking è qualcosa che Go o GitHub dovranno affrontare. Fino ad allora, è importante che gli sviluppatori Go siano consapevoli dei moduli che utilizzano e dello stato del repository da cui i moduli provengono.

La divulgazione arriva anche mentre Lasso Security ha scoperto 1.681 token API esposti su Hugging Face e GitHub, inclusi quelli associati a Google, Meta, Microsoft e VMware, che potrebbero essere potenzialmente sfruttati per organizzare attacchi alla catena di fornitura, avvelenamento dei dati di addestramento e furto di modelli.