Cercetătorii în securitate spun că Google Cloud Vertex AI Agent Engine a expus un risc serios de privilegii prin modelul său implicit de agent de serviciu, permițând unui agent AI implementat să extragă acreditările agentului de serviciu și să se transforme în resurse sensibile.Palo Alto Networks Unit 42 a spusproblema a permis unui agent rău intenționat sau compromis să treacă dincolo de sarcina intenționată și să citească datele din proiectul Google Cloud al clientului.
Cercetătorii au descris problema ca fiind o slăbiciune a permisiunii implicite, nu o simplă eroare în gestionarea promptă. În testul lor, un agent implementat construit cuKitul de dezvoltare a agenților Googlear putea să interogheze serviciul de metadate, să extragă acreditările agentului de serviciu Vertex AI Reasoning Engine și apoi să folosească acea identitate pentru a accesa datele de stocare din proiectul consumatorului.
Google nu a încadrat acest lucru ca un eveniment activ de exploatare în masă în materialele pe care le-am găsit. În schimb, evidența publică arată o problemă de securitate dezvăluită de cercetători care a determinat Google să actualizeze documentația și să împingă clienții către controale mai stricte ale identității, cum ar fi identitatea agentului și o gestionare mai explicită a contului de serviciu.
Ce au descoperit cercetătorii
Unitatea 42 a spus Per-Project, Per-Product Service Agent sau P4SA, legat de un agent Vertex AI implementat, avea permisiuni excesive în mod implicit. Au extras acreditările pentruservice-<PROJECT-ID>@gcp-sa-aiplatform-re.iam.gserviceaccount.com, pe care Google îl documentează ca Vertex AI Reasoning Engine Service Agent.
Cu aceste acreditări, cercetătorii au spus că ar putea pivota înpropriul proiect Google Cloud al clientuluiși obțineți acces de citire la compartimentele Google Cloud Storage. Unitatea 42 a enumerat în mod specific permisiunile, cum ar fistorage.buckets.get,storage.buckets.list,storage.objects.get, șistorage.objects.listca parte a accesului excesiv pe care l-au observat.
Ei au spus, de asemenea, că aceleași acreditări au expus accesul la depozitele restricționate de Artifact Registry deținute de Google, legate de Vertex AI Reasoning Engine.Conform raportului, acest acces le permite să vadă și să descarce imagini interne ale containerelor asociate cu serviciul, despre care au susținut că ar putea dezvălui codul proprietar și ar putea ajuta la maparea lanțului intern de aprovizionare de software al Google.
De ce contează problema
Acest lucru contează deoarece agenții AI acționează acum ca lucrători semi-autonomi în mediile de întreprindere. Dacă identitatea atașată acelui agent are mai mult acces decât ar trebui, un instrument rău intenționat, un agent manipulat prompt sau o implementare compromisă se poate transforma într-un punct pivot intern. Acesta este scenariul de bază „agent dublu” descris de Unitatea 42.
Cercetătorii au descoperit, de asemenea, că acreditările extrase au oferit acces la un proiect de chiriaș gestionat de Google, utilizat pentru instanța agentului. În acel mediu, au descoperit fișiere precumDockerfile.zip,code.pkl, șirequirements.txt, împreună cu referințe la compartimentele interne Google Cloud Storage. Ei au spus că nu pot accesa direct cel puțin o găleată internă restricționată, dar referințele de infrastructură au expus în continuare detalii operaționale.
Unele dintre scenariile mai înfricoșătoare din aval din exemplul de articol necesită o formulare mai strictă. Unitatea 42 a discutat despre un fișier Python pickle și a remarcat că pickle este nesigur din punct de vedere istoric atunci când datele nesigure sunt deserializate, dar raportul nu a susținut o ușă de producție demonstrată prin acel fișier în mediul Google. Acea parte ar trebui să rămână încadrată ca un semnal de risc, nu ca o cale de exploatare confirmată.
Ce a schimbat Google
Unitatea 42 spune că Google a colaboratcu cercetătorii după dezvăluire și și-a revizuit documentația pentru a explica modul în care Vertex AI utilizează resursele, conturile și agenții. Pagina de cercetare mai spune că Google a schimbat fluxul de lucru de implementare ADK după descoperire și a remarcat că eșantionul de cod original folosit în cercetare ar putea să nu mai funcționeze în versiunea actuală.
Documentația actuală Google Vertex AI Agent Engine împinge acum clienții către un control mai puternic al identității. Ghidul de configurare recomandă utilizarea identității agentului pentru gestionarea accesului, iar Google spune că identitatea agentului permite organizațiilor să acorde sau să refuze accesul la API-urile și resursele Google Cloud primare pe bază de agent.
De asemenea, Google documentează că agenții desfășurați pot folosi fie identitatea agentului, fie conturile de serviciu și spune că acele identități determină ce date și resurse poate accesa agentul. Aceasta este calea practică de remediere aici: încetați să vă bazați pe permisiunile implicite largi și treceți la designul explicit al identității cu cel mai mic privilegiu.
Puncte cheie
- Unitatea 42 a spus că un agent Vertex AI instalat ar putea extrage acreditările agentului de service Vertex AI Reasoning Engine.
- Cercetătorii au spus că acele acreditări au permis accesul la citire la datele din compartimentele Google Cloud Storage ale clienților.
- Ei au raportat, de asemenea, acces la arhivele restricționate ale Registrului Artefact deținute de Google legate de imaginile Vertex AI Reasoning Engine.
- Google a actualizat documentația și a schimbat fluxul de lucru de implementare ADK după dezvăluire.
- Google recomandă acum un control mai strict al identității prin identitatea agentului și gestionarea explicită a contului de serviciu.
Tabel rezumat al riscurilor
| Zonă | Ce au raportat cercetătorii | De ce contează |
|---|---|---|
| Identitatea agentului de serviciu | Acreditările agentului de serviciu Vertex AI Reasoning Engine ar putea fi extrase din mediul implementat | Acreditările furate pot permite unui agent să acționeze în afara rolului său preconizat. |
| Datele proiectului clientului | Acces la permisiunile pentru compartimentul și obiectul Cloud Storage în proiectul de consum | Datele sensibile ale clienților ar putea deveni lizibile de un agent rău intenționat. |
| Infrastructură gestionată de Google | Acces la imagini restricționate Artifact Registry și fișiere de implementare a proiectelor chiriașilor | Vizibilitatea infrastructurii interne poate ajuta o cercetare mai profundă și atacuri ulterioare. |
| Design de identitate | Valori implicite prea largi în loc de cel mai mic privilegiu | Agenții AI devin identități interne cu risc ridicat dacă permisiunile sunt prea largi. |
| Atenuare | Identitatea agentului și controale mai stricte ale contului de serviciu | Limitează ceea ce poate ajunge un agent desfășurat dacă este abuzat. |
Ce ar trebui să facă organizațiile acum
- Examinați fiecare implementare Vertex AI Agent Engine și identificați identitatea serviciului pe care o folosește.
- Înlocuiți accesul prestabilit larg cu identitatea agentului cu cel mai mic privilegiu sau conturi de serviciu cu un domeniu strâns.
- Auditați stocarea în cloud, registrul artefactului și legăturile IAM aferente acordate agenților de servicii Vertex AI.
- Tratați agenții AI ca sarcini de lucru privilegiate, nu doar caracteristici ale aplicației. Aceasta este lecția directă din concluziile Unității 42.
FAQ
Care a fost problema Vertex AI?
Cercetătorii au spus că o instanță Vertex AI Agent Engine desfășurată ar putea expune acreditările agentului său de serviciu, ceea ce a permis apoi accesul la resurse sensibile dincolo de scopul prevăzut al agentului.
Acest lucru a permis atacatorilor să citească datele clienților?
Unitatea 42 a spus da, în mediul lor de testare. Ei au raportat acces de citire la toate datele compartimentului Google Cloud Storage din cadrul proiectului consumatorului, după ce au trecut cu identitatea de agent de serviciu furat.
Au obținut cercetătorii acces direct la toate sistemele interne Google?
Nu. Ei au raportat acces la arhivele restricționate de Artifact Registry deținute de Google și la fișierele de implementare a proiectelor chiriașilor, dar au mai spus că nu au permisiunea de a accesa cel puțin un compartiment de stocare internă restricționat pe care l-au identificat.
Care este remedierea recomandată?
Îndrumările actuale ale Google indică mai degrabă controale mai puternice ale identității, în special identitatea agentului și conturile de servicii cu un domeniu strâns, mai degrabă decât permisiunile implicite largi.