Luka w Google ADK. Agenci AI wpadli we własną pułapkę

• Problem dotyczył konfiguracji agentów pomagających Google w obsłudze projektu, a nie samego narzędzia instalowanego przez programistów.
• Agent analizujący publiczne zgłoszenia lub zmiany w kodzie mógł paść ofiarą prompt injection i opublikować polecenie uznawane za pochodzące od zaufanego współpracownika.
• Google usunęło problematyczne automatyzacje. Nie ma informacji, aby luki zostały wykorzystane w rzeczywistym ataku lub doprowadziły do rozpowszechnienia szkodliwej wersji ADK.

Google Agent Development Kit, w skrócie ADK, to zestaw narzędzi dla programistów tworzących aplikacje wykorzystujące agentów AI.

Jego wersja dla Pythona jest rozwijana w publicznym repozytorium google/adk-python na GitHubie, gdzie przechowywane są kod, dokumentacja, testy oraz historia zmian.

Programiści mogą zgłaszać tam problemy dotyczące m.in. uruchamiania agentów, obsługi plików czy łączenia z modelami AI. Mogą opisać problem, podać komunikat błędu i dołączyć fragment kodu, a także przesłać „pull request”, czyli gotową propozycję zmiany w kodzie ADK.

Agenci pomagali obsługiwać zgłoszenia

W repozytorium działały automatyzacje wykorzystujące AI. Jeden agent analizował zgłoszenia, inny sprawdzał propozycje zmian, a kolejny mógł przygotować poprawkę. Dzięki temu opiekunowie projektu nie musieli ręcznie analizować każdego zgłoszenia od początku.

Problem polegał na tym, że agenci przetwarzali treści przesyłane przez dowolne osoby z internetu. Atakujący mógł utworzyć pozorne zgłoszenie błędu albo propozycję zmiany kodu i umieścić w niej instrukcję skierowaną do modelu AI.

Agent mógł potraktować ją nie jako zwykły tekst do analizy, ale jako polecenie, które powinien wykonać. Taki rodzaj ataku określa się jako prompt injection.

Jeden agent uruchamiał drugiego

Badacze Pillar Security opisali dwa powiązane scenariusze ataku.

Jeden dotyczył automatycznej oceny propozycji zmian w kodzie, a drugi agenta przygotowującego poprawki do zgłoszonych problemów.

W pierwszym przypadku zmanipulowany agent mógł opublikować specjalny komentarz z konta adk-bot. Konto to było skonfigurowane jako konto użytkownika posiadającego status zaufanego współpracownika repozytorium.

Inna automatyzacja sprawdzała, kto opublikował polecenie. Skoro pochodziło ono z zaufanego konta, uruchamiała proces mający większe możliwości, m.in. związane ze sprawdzaniem zmian w kodzie.

W drugim scenariuszu agent analizujący publiczne zgłoszenie mógł zostać nakłoniony do opublikowania komendy uruchamiającej bardziej uprzywilejowanego agenta, który przygotowywał poprawki.

Atakujący nie musiał więc sam posiadać dostępu do chronionego procesu. Wykorzystywał pierwszego, publicznie dostępnego agenta jako pośrednika.

Jakie było zagrożenie?

W jednym ze scenariuszy możliwe było wpływanie na komentarze, oceny i oznaczenia dotyczące proponowanych zmian w kodzie. Mogło to stworzyć fałszywe wrażenie, że szkodliwa modyfikacja została sprawdzona lub zaakceptowana.

Nie oznaczało to jednak, że atakujący mógł samodzielnie opublikować szkodliwą wersję ADK. Zmiana nadal musiała zostać scalona przez uprawnionego opiekuna projektu, dlatego skuteczny atak wymagałby również wprowadzenia go w błąd.

Badacze zademonstrowali także możliwość wykonania dowolnych poleceń na komputerze obsługującym automatyczne zadania repozytorium. Potencjalnie pozwalało to na wyprowadzenie znajdujących się tam tokenów, kluczy i innych danych dostępowych.

Nie było jednak publicznie wiadomo, jakie dokładnie uprawnienia posiadały wszystkie znajdujące się w tym środowisku dane uwierzytelniające.

Google usunęło problematyczne automatyzacje. Nie ma dowodów, aby podatności zostały wykorzystane przez rzeczywistych napastników, doprowadziły do przejęcia repozytorium lub rozpowszechnienia szkodliwej wersji ADK.

Sprawa pokazuje jednak, że w systemach wykorzystujących wielu agentów nie wystarczy kontrolować uprawnień każdego z nich osobno. Trzeba również sprawdzać, czy agent dostępny publicznie nie może wykorzystać zaufania udzielonego bardziej uprzywilejowanemu systemowi.