Специалисты компании Pillar Security выявили две критические уязвимости в хранилище кода Google Agent Development Kit для Python. Эти недостатки злоумышленники могли использовать для активации привилегированного ИИ-агента. Первая уязвимость предоставляла возможность подделать проверку запроса на слияние, вторая позволяла выполнять любой код в автоматизированной системе обработки и извлекать конфиденциальную информацию.
Google ADK — это свободно распространяемый набор утилит для разработки и запуска ИИ-агентов. Программный пакет был загружен более 90 миллионов раз пользователями по всему миру.
По словам исследователя из компании Pillar Security Дэна Лисичкина, уязвимости коренились не в самом пакете Python, а в процессах автоматизации его GitHub-хранилища. В репозитории функционировали два вида агентов: агенты с ограниченными правами обрабатывали публичные запросы и заявки, в то время как другие агенты были предназначены только для администраторов и имели право изменять исходный код, выполнять операции и получать доступ к конфиденциальным данным. Обе категории агентов не имели надлежащей защиты от взаимодействия между собой.
Первый сценарий атаки, разработанный исследователями, предусматривал следующее: нарушитель создавал запрос на слияние с полезным исправлением и вредоносным скриптом, а затем подготавливал еще один запрос с внедренным текстом. Система проверки обрабатывала этот второй запрос и публиковала служебную инструкцию с тегом @gemini-cli в комментариях. Поскольку сообщение исходило от авторитетного аккаунта, это запускало воркфлоу с расширенными полномочиями.
В результате нарушитель получал возможность заполучить токен доступа GitHub и влиять на функционирование хранилища, включая редактирование комментариев, заявок и запросов на слияние, отклонение оценок кода от других пользователей, одобрение изменений и запуск Gemini для любого запроса на слияние.
Кроме того, эту методику можно было применить для создания полностью сфальсифицированной записи о проверке: якобы человек потребовал оценки кода, а Gemini ее провел и одобрил, хотя на деле этого не произошло. Однако здесь следует отметить, что администратор в любом случае должен был вручную одобрить и объединить вредоносный запрос на слияние с главной веткой, что требовало использования манипуляций и обмана.
Позднее исследователи выявили второй, еще более серьезный способ атаки, затрагивающий системы на основе Antigravity SDK. В этом сценарии публичный агент самостоятельно анализировал новые заявки и оставлял ответы от имени adk-bot. Так как бот обладал статусом участника проекта, посредством внедрения текста его можно было заставить отправить команду /adk-issue-fix. Таким образом, команда, которую на самом деле предоставил сторонний человек, проходила валидацию и активировала агента с повышенными привилегиями для исправления программного кода.
Агент, запущенный таким способом, получал возможность видоизменять структуру хранилища, создавать новые ветви кода и запросы на слияние, а также функционировал в среде с токеном бота, ключом доступа Google и данными сервисного аккаунта в Google Cloud. Исследователи в своем анализе показали, как можно было выполнить произвольные инструкции в системе непрерывной интеграции и получить персональный токен доступа (PAT), который использовал бот.
Замечается, что в автоматизированных процессах делались попытки ограничить доступные команды, разрешив только gh и git, однако агенту оставили возможность сохранять информацию на жесткий диск. Благодаря этому он мог сохранить вредоносный код на накопитель, указать необычное расположение для скриптов запуска и активировать опасный код используя разрешенную команду git.
Эксперты отмечают, что компрометированных версий ADK и признаков реальных атак с использованием этих уязвимостей не обнаружено. На данный момент команда инженеров из Google уже повысила уровень защиты хранилища и деактивировала три рискованных автоматизированных процесса — issue-analyze.yml, issue-fix.yml и pr-analyze.yml.
Лисичкин подчеркивает, что разделения агентов по правам доступа уже недостаточно, и каждый бот должен работать под отдельной учетной записью с минимальным набором разрешений и строгими ограничениями доступа к ресурсам. Также исследователь советует разработчикам использовать отдельные аккаунты для различных ботов, сокращать полномочия их токенов и не полагаться на безопасность только потому, что команды опубликованы ботом.
