Уязвимости безопасности в автоматизированных рабочих процессах репозитория GitHub для Agent Development Kit от Google для Python могут позволить публичным AI-агентам запускать более привилегированную автоматизацию, открывая один путь для манипуляции рецензированием pull-запросов и другой — для раскрытия учетных данных, согласно отчету Pillar Security.
Первый путь атаки включал агента-триажа, который анализировал pull-запросы, отправленные внешними участниками. Агент публиковал свои ответы через adk-bot — учетную запись с доступом коллаборатора к репозиторию. Pillar обнаружил, что вредоносные инструкции, встроенные в pull-запрос, могли побудить агента отправить команду «@gemini-cli», запуская рабочий процесс, предназначенный для доверенных пользователей.
Этот рабочий процесс мог обеспечить выполнение команд внутри его CI-раннера. Его GitHub-токен не мог отправлять код, но имел права на запись в issues и pull-запросы. Pillar заявил, что эти разрешения можно было использовать для изменения комментария мейнтейнера, отправки одобрительного ревью от имени github-actions[bot] и удаления легитимного запроса на рецензирование, делая вредоносный pull-запрос готовым к слиянию.
Pillar воспроизвел первую цепочку атак в своей исследовательской среде. Мейнтейнер все еще должен был завершить слияние, и в отчете говорится, что Google впоследствии усилил защиту репозитория.
Фирма по безопасности также обнаружила отдельный путь атаки в более новых рабочих процессах, построенных вокруг агента на основе Antigravity. Злоумышленник мог разместить инъекцию промпта в публичном issue и побудить агента-аналитика отправить команду, запускающую исправляющий рабочий процесс, зарезервированный для доверенных пользователей репозитория.
Исправляющий рабочий процесс пытался ограничить агента командами Git и GitHub, но Pillar обнаружил, что Git все еще можно использовать для запуска произвольного кода. Исследователи продемонстрировали, что персональный токен доступа adk-bot может быть извлечен из раннера на сервер, контролируемый злоумышленником, в то время как ключ сервисной учетной записи Google Cloud также был доступен рабочему процессу.
Pillar сообщил, что 2 июля подтвердил удаление затронутых рабочих процессов, а 21 июля Google уведомил исследователей об исправлении второй проблемы.
Передача полномочий между агентами раскрывает риски
Pillar охарактеризовал находки как «первый практический, реальный случай эксплуатации агента агентом» с участием производственной мультиагентной системы.
Санчит Вир Гогия, главный аналитик Greyhound Research, отметил, что базовые уязвимости были знакомы, но их взаимодействие требует от предприятий пересмотреть, как полномочия перемещаются в агентных системах.
«Естественный язык присоединился к пути авторизации», — сказал Гогия. «Это изменение, о котором стоит сообщить, а не формулировка „впервые“».
Гогия добавил, что полномочия агента следует измерять не только назначенными ему инструментами, но и более привилегированными системами, которые его выходные данные могут запустить или на которые могут повлиять.
Этот более широкий охват также должен влиять на то, как CISО оценивают серьезность риска, согласно Сакши Гровер, старшему менеджеру по исследованиям IDC Asia Pacific Cybersecurity Services.
«Для CISО существенность должна определяться отслеживанием трех вещей», — сказал Гровер. «Во-первых, какие агенты потребляют недоверенный контент, такой как pull-запросы, issues, электронные письма, тикеты поддержки или внешние документы? Во-вторых, могут ли выходные данные этих агентов прямо или косвенно запустить другого агента или рабочий процесс с более высокими привилегиями? В-третьих, какова максимальная эффективная способность задействованных идентификаторов, учетных данных и инструментов?»
Картирование транзитивных полномочий
Существующие инструменты безопасности могут предоставлять лишь частичное представление о том, как полномочия перемещаются между агентами и рабочими процессами.
Гровер сказал, что инструменты IAM, PAM, CIEM и безопасности приложений могут раскрывать отдельные идентификаторы, разрешения и небезопасные конфигурации рабочих процессов, но могут не распознавать, что эти компоненты образуют единый путь делегирования, управляемый событиями.
«Инвентаризация фиксирует, что существует, в то время как картирование делегирования фиксирует, что может произойти», — сказал Гогия.
Гогия добавил, что команды безопасности должны отслеживать внешние входные данные от точки их поступления к агенту до любой нижестоящей системы, которая действует на основе результата. Обзор также должен учитывать передачи, встроенные в общее состояние рабочего процесса, такие как комментарий, запускающий команду.
«Более сложный вопрос не в том, может ли Агент А вызвать Агента Б, а в том, может ли Агент А изменить что-либо, чему Агент Б уже доверяет», — сказал он.
Человеческое одобрение не обязательно закрывает этот пробел. Хотя первый путь атаки все еще требовал от мейнтейнера слияния pull-запроса, манипулируемая автоматизация могла повлиять на доказательства, представленные мейнтейнеру.
«Злоумышленнику не нужны права на слияние, когда он может сфабриковать доказательства, которые убедят кого-то другого выполнить слияние», — сказал Гогия. Он добавил, что одобрение должно привязывать независимо аутентифицированного рецензента к точному проверенному коду или артефакту. Любое существенное изменение должно аннулировать это одобрение.
Гровер добавил, что изменения в рецензиях, комментариях и статусах одобрения также следует рассматривать как события безопасности и экспортировать в независимую систему журналирования, которую не может изменить собственная идентичность рабочего процесса.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Prasanth Aby Thomas
