Terraform, 5 provider malevoli eseguono codice già con terraform init

🛡️ Executive Summary

• Averlon analizza oltre 5.500 provider Terraform community e ne classifica cinque come malevoli, oltre a 1.091 considerati sospetti.
• Un provider è un binario eseguibile: può leggere file, credenziali ed environment variable già durante il semplice comando terraform init.
• Il rischio nasce dal confondere Infrastructure as Code con configurazione passiva, ignorando il codice eseguibile introdotto dalle dipendenze.

Terraform può trasformare una dipendenza apparentemente infrastrutturale in codice eseguito con le credenziali più sensibili dell’ambiente cloud. Averlon ha analizzato oltre 5.500 provider community e ne ha classificati cinque come malevoli, oltre a più di mille che richiedono ulteriori verifiche. Il punto più importante della ricerca non riguarda però il numero dei provider individuati: un provider Terraform non è semplice configurazione, ma un binario eseguibile che eredita accesso a rete, filesystem, variabili d’ambiente e credenziali disponibili al processo. Per attivarlo può essere sufficiente eseguire terraform init, senza creare alcuna risorsa e senza arrivare a terraform apply.

Terraform Registry distribuisce codice che eredita la fiducia dell’infrastruttura

Terraform viene normalmente percepito come strumento di Infrastructure as Code, quindi come un livello dichiarativo utilizzato per descrivere reti, cluster Kubernetes, database e servizi cloud. Questa lettura diventa pericolosa quando viene estesa indistintamente a moduli e provider. Nella ricerca pubblicata da Averlon viene evidenziato che il Terraform Registry ospita oltre 22.000 moduli e quasi 7.000 provider, ma la presenza nel registry non equivale a una verifica di sicurezza del codice distribuito.

Il problema è particolarmente rilevante perché Terraform opera spesso con autorizzazioni molto superiori a quelle di una normale applicazione: può creare infrastrutture, modificare policy IAM, leggere segreti e accedere alle API dei cloud provider. Di conseguenza, introdurre un provider equivale molto più a eseguire un binario di terze parti che a importare un semplice file di configurazione. È lo stesso principio emerso negli attacchi alla supply chain di GitHub Actions, dove il componente compromesso diventava pericoloso proprio perché veniva eseguito all’interno di runner già dotati di token e segreti.

Leggi anche: Jade Sleet usa Terraform per trasformare una prova DevOps in un’infezione

Basta terraform init per eseguire un payload senza arrivare al deploy

La distinzione più importante riguarda il funzionamento dei provider. Un provider Terraform è un plugin compilato, generalmente scritto in Go, che viene scaricato sul sistema e lanciato come processo separato. Da quel momento può compiere operazioni che non hanno necessariamente alcuna relazione con le modifiche infrastrutturali mostrate da terraform plan: leggere file locali, consultare variabili d’ambiente, recuperare credenziali cloud, effettuare richieste verso Internet o eseguire comandi.

Il limite del modello di controllo emerge già durante terraform init. Averlon dimostra che un provider costruito per eseguire un comando shell può avviare il payload durante l’inizializzazione, prima ancora che l’utente richieda un terraform apply. Questo rende insufficiente utilizzare il piano Terraform come unica superficie di revisione, perché il comportamento del binario non deve necessariamente comparire tra le risorse che verranno create o modificate. Il rischio ricorda quanto osservato nelle campagne che sfruttano pacchetti Ruby, Go e npm per sottrarre credenziali cloud e chiavi SSH: il componente malevolo entra attraverso un processo di sviluppo considerato legittimo e sfrutta i privilegi che l’ambiente gli concede già per svolgere il proprio lavoro.

Un modulo può nascondere il provider che esegue realmente il codice

Moduli e provider possono inoltre essere combinati per rendere il rischio meno evidente. Un team può importare un modulo credendo di riutilizzare esclusivamente configurazioni infrastrutturali, mentre quel modulo può introdurre una dipendenza verso un provider ulteriore. Il codice Terraform visibile continua a creare le risorse attese e il piano può apparire perfettamente coerente, ma durante l’inizializzazione viene scaricato anche il binario del provider aggiuntivo. Averlon mostra come un provider malevolo possa essere nascosto all’interno di un modulo apparentemente innocuo e convivere con normali risorse AWS.

L’unico segnale evidente può comparire nell’output di inizializzazione, facilmente ignorabile quando il nome del provider è sufficientemente credibile. L’attacco sfrutta quindi non un bug specifico di Terraform, ma una trust boundary sottovalutata: il modulo viene interpretato mentalmente come configurazione, anche quando porta con sé software eseguibile. La stessa confusione tra contenuto apparentemente passivo e componente realmente operativo si è vista quando GitHub Actions è stato trasformato in infrastruttura offensiva attraverso workflow nascosti nei repository. Il rischio non è determinato soltanto dal contenuto che lo sviluppatore pensa di utilizzare, ma da tutto ciò che la catena di dipendenze provoca automaticamente nell’ambiente.

Cinque provider malevoli e oltre mille casi sospetti su 5.500 analizzati

Averlon ha sottoposto a scansione oltre 5.500 provider community, combinando analisi statica, dipendenze, call graph, metadati dei file e revisione tramite un modello linguistico configurato per operare come malware analyst. Il risultato comprende 3.949 provider benigni, 1.091 sospetti, 652 casi con evidenze insufficienti, 12 che richiedono ulteriore revisione e 5 classificati come malevoli. I cinque provider malevoli sembrano essere principalmente proof of concept e dimostrano tecniche come raccolta delle credenziali, esecuzione di comandi e comunicazioni di rete nascoste. Averlon precisa di non aver trovato prove che siano stati utilizzati in campagne attive. È una distinzione fondamentale: la ricerca non dimostra che il Terraform Registry sia diffusamente compromesso, ma prova che il meccanismo consente già di distribuire provider progettati per abusare della fiducia concessa dal runtime. Anche i 1.091 risultati sospetti non devono essere interpretati automaticamente come malware. Molti provider effettuano richieste di rete o leggono variabili d’ambiente perché questo rientra nella loro funzione normale. L’anomalia nasce quando tali comportamenti risultano non documentati, sproporzionati o diretti verso destinazioni non coerenti con lo scopo dichiarato. Il precedente dei repository GitHub falsificati per distribuire malware e rubare credenziali mostra quanto possa essere pericoloso trasformare età del repository, cronologia dei commit o aspetto professionale in indicatori automatici di affidabilità.

Continua con:

FakeGit avvelena GitHub con 7.600 repository malevoli

Megalodon compromette migliaia di repository attraverso workflow CI/CD

La cronologia Git non certifica chi controlla davvero il provider

Averlon evidenzia infine un’altra debolezza della verifica manuale: un attaccante può clonare un progetto open source legittimo conservandone l’intera cronologia Git, modificare il remote e ripubblicare il repository sotto un namespace simile all’originale. Commit vecchi di anni, nomi di contributor conosciuti, release e documentazione vengono conservati perché Git è progettato precisamente per replicare la storia del repository. Bastano quindi pochi commit successivi per introdurre il comportamento malevolo senza cancellare l’apparenza di maturità del progetto. Il problema di Terraform non è quindi una vulnerabilità tradizionale da correggere con una patch. È un problema di fiducia nella supply chain: chi esegue Terraform deve considerare provider, moduli e processi CI/CD come codice con accesso privilegiato, verificare origine e namespace delle dipendenze, fissarne le versioni e controllare i cambiamenti prima dell’esecuzione. In un ambiente nel quale terraform init può già avviare un binario con accesso alle credenziali cloud, il confine di sicurezza non coincide più con il momento del deploy: inizia quando viene accettata la dipendenza.