Prompt injection indiretto: attacco via GitHub e agenti AI

🛡️ Executive Summary

• Ricercatori dimostrano una tecnica di prompt injection indiretta che sfrutta repository GitHub e agenti AI per ottenere una reverse shell senza inserire malware nel codice sorgente.
• L’attacco combina istruzioni di setup, messaggi di errore manipolati e payload recuperati tramite record DNS TXT, aggirando efficacemente le tradizionali analisi statiche.
• Gli sviluppatori dovrebbero verificare manualmente gli script di inizializzazione e limitare le autorizzazioni concesse agli agenti AI durante la configurazione dei progetti.

L’adozione sempre più diffusa degli assistenti di sviluppo basati su intelligenza artificiale sta introducendo nuove superfici di attacco che vanno oltre le tradizionali vulnerabilità del software. Una dimostrazione realizzata da ricercatori di sicurezza evidenzia come sia possibile compromettere completamente la macchina di uno sviluppatore semplicemente inducendolo a clonare un repository GitHub apparentemente legittimo e affidarne la configurazione a un agente AI come Claude Code. La tecnica non richiede l’inserimento di codice malevolo nel repository e non sfrutta vulnerabilità del sistema operativo o del linguaggio di programmazione. L’intero attacco si basa invece sulla capacità degli agenti autonomi di interpretare istruzioni, eseguire comandi di shell, leggere file e recuperare informazioni dalla rete come parte delle normali attività di configurazione di un progetto. Attraverso una sofisticata combinazione di prompt injection indiretta, messaggi di errore costruiti ad arte e payload distribuiti tramite DNS, gli aggressori possono ottenere una reverse shell senza lasciare tracce evidenti nel codice sorgente.

L’attacco sfrutta la fiducia degli agenti AI nei repository

Il principio alla base della tecnica consiste nello sfruttare il modo in cui gli agenti di coding AI elaborano il contenuto di un progetto. Quando uno sviluppatore clona un repository e chiede all’assistente di configurarlo, quest’ultimo considera normalmente affidabili i file presenti nella directory di lavoro, come README, script di installazione e documentazione. L’agente interpreta tali elementi come parte del contesto operativo del progetto ed esegue automaticamente i passaggi necessari per completare l’installazione. Gli aggressori sfruttano proprio questo comportamento per orchestrare una sequenza di operazioni che, prese singolarmente, appaiono perfettamente legittime ma che, combinate tra loro, conducono all’esecuzione arbitraria di codice. Non essendoci malware incorporato nel repository, anche un controllo manuale del codice può non evidenziare alcun elemento sospetto.

Tre componenti apparentemente innocui costruiscono il vettore di attacco

La dimostrazione si basa sulla cooperazione di tre elementi distinti. Il primo consiste in un repository pubblico che presenta normali istruzioni di installazione e configurazione. Il secondo è rappresentato da un pacchetto Python progettato per generare un messaggio di errore apparentemente legittimo quando il progetto non è ancora stato inizializzato. Il terzo componente è uno script di setup incaricato di interrogare un record DNS TXT controllato dall’aggressore e di eseguire automaticamente il contenuto recuperato. Nessuno di questi elementi, osservato singolarmente, appare particolarmente pericoloso. L’efficacia dell’attacco deriva esclusivamente dalla loro interazione durante il processo di configurazione guidato dall’agente AI.

Il messaggio di errore induce l’agente a eseguire il comando

All’interno del pacchetto Python viene inserito un file init.py che verifica se il progetto sia stato inizializzato correttamente. Quando la verifica fallisce, il codice genera un RuntimeError con un messaggio che suggerisce esplicitamente di eseguire un comando come python3 -m nomeprogetto init. Questo comportamento è estremamente comune nei pacchetti software legittimi e difficilmente suscita sospetti sia nello sviluppatore sia nell’agente AI. Seguendo le indicazioni riportate dal messaggio, l’assistente interpreta il comando come parte della normale procedura di installazione e lo esegue automaticamente, avviando così la fase successiva dell’attacco.

Il payload viene recuperato dinamicamente tramite DNS

Lo script di inizializzazione rappresenta il vero elemento chiave della compromissione. Durante la sua esecuzione utilizza strumenti come dig per interrogare un record DNS TXT appartenente a un dominio controllato dall’attaccante. Se il record restituisce un valore valido, quest’ultimo viene passato direttamente a bash -c ed eseguito sulla macchina della vittima. Il payload distribuito attraverso il DNS è codificato in Base64, così da non apparire immediatamente leggibile durante eventuali ispezioni superficiali. Una volta decodificato, il contenuto corrisponde generalmente a un comando di reverse shell che stabilisce una connessione diretta tra il sistema compromesso e il server controllato dall’aggressore. Poiché il payload viene recuperato solo al momento dell’esecuzione, non compare mai all’interno del repository né viene memorizzato permanentemente sul disco in forma leggibile.

La reverse shell offre il controllo completo della macchina

Una volta stabilita la connessione remota, l’attaccante ottiene i privilegi dell’utente che ha eseguito l’agente AI. Da quel momento diventa possibile consultare variabili d’ambiente contenenti token GitHub, credenziali AWS, chiavi API di servizi come Anthropic e numerose altre informazioni sensibili normalmente presenti negli ambienti di sviluppo. Gli aggressori possono inoltre installare meccanismi di persistenza, creare nuovi utenti, aggiungere chiavi SSH, modificare configurazioni di sistema oppure installare ulteriori malware destinati a mantenere il controllo della macchina nel tempo. Il fatto che il payload venga distribuito dinamicamente tramite DNS consente inoltre di modificare il comportamento dell’attacco in qualsiasi momento senza aggiornare il repository originario, rendendo la campagna estremamente flessibile.

L’attacco aggira le tradizionali tecniche di rilevamento

Uno degli aspetti più insidiosi della dimostrazione riguarda la difficoltà di individuare la minaccia attraverso gli strumenti di sicurezza tradizionali. L’analisi statica del repository mostra semplicemente uno script che interroga un record DNS e avvia un comando di shell, operazioni che possono risultare perfettamente lecite durante una procedura di configurazione. Anche il traffico di rete evidenzia soltanto una normale richiesta DNS seguita da una connessione in uscita, senza la presenza di file eseguibili sospetti o payload permanenti. L’agente AI, dal canto suo, interpreta l’intera sequenza come una normale installazione del progetto. Nessuno dei singoli componenti risulta quindi chiaramente malevolo; soltanto l’interazione tra messaggio di errore, script di inizializzazione e contenuto del record DNS produce la compromissione effettiva della macchina.

I repository possono essere diffusi attraverso canali legittimi

Secondo i ricercatori, il vettore di attacco si presta a numerosi scenari di distribuzione. Un repository apparentemente innocuo può essere pubblicato su GitHub, condiviso attraverso tutorial tecnici, allegato a offerte di lavoro per sviluppatori oppure distribuito mediante normali conversazioni su piattaforme collaborative. Poiché il codice sorgente non contiene malware evidente, il repository può apparire del tutto legittimo anche a sviluppatori esperti. L’elemento decisivo diventa quindi la presenza di un agente AI configurato per eseguire automaticamente le istruzioni contenute nel progetto senza richiedere conferme dettagliate all’utente.

Gli agenti AI richiedono nuovi modelli di sicurezza

La ricerca evidenzia come la crescente autonomia degli strumenti di coding basati su intelligenza artificiale richieda un ripensamento delle strategie di sicurezza. Gli sviluppatori dovrebbero esaminare manualmente gli script di inizializzazione prima di consentirne l’esecuzione e limitare, quando possibile, i privilegi concessi agli assistenti AI durante la configurazione dei progetti. Parallelamente, i produttori di agenti autonomi dovrebbero introdurre sistemi di trasparenza che mostrino chiaramente tutti i comandi di shell, le operazioni di rete e le istruzioni recuperate da fonti esterne, compresi i contenuti provenienti da record DNS TXT. Consentire agli utenti di verificare ogni singolo passaggio prima dell’esecuzione rappresenterebbe una difesa efficace contro questo tipo di prompt injection indiretta.

La sicurezza degli strumenti AI diventa parte della supply chain

La dimostrazione conferma che gli agenti AI stanno diventando un nuovo elemento della supply chain del software e, come tale, rappresentano un bersaglio privilegiato per gli aggressori. La capacità di influenzare indirettamente le decisioni di un assistente autonomo attraverso repository apparentemente legittimi apre scenari di compromissione completamente nuovi rispetto agli attacchi tradizionali. In futuro la protezione degli ambienti di sviluppo non dipenderà più soltanto dall’analisi del codice sorgente o dal controllo delle dipendenze software, ma anche dalla capacità di verificare il comportamento operativo degli agenti AI che eseguono automaticamente istruzioni, recuperano contenuti dalla rete e interagiscono con il sistema. La sicurezza dell’intelligenza artificiale applicata allo sviluppo software diventa quindi un elemento fondamentale della resilienza dell’intero ecosistema DevSecOps.