Манипуляция агентами: эксплуатация уязвимостей в репозитории Google Agent Development Kit

Исследователи Pillar Security зафиксировали первый случай использования одного ИИ-агента другим в реальном продакшен-окружении. Уникальная на данный момент уязвимость была найдена в google/adk-python — репозитории Google Agent Development Kit для Python.

В репозитории работали два класса автоматизированных ИИ-агентов. Первый класс агентов с низким уровнем привилегий был встроен в рабочие процессы, доступные всем, такие как PR или Issue. Второй же класс имел высокий уровень доступа и предназначался только для мэйнтейнеров. Уязвимость заключалась в том, что низкопривилегированным агентом, доступным для всех, можно было манипулировать, чтобы он активировал высокопривилегированного агента.

Каким был сценарий атаки

Перед разбором цепочки важно знать, что в репозитории Google ADK есть два бота.

adk-bot — тот самый непривилегированный ИИ-агент, комментирующий PR от имени обычного разработчика (collaborator), триажер для PR и Issue.
gemini-cli — высокопривилегированный, нужен для проверки кода, одобрения PR.

Ключевая особенность заключалась в том, что система доверяла не человеку, а учетной записи агента. Сообщение, автоматически опубликованное adk-bot, воспринималось как действие доверенного участника проекта.

Рассмотрим, как выглядит сценарий атаки.

Атакующий создает вредоносный PR. Внутри описания закладывается промпт-инъекция.
adk-bot читает содержимое, которое «вынуждает» его обратиться к gemini-cli в формате @gemini-cli .
gemini-dispatch.yml видит упоминание @gemini-cli от пользователя c ролью collaborator (из-за привязки adk-bot к аккаунту) и направляет в gemini-invoke.yml.
Инъекция передается в контекст обработки высокопривилегированного агента и воспринимается как часть инструкции. Агент при этом уже имеет доступ для проверки кода в PR, его одобрении от имени github-actions[bot], а также удалении или редактировании комментариев других разработчиков.
Далее работает социальная инженерия: атакующий открывает PR с вредоносным кодом, через описанную цепочку заставляет gemini-cli «одобрить» внесение изменений. Мейнтейнер видит, что бот одобрил, и может смержить код, думая, что проверка безопасности успешно пройдена.

Источник.

По сути, исследователи продемонстрировали современную реализацию давно известной проблемы confused deputy. Низкопривилегированный агент не обладал расширенными правами самостоятельно, но мог инициировать действия от имени доверенного субъекта. В результате модель разграничения доступа нарушалась не за счет ошибки в механизме авторизации, а из-за некорректного распределения доверия между агентами.

Пример confused deputy. Речь здесь не о ИИ-агентах, но логика осталась прежней. Источник.

В результате злоумышленник мог создать полностью легитимный на вид след «автоматической проверки и одобрения со стороны ИИ» для вредоносного PR, провоцируя мейнтейнеров на его слияние с основной веткой.

На данный момент Google устранила основные проблемы, которые изначально привели к уязвимости. И хотя компания не сочла социальную инженерию решающим фактором в данном случае, было подтверждено, что проведены работы по укреплению репозитория.

Security Center

Рассказываем о лучших практиках и средствах ИБ, требованиях и изменениях в законодательстве.

Исследовать →

RCE и обход песочницы в Antigravity-SDK

Вскоре после первой находки Google добавил в репозиторий автоматизацию на базе Antigravity-SDK (scripts/run_antigravity.py). Процесс состоял из двух воркфлоу:

issue-analyze.yml — автоматически анализировал любые новые баг-репорты (Issues) от внешних пользователей.
issue-fix.yml — активировался при публикации комментария /adk-issue-fix от доверенного лица и автоматически писал код для исправления проблемы.

Цепочка атаки и обход ограничений

Злоумышленник оставлял промпт-инъекцию прямо в тексте нового Issue. Воркфлоу анализа считывал его и под воздействием инъекции сам отправлял команду /adk-issue-fix. Поскольку бот комментировал от имени легитимного соавтора (adk-bot), система воспринимала это как доверенное действие и запускала привилегированный процесс исправления.

Далее воркфлоу исправления передавал управление агенту, чьи команды фильтровались функцией issafe_command. Фильтр блокировал опасные метасимволы (вроде ;, |, &, $) и разрешал запуск только утилит git и gh.

Исследователи обошли защиту двумя путями.

Использование git как лаунчера: утилита запускалась без запрещенных символов, но выполняла произвольный код через встроенные параметры (например, git -c "alias.x=!" x или подмену путей хуков git -c core.hooksPath=...).
Неконтролируемая запись файлов: фильтр проверял только запуск команд, а инструмент записи файлов оставался открытым. Агент мог сначала записать вредоносный скрипт на диск, а затем выполнить его через легитимный git.

Атакующий получал удаленное выполнение кода (RCE) на CI-раннере GitHub. Это позволяло беспрепятственно выгрузить из переменных окружения долгоживущий персональный токен бота ADK_TRIAGE_AGENT и ключ сервисного аккаунта Google Cloud (ADK_GCP_SA_KEY), имевший доступ к платформе Vertex AI.

На данный момент уязвимый воркфлоу полностью удален из репозитория, а сама проблема устранена.

Выводы

ИИ-агенты в силу своей эффективности получают все более широкую известность, постоянно расширяются сферы их применения, но вместе с силой растет и ответственность. Данная уязвимость показала, что агент может стать инструментом для эскалирования привилегий, переходить тонко очерченную границу между доступами.

Это наталкивает на мысль, что нужно создавать новые подходы для обеспечения безопасности:

Не выдавать агенту доступ к реальным учетным записям сотрудников.
С особой осторожностью оценивать риски выдачи прав одному агенту на взаимодействие с другим.
В отношении агентов, контактирующих с ненадежными источниками данных, нужно применять политику нулевого доверия, а также задавать жесткие системные промпты.
Реализовывать систему мониторинга модели: кто именно запускает выполнение флоу, какие действия она выполняет в ответ на запрос.

Источник: habr.com

0 0 голоса

Рейтинг новости