Un agente AI configurato correttamente può diventare uno strumento di attacco: su Vertex AI Agent Engine, permessi predefiniti eccessivi aprono l'accesso ai dati del cliente e all'infrastruttura interna di Google.
Autore: Redazione SecurityOpenLab
La superficie di attacco degli agenti AI in ambienti cloud enterprise si allarga a ogni nuovo caso documentato dai team di ricerca, e ogni caso aggiunge una prospettiva diversa sullo stesso problema di fondo. Su SecurityOpenLab abbiamo già esaminato alcune di queste prospettive, fra cui le più recenti sono il modello compromesso prima ancora del deployment e il modello in produzione che opera oltre i confini di fiducia previsti. Aggiungiamo oggi l’interessante esito di una ricerca pubblicata dalla Unit 42 di Palo Alto Networks, che aggiunge un terzo punto di osservazione: l'infrastruttura di deployment in cui permessi predefiniti eccessivi possono trasformare un agente AI legittimo in un vettore di compromissione dell'intero ambiente cloud.
Il caso documentato riguarda in particolare Vertex AI Agent Engine di Google Cloud Platform (GCP), la piattaforma che consente agli sviluppatori di costruire e distribuire agenti AI sofisticati integrati nei flussi di lavoro enterprise. Il titolo scelto dai ricercatori, Double Agents, descrive con precisione il meccanismo in cui un agente configurato correttamente, senza codice malevolo nel modello e senza anomalie nel comportamento visibile, può essere armato da un attaccante esterno per agire contro l'organizzazione che lo ha messo in produzione.
Il meccanismo di attacco documentato dalla Unit 42 parte da un elemento specifico dell'architettura GCP: il Per-Project, Per-Product Service Agent, identificato nell'acronimo P4SA. Si tratta di un account di servizio gestito da Google che consente a un servizio GCP di accedere alle risorse del progetto. Quando un agente AI viene configurato su Vertex AI Agent Engine, il P4SA associato riceve per default un insieme di permessi che i ricercatori hanno identificato come eccessivi rispetto a quanto necessario per il funzionamento dell'agente.
È qui che parte la catena di attacco. Sfruttando i permessi predefiniti del P4SA, i ricercatori hanno interrogato il metadata service interno di Google Cloud ed estratto le credenziali dell'account di servizio. Hanno ottenuto così il progetto GCP che ospita l'agente in formato JSON, l'identità dell'agente stesso e gli scope OAuth 2.0 associati alla macchina su cui l'agente è in esecuzione. Con queste credenziali in mano è stato facile attuare il movimento laterale verso le risorse del progetto cliente.
L'accesso ottenuto includeva la lettura illimitata di tutti i dati contenuti nei Google Cloud Storage Bucket del progetto, con permessi di lettura e listing su tutti i bucket e i loro contenuti. Per un'organizzazione che utilizza GCP per archiviare dati operativi, backup, log o asset di produzione, questo livello di accesso è sufficiente per un'esfiltrazione massiva senza che nessun sistema di rilevamento tradizionale rilevi anomalie nell'agente, che continua a operare normalmente dal punto di vista dell'utente.
Il secondo aspetto interessante della ricerca è che le stesse credenziali P4SA sottratte hanno consentito ai ricercatori di accedere a repository Artifact Registry riservati di proprietà di Google, che non sono accessibili dal cliente standard. Tra questi figurano i repository privati con le immagini container che costituiscono il nucleo operativo di Vertex AI Reasoning Engine, che contengono codice proprietario di Google relativo all'infrastruttura di Vertex AI, con dettagli implementativi riservati.
Inoltre, avere visibilità sul contenuto dei repository interni di una piattaforma cloud significa poter mappare la supply chain software interna, identificare immagini obsolete o con vulnerabilità note, pianificare attacchi successivi con una base informativa che un attaccante esterno normalmente non possiede.
I ricercatori hanno verificato che le stesse credenziali hanno dato accesso anche ai bucket Google Cloud Storage del tenant project, il progetto gestito da Google dedicato all'istanza configurata dell'Agent Engine. In quell'ambiente hanno trovato il Dockerfile utilizzato per il deployment, che conteneva percorsi interni scritti nel codice a bucket GCP interni riservati, tra cui gs://reasoning-engine-restricted. I ricercatori non hanno potuto accedere direttamente al contenuto del bucket, ma la visibilità sui percorsi interni riservati è stata sufficiente a esporre informazioni sull'infrastruttura di Google Cloud a cui un cliente non dovrebbe mai avere accesso.
Nel tenant project i ricercatori hanno trovato anche un file .pkl, il cui uso è sconsigliato perché intrinsecamente insicuro, dato che chiunque riesca a modificarne il contenuto prima o durante il deployment può fargli eseguire codice arbitrario all'apertura, fra cui
backdoor persistenti. Inoltre, deserializzando questo file in un ambiente controllato i ricercatori hanno potuto ispezionare la struttura interna del codice proprietario di Google e hanno ottenuto ulteriori dettagli sull'implementazione di Vertex AI Reasoning Engine.
L'analisi ha rivelato anche che i permessi OAuth 2.0 associati per default all'Agent Engine includono l'accesso potenziale a servizi Google Workspace come Gmail, Google Calendar e Google Drive. Per default i permessi IAM necessari non sono concessi, quindi l'accesso non si attiva automaticamente, ma la combinazione di permessi OAuth così ampi con eventuali permessi IAM configurati in modo errato crea una condizione di rischio latente che potrebbe dare accesso a un agente compromesso alla posta elettronica, ai calendari e ai documenti dell'organizzazione. Gli esperti sottolineano che la criticità è dovuta al fatto che permessi tanto ampi e non modificabili sono una deviazione dal principio del minimo privilegio a livello di API, indipendente e separata dalla gestione IAM, e che questa deviazione è incorporata nel design della piattaforma senza che l'utente possa intervenire.
A seguito della ricerca, Google ha aggiornato la documentazione ufficiale di Vertex AI per informare i clienti sul modo in cui la piattaforma utilizza risorse, account e service agent. Ha inoltre rassicurato circa il fatto che il service agent compromesso non può alterare le immagini container usate in produzione da altri clienti - quindi un attaccante non può avvelenare l'infrastruttura condivisa di Vertex AI per colpire altri tenant, scongiurando lo scenario peggiore della supply chain attack su scala.
Per le altre criticità Google ha suggerito delle mitigazioni, fra cui la principale è l'adozione della best practice Bring Your Own Service Account (BYOSA) per affiancare al P4SA predefinito un account di servizio proprio, che viene utilizzato al posto del P4SA per tutte le operazioni dell'agente e configurato secondo il principio del minimo privilegio, così che il cliente possa controllare i permessi dell'account su cui l'agente opera, eliminando alla radice il problema dei permessi eccessivi concessi per default.