Le aziende collegano di continuo assistenti AI ad elementi della propria infrastruttura (caselle di posta elettronica, file drive, strumenti interni), partendo dal presupposto che esista un isolamento effettivo tra utenti e account. Non è detto che questo isolamento esista davvero, o che funzioni. A scoprirlo è stata Check Point Research, che ha trovato un canale nascosto capace di far inviare task da una sessione ChatGPT legata a un account a una sessione ChatGPT completamente separata, appartenente a un altro account, senza che la vittima si accorgesse di nulla. In una dimostrazione dal vivo, la sessione di un attaccante ha chiesto alla sessione della vittima di recuperare dati dal suo account Gmail collegato, e ha ottenuto esattamente quello che voleva.

Il problema? ChatGPT approva in automatico le azioni di lettura considerate a basso rischio verso le app connesse, senza chiedere conferma, e l'unica traccia di questa attività è un'etichetta Talked to Gmail che compare dopo il fatto, quando ormai è tardi.

Il trucco, o meglio la falla

Il canale che hanno sfruttato i ricercatori è un servizio interno che ChatGPT usa per far funzionare il codice degli utenti. In sostanza, quando una conversazione richiede l'esecuzione di script o l'installazione di librerie, OpenAI apre un container per quella sessione, ossia un ambiente temporaneo che dovrebbe restare separato da tutti gli altri. Inoltre, partendo dal presupposto che questi container non hanno accesso diretto a Internet, le richieste di pacchetti software passano attraverso un'istanza interna di JFrog Artifactory, un sistema di gestione dei repository software che dovrebbe agire in qualità di intermediario sicuro.

ChatGPT elabora un secondo flusso di attività in parallelo alla conversazione attiva

La realtà è differente dalla teoria, perché i ricercatori hanno scoperto che quello stesso servizio esponeva una funzione pensata per gestire i metadati dei pacchetti, che consentiva di attaccare proprietà testuali o binarie a un elemento del repository e di rileggerle in un secondo momento. L’implementazione prevedeva inoltre che le credenziali già presenti in ogni container (usate normalmente per scaricare i pacchetti), bastassero per usare entrambe le operazioni, in scrittura e in lettura. Il risultato pratico è che una proprietà scritta dal container di un account risultava leggibile, pochi istanti dopo, dal container di un account differente, trasformando di fatto i metadati di un sistema di distribuzione software in un appunto condiviso tra sessioni che avrebbero dovuto ignorarsi a vicenda.

Un account controllato dall'attaccante scriveva un'istruzione nello spazio condiviso. Bastava poi far arrivare alla vittima un prompt malevolo incollato in una chat, un link a una conversazione condivisa, oppure un GPT personalizzato con un'istruzione nascosta al suo interno, perché la sessione della vittima controllasse quello stesso spazio durante il turno successivo della conversazione.

Se c’era un compito in attesa, ChatGPT lo eseguiva usando i permessi già concessi dalla vittima (per esempio quelli verso app collegate quali Gmail, Google Drive, Microsoft Teams o GitHub), scriveva il risultato nello spazio condiviso e rispondeva normalmente alla domanda reale dell'utente, come se niente fosse. I ricercatori hanno segnalato la falla ad OpenAI, che ha chiuso il percorso di attacco.

Nello stesso turno, ChatGPT elabora una richiesta visibile dell’utente e un’attività nascosta, per poi restituire i risultati mediante canali separati

L’happy ending è un’illusione

Un retroscena interessante è che la stessa istanza di Artifactory è il servizio da cui, poche settimane prima, erano passati gli agenti AI interni di OpenAI che hanno finito per compromettere l'infrastruttura di produzione di Hugging Face. In quel caso modelli impiegati in valutazioni interne di cybersecurity, con controlli ridotti a scopo di test, avevano sfruttato in autonomia una vulnerabilità in Artifactory per uscire dal proprio ambiente isolato, raggiungere Internet e muoversi lateralmente fino a ottenere credenziali cloud, Kubernetes e di repository di codice sui sistemi di Hugging Face.

Le due vicende restano distinte per tecnica e per finalità, eppure sono maturate sullo stesso pezzo di infrastruttura condivisa. È proprio questo punto in comune a mostrare che quando gli agenti AI girano su infrastrutture interne condivise, quell'infrastruttura diventa un bersaglio, indipendentemente che ad attaccarla sia un ricercatore, un cybercriminale o gli stessi agenti che dovrebbero farla funzionare.

Anzi, il caso più recente dimostra che qualunque assistente AI che opera all’interno del perimetro di fiducia di un'organizzazione, con credenziali proprie e le autorizzazioni per eseguire codice e accedere ad app collegate, può trasformarsi in un coerced insider, ossia in un collaboratore interno che viene costretto ad agire contro la propria organizzazione. Il punto è che per fare che questo accada non serve che il modello sia necessariamente compromesso o malevolo; gli basta essere persuaso, mediante un messaggio, a usare permessi che gli erano stati concessi in perfetta buona fede.

In sostanza, il singolo caso è chiuso, ma il problema complessivo resta. E il problema, per i team di sicurezza, si è spostato dall'intercettare i dipendenti che usano ChatGPT di nascosto al governare un intero ecosistema di agenti autonomi che leggono, scrivono ed eseguono codice per conto dell'organizzazione.

Davanti a scenari simili le aziende dovrebbero muoversi su tre fronti, valevoli indipendentemente dalle piattaforma AI in uso: conoscere con precisione quali strumenti AI vengono effettivamente usati all’interno dell’infrastruttura e a che cosa sono collegati, perché dalla mancanza di visibilità e monitoraggio nascono i punti ciechi. In secondo luogo, introdurre protezioni in tempo reale capaci di rilevare tentativi di manipolazione delle AI e bloccare l'uscita di dati sensibili. Terzo fronte è la capacità di monitorare e governare attivamente quello che gli agenti AI possono fare, trattando sia le loro azioni, sia le risposte che restituiscono.

Una delle attività più importanti da portare avanti, tuttavia, riguarda la gestione delle identità. Nel caso oggetto di questo articolo, infatti, non è stata rubata nessuna credenziale e non è stata violata nessuna password: l'attacco è stato attuato sfruttando permessi che il sistema considerava normali, ossia quelli già concessi dalla vittima alle sue app collegate. È quindi chiaro che il modello di identità digitale con credenziali fisse, costruito per gli utenti umani e il più delle volte ereditato dalle identità macchina, è ormai inefficiente. Un agente AI agisce in autonomia su più sistemi insieme, e resta difficile distinguere un'azione legittima da un'istruzione iniettata in un testo esterno. La strada su cui stanno lavorando i team di sicurezza non è farlo meglio, che resta troppo complicato, piuttosto bisogna ridurre le chance di sfruttamento. In altre parole, bisogna concedere agli agenti accesso alle risorse solo per il tempo e lo scopo necessari a un singolo task, così che anche un'istruzione illecita non trovi permessi già accordati che le permettano di avere seguito.