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.

Una vulnerabilità in una libreria open source comune nello spazio Web3 impatta la sicurezza dei contratti intelligenti pre-costruiti, influenzando diverse collezioni di NFT, inclusa Coinbase.

Come Funziona l’Attacco?

La vulnerabilità è stata scoperta da ricercatori della piattaforma di sviluppo Web3 Thirdweb, che hanno rilevato che la maggior parte dei gestori di password per Android è vulnerabile ad AutoSpill, anche senza iniezione di JavaScript. Le app Android spesso utilizzano i controlli WebView per visualizzare contenuti web, come pagine di login all’interno dell’app. I gestori di password su Android utilizzano il framework WebView della piattaforma per digitare automaticamente le credenziali dell’utente quando un’app carica la pagina di login di servizi come Apple, Facebook, Microsoft o Google. È possibile sfruttare le debolezze in questo processo per catturare le credenziali compilate automaticamente sull’app che le richiama.

Contratti Smart Impattati

I seguenti contratti smart sono impattati dalla vulnerabilità:

• AirdropERC20 (v1.0.3 e successivi), ERC721 (v1.0.4 e successivi), ERC1155 (v1.0.4 e successivi) ERC20Claimable, ERC721Claimable, ERC1155Claimable
• BurnToClaimDropERC721 (tutte le versioni)
• DropERC20, ERC721, ERC1155 (tutte le versioni)
• LoyaltyCard
• MarketplaceV3 (tutte le versioni)
• Multiwrap, Multiwrap_OSRoyaltyFilter
• OpenEditionERC721 (v1.0.0 e successivi)
• Pack e Pack_OSRoyaltyFilter
• TieredDrop (tutte le versioni)
• TokenERC20, ECRC721, ERC1155 (tutte le versioni)
• SignatureDrop, SignatureDrop_OSRoyaltyFilter
• Split (basso impatto)
• TokenStake, NFTStake, EditionStake (tutte le versioni)

Misure di Mitigazione

I proprietari di contratti smart devono adottare misure di mitigazione immediatamente per tutti i contratti pre-costruiti creati prima del 22 novembre 2023, alle 19:00 PT. Il consiglio è di bloccare i contratti vulnerabili, fare uno snapshot e poi migrarli a un nuovo contratto creato con una versione non vulnerabile della libreria. Thirdweb ha condiviso i dettagli dell’exploit con i manutentori della libreria interessata e ha affermato di non aver visto la vulnerabilità essere sfruttata in attacchi.

Risposte da Coinbase e Altri

Coinbase NFT ha annunciato che ha appreso della vulnerabilità venerdì scorso e che influisce su alcune delle sue collezioni create con Thirdweb. Mocaverse ha aggiornato i suoi utenti che i loro asset sono al sicuro e che ha “aggiornato con successo i contratti smart della collezione NFT Mocaverse, Lucky Neko e Mocaverse Relic per chiudere la rilevante vulnerabilità di sicurezza”. OpenSea ha annunciato che sta lavorando a stretto contatto con Thirdweb per mitigare i rischi coinvolti e prevede di assistere gli utenti colpiti. alcuni utenti hanno invece lamentato una mancanza di trasparenza da parte di ThirdWeb sulla scoperta da loro denunciata.