I moderni strumenti di coding assistito da AI stanno diventando parte integrante del flusso di lavoro di milioni di sviluppatori. Ma questa automazione introduce una nuova superficie di attacco che i ricercatori di sicurezza hanno appena dimostrato in modo preoccupante: un repository GitHub apparentemente pulito può indurre un agente AI a eseguire malware, senza che nessun codice malevolo sia visibile né agli scanner statici né agli occhi umani.
La ricerca di Mozilla 0DIN
I ricercatori della Mozilla Zero Day Investigative Network (0DIN), la piattaforma di sicurezza AI di Mozilla, hanno pubblicato un proof-of-concept che dimostra come un agente di coding autonomo possa essere indotto a installare una reverse shell sul sistema dello sviluppatore. Il test è stato condotto specificamente con Claude Code, ma la vulnerabilità concettuale riguarda qualsiasi agente AI che abbia accesso al filesystem e al terminale.
La parte più inquietante della ricerca è questa frase dei ricercatori: “No exploit code, no warning, no suspicious command anyone had to approve.” Nessun codice exploit, nessun avvertimento, nessun comando sospetto da approvare.
Come funziona l’attacco: tre componenti innocui
L’attacco si basa su tre elementi che, considerati singolarmente, non destano alcun sospetto:
- Un repository GitHub pulito — Il repo contiene istruzioni di setup standard: installazione dipendenze (
pip3 install -r requirements.txt) e inizializzazione del progetto (python3 -m axiom init). Nessun codice malevolo, nessun flag da scanner. - Un pacchetto Python progettato per fallire — Il package è volutamente configurato per rifiutare l’esecuzione finché non viene inizializzato. Genera un errore che istruisce l’utente (o l’agente) a eseguire
python3 -m axiom init. L’agente AI, tentando di risolvere autonomamente l’errore di setup, lancia questo comando. - Un record DNS TXT controllato dall’attaccante — Il comando di inizializzazione chiama uno script shell che recupera un valore di configurazione da un record DNS TXT controllato dall’attaccante. Quel valore viene eseguito come comando.
Il risultato è una reverse shell con i privilegi del developer. L’agente AI ha eseguito tre livelli di indirection — un messaggio di errore fidato, uno script che ha recuperato un valore, e un record DNS che non ha mai esaminato — senza mai “vedere” il payload malevolo.
Perché è invisibile ai controlli tradizionali
Questa tecnica bypassa tutti i meccanismi di difesa convenzionali:
- Scanner statici: non trovano nulla perché il repository è genuinamente pulito
- Code review umana: anche un revisore attento non vedrebbe codice malevolo
- AI review: l’agente AI valuta solo il codice che vede, non il payload DNS
- Audit log limitati: l’agente potrebbe non registrare l’intera catena di esecuzione, incluse le risorse recuperate dinamicamente a runtime
Ciò che rende l’attacco efficace è il comportamento goal-oriented degli agenti AI: quando incontrano un errore, il loro obiettivo è risolverlo. E lo risolvono eseguendo esattamente ciò che viene suggerito — anche se quel suggerimento porta a recuperare ed eseguire un payload da un record DNS remoto.
Cosa ottiene l’attaccante
Se l’attacco va a segno, l’attaccante ottiene una shell interattiva con i privilegi dello sviluppatore. Questo significa accesso a:
- Variabili d’ambiente (incluse credenziali e API key)
- File di configurazione locali (chiavi SSH, certificati, config di cloud provider)
- Possibilità di stabilire persistenza sul sistema
- Accesso ai repository locali e ai segreti in essi contenuti
I ricercatori 0DIN avvertono che questa tecnica potrebbe essere distribuita facilmente attraverso fake job posting, tutorial, post su blog tecnici o messaggi diretti su piattaforme come Discord o LinkedIn.
Come mitigare il rischio
0DIN ha proposto alcune contromisure concrete per chi sviluppa o utilizza strumenti di coding AI agentico:
- Execution chain disclosure: gli agenti AI dovrebbero mostrare esplicitamente l’intera catena di esecuzione dei comandi di setup, inclusi script e codice recuperato dinamicamente a runtime, prima di eseguirlo.
- Sandboxing più rigido: gli agenti autonomi che interagiscono con repository esterni dovrebbero operare in ambienti isolati (container, VM, namespace separati) con privilegi minimi.
- Permission scoping: limitare le azioni che un agente AI può compiere autonomamente — specialmente l’esecuzione di comandi shell — richiedendo conferma esplicita dell’utente per operazioni ad alto rischio.
- Monitoraggio DNS in uscita: implementare logging e alerting su query DNS anomale durante le operazioni di build e setup.
- Analisi comportamentale: non fidarsi solo degli scanner statici, ma adottare strumenti di analisi comportamentale che monitorino le azioni effettive a runtime.
Un segnale di allarme per il settore
Questa ricerca evidenzia un problema strutturale nell’adozione degli agenti AI nel ciclo di sviluppo: l’automazione che ci fa risparmiare tempo è la stessa che può diventare un vettore di attacco. Man mano che strumenti come Claude Code, GitHub Copilot Workspace e altri agenti simili vengono integrati nelle pipeline CI/CD e nei workflow quotidiani, la superficie di attacco si espande in modi che i modelli di minaccia tradizionali non contemplano.
La buona notizia è che, per ora, si tratta di un proof-of-concept. La cattiva è che chiunque abbia letto questa ricerca sa come replicarlo — e il costo per un attaccante è praticamente zero: basta pubblicare un repository GitHub e registrare un dominio per il record DNS TXT.
Per i team di sicurezza, questo è il momento di rivedere le policy di utilizzo degli agenti AI, in particolare per quanto riguarda le operazioni autonome su repository di terze parti.
Fonte originale: 4sysops.com — ricerca originale di Mozilla 0DIN via BleepingComputer