Sintesi Tecnica: Oltre il Takedown: Misurare la Persistenza di Moduli Go Maliziosi nel Mondo Reale

Definizione del Problema

L'ecosistema Go, un pilastro per l'infrastruttura software moderna, è sempre più preso di mira da attacchi alla supply chain. A differenza di altri ecosistemi tradizionali (ad esempio, npm, PyPI) dove gli attacchi sono ben documentati, Go presenta sfide uniche a causa del suo modello di esecuzione e della sua infrastruttura di distribuzione. Gli attaccanti stanno riimpacchettando moduli Go legittimi sotto account controllati dagli attaccanti, incorporando codice offuscato che si attiva al momento dell'importazione.

Esiste un divario critico tra i takedown al livello di hosting (rimozione dei repository da GitHub) e la rimediazione dell'ecosistema. Il modello di distribuzione di Go si affida a proxy.golang.org e index.golang.org per garantire la riproducibilità. Una volta che una versione di un modulo malizioso viene pubblicata e memorizzata nella cache dal proxy, essa rimane immutabile e recuperabile anche dopo che il repository sorgente originale è stato eliminato o sospeso. Di conseguenza, affidarsi esclusivamente alla visibilità centrata su GitHub non riesce a catturare l'intera estensione del compromesso né a garantire una vera rimediazione.

Metodologia

Gli autori hanno impiegato un approccio di misurazione a due fasi e complementari per catturare l'impronta della campagna sia nel livello di hosting che nel livello di distribuzione.

Fase 1: Scoperta Manuale (Dataset M)

• Ambito: Una ricerca manuale attraverso i repository GitHub condotta tra marzo e giugno 2025.
• Tecnica: I ricercatori sono partiti da un set iniziale di repository maliziosi noti e si sono espansi tramite "pivoting basato sugli stargazer", identificando account che coordinatamente avevano messo la stella a più moduli maliziosi.
• Verifica: I candidati sono stati filtrati utilizzando pre-filtri basati su parole chiave (ad esempio, exec.Command, /bin/sh, .Start()) e verificati manualmente per garantire che contenessero stringhe offuscate che ricostruivano comandi di fetch-and-execute (ad esempio, wget o curl seguiti da esecuzione).
• Risultato: Una linea di base ad alta confidenza di 2.113 repository maliziosi ($|M| = 2.113$).

Fase 2: Misurazione Automatica del Livello di Distribuzione (Dataset G)

• Ambito: Una scansione su larga scala dell'infrastruttura di distribuzione di Go utilizzando index.golang.org e proxy.golang.org.
• Strumento: Gli autori hanno sviluppato GOAST (Go AST-based Scanner for Threat), un motore di analisi statica progettato per rilevare firme specifiche di una campagna piuttosto che malware generici.
  • GOAST analizza i file sorgente Go in Abstract Syntax Trees (AST).
  • Identifica le chiamate di generazione di processi (exec.Command combinato con Start, Run o Output).
  • Esegue una propagazione leggera dei valori intra-procedurali per ricostruire gli argomenti delle stringhe offuscate.
  • Segnala un modulo come malizioso solo se una chiamata di esecuzione ricostruita è accoppiata a un'istruzione di download (ad esempio, wget/curl verso un URL HTTP(S)).
• Raccolta Dati: Il team ha raccolto un feed cronologico di 12,3 milioni di voci di indice da luglio 2024 a luglio 2025. Dopo la deduplicazione e il filtraggio per comportamenti di condivisione del nome (clonazione di nomi di moduli legittimi), hanno scansionato 60.232 candidati sospetti.
• Risultato: 2.289 versioni di moduli maliziosi confermati ($|G| = 2.289$).

Risultati Chiave

1. Caratterizzazione della Campagna (RQ1)

La campagna opera tramite una pipeline rigida e automatizzata con due fasi distinte:

• Fase 1 (Marzo 2025): Mirata a Linux, utilizzando l'indicizzazione degli slice per ricostruire i comandi.
• Fase 2 (Maggio 2025): Espansione a Windows, utilizzando un mix di concatenazione di letterali e indicizzazione di slice.
• Vettore di Esecuzione: Entrambe le fasi sfruttano gli inizializzatori di variabili globali di Go, eseguendo codice malizioso immediatamente al momento dell'importazione del pacchetto.
• Infrastruttura: La campagna si basa su una base ristretta di 20 domini distinti. I payload per Linux servono stager ELF statici, mentre i payload per Windows ruotano binari PE unici secondo un ciclo rigoroso di 31 giorni.

2. I Limiti delle Visioni Centrate su GitHub (RQ2)

Il confronto tra il set manuale di GitHub ($M$) e il set del proxy ($G$) ha rivelato due punti ciechi critici:

• Gap di Copertura della Scoperta (Miss #1): L'83,0% dei moduli maliziosi trovati nel proxy ($G \setminus M$) non era mai stato scoperto tramite il workflow manuale centrato su GitHub. Questi moduli circolavano nel proxy senza i segnali sociali (stelle) necessari per la scoperta manuale.
• Volatilità del Livello di Hosting (Miss #2): Al momento dell'analisi, il 69,3% dei moduli nell'impronta del proxy ($G$) era già "non osservabile da GitHub" (repository eliminati o sospesi).
• Doppio Errore: Il 64,3% del totale dell'impronta del proxy rientrava in entrambe le categorie: erano stati mancati dalla scoperta manuale ed i loro repository di hosting erano già scomparsi.

3. Il Gap tra Takedown e Rimediazione (RQ3)

Lo studio ha quantificato la persistenza delle minacce dopo la rimozione della sorgente:

• Evidenza A (Sovrapposizione): Per i 74 moduli nell'intersezione ($M \cap G$) confermati come morti su GitHub durante lo snapshot di giugno, il 100% rimaneva recuperabile tramite il proxy Go a luglio.
• Evidenza B (Scala): Tra i 1.586 moduli nel set del proxy ($G$) che erano non osservabili da GitHub ad agosto, il 99,4% (1.577 moduli) è stato confermato recuperabile tramite i log del proxy a luglio.
• Conclusione: Rimuovere semplicemente un repository da GitHub non rimedia la minaccia; le versioni dei moduli maliziosi persistono nel livello di distribuzione.

Contributi e Significato

Il documento fornisce tre contributi primari:

1. Misurazione su Scala di Ecosistema: Fornisce la prima misurazione completa di una campagna attiva nella supply chain di Go, caratterizzando la sua automazione, l'evoluzione in due fasi e la struttura rigida della sua offuscazione.
2. Quantificazione dei Gap di Visibilità: Dimostra che le visioni centrate su GitHub sottostimano sistematicamente l'effettiva impronta della minaccia a causa dei limiti di portata della scoperta e della volatilità del livello di hosting.
3. Evidenza del Gap di Rimediazione: Dimostra empiricamente che "takedown $\neq$ rimediazione" nell'ecosistema Go, mostrando che i moduli memorizzati nella cache del proxy rimangono disponibili molto tempo dopo che i loro repository sorgente sono stati rimossi.

Significato:
Gli autori sostengono che la risposta agli incidenti e la rimediazione nell'ecosistema Go non possono fare affidamento esclusivamente sui segnali del livello di hosting. Poiché l'infrastruttura del proxy garantisce la riproducibilità, essa mantiene involontariamente gli artefatti maliziosi. Una rimediazione efficace richiede la coordinazione tra il livello di hosting (GitHub) e il livello di distribuzione (Go Proxy/Index). In seguito alla divulgazione responsabile, GitHub ha rimosso 684 repository e il team di Google Go ha rimediato 1.377 versioni di moduli, validando la necessità di questo approccio cross-layer.