Монорепозитории делают ИИ-агентов полезнее, но взломанные учетные записи становится труднее изолировать

Исследователям из стартапа в области безопасности Hacktron потребовалось менее 72 часов, чтобы пройти путь от уязвимости на форуме сообщества OpenAI до внутреннего монорепозитория GitHub компании OpenAI, где они создали один безобидный запрос на слияние (pull request) и остановились. Монорепозитории упрощают работу с кодовой базой, но они не изолируют проекты так, как это делают раздельные репозитории. ИИ-агенты для написания кода повышают ставки, поскольку они могут иметь широкий и постоянный доступ.

В своем блоге исследователи Hacktron подробно описали, как они использовали модели Claude от Anthropic для объединения двух критических уязвимостей в цепочку с целью компрометации учетных записей сотрудников OpenAI в ChatGPT. Оттуда скомпрометированная среда Codex сотрудника предоставила им доступ к внутреннему монорепозиторию GitHub компании OpenAI.

Исследователи не стали читать исходный код OpenAI и проверять, как далеко они смогут зайти.

«Поскольку люди могут подключать различные сервисы к Codex и ChatGPT, масштаб того, к чему мы теоретически могли получить доступ, был огромным, включая GitHub, Slack и электронную почту», — написали они.

Как Hacktron добрались до монорепозитория OpenAI

Исследовательская группа Hacktron начала с форума Discourse на community.openai.com. Поскольку форум поддерживал функцию «Войти через OpenAI» (Sign in with OpenAI) через auth.openai.com, исследователи предположили, что его компрометация может открыть им путь к более широким сервисам OpenAI.

Исследователи отследили уязвимость удаленного выполнения кода (RCE) до конвейера загрузки изображений Discourse. После того как Opus 4.8 столкнулся с трудностями при создании надежного эксплойта, они использовали недавно выпущенный Opus 5, чтобы подтвердить возможность достижения локального RCE посредством загрузки изображения.

Они поместили Claude в автономный цикл целей против собственного экземпляра Discourse Cloud в качестве упражнения по захвату флага (CTF) после того, как Opus изначально отказался писать цепочку эксплойтов для удаленного экземпляра. Четыре часа спустя Claude добился RCE на их экземпляре Discourse Cloud. 25 июля исследователи добились RCE на экземпляре OpenAI.

В Hacktron сообщили, что отдельная неправильная конфигурация в инфраструктуре единого входа (SSO) OpenAI позволила использовать скомпрометированный форум для захвата учетных записей ChatGPT и Codex пользователей, которые на нем авторизовались, без каких-либо дополнительных действий. Затем исследователи перехватили учетную запись сотрудника OpenAI, среда Codex которого была подключена к организации GitHub компании OpenAI, и использовали ее для создания концептуального запроса на слияние (PR) во внутреннем монорепозитории. Весь процесс занял менее 72 часов с момента первоткрытия до получения доступа к репозиторию.

Hacktron сообщила об уязвимости в OpenAI, а также отдельно в Discourse. Примерно через 14 часов после первоначального обращения в OpenAI компания подтвердила устранение проблемы. OpenAI не ответила на запрос о комментарии к моменту публикации.

К чему может получить доступ одна скомпрометированная учетная запись

Независимый технологический аналитик Карми Леви назвал инцидент с OpenAI «своего рода предупредительным выстрелом» для всей отрасли. Монорепозитории могут быть удобны, так как они объединяют ресурсы разработки для множества проектов, но когда учетная запись имеет широкий доступ ко всему репозиторию, они также могут превратиться в то, что Леви назвал «монолитной целью» для злоумышленников, стремящихся извлечь максимум выгоды из единой компрометации.

Эрик Авакян, технический консультант Info-Tech Research Group и бывший директор по информационной безопасности (CISO) Содружества Пенсильвания, отметил, что монорепозитории сами по себе не опасны. Проблема заключается в концентрации рисков. Хотя монорепозитории могут содержать код для самых разных приложений, сервисов, библиотек и внутренних систем, это единый репозиторий, и если у конкретной учетной записи есть широкий доступ, потенциальная зона поражения может оказаться гораздо больше, чем люди себе представляют.

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

«Это невероятно полезные возможности, но если агент или учетная запись, от имени которой он действует, будут скомпрометированы, те же самые возможности могут обернуться против вас», — сказал Авакян.

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

GitHub имеет отдельные элементы управления тем, что именно изменяется или объединяется. Платформа может требовать проверки от владельцев кода, в то время как защита ветвей и наборы правил могут требовать проведения проверок, статусной валидации и соблюдения других условий перед слиянием изменений. Эти средства управления могут ограничивать изменения или слияния, но они не ограничивают то, что учетная запись может видеть.

Что необходимо проверить службам безопасности

Предприятиям не стоит воспринимать это как совершенно неизведанную территорию, отметил Авакян. Такие подходы, как OAuth, сервисные учетные записи, недолговечные учетные данные и доступ с наименьшими привилегиями, существуют уже довольно давно и теперь распространяются на ИИ-агентов.

«Прямо сейчас я бы посоветовал директорам по информационной безопасности начинать не с агента, — сказал Авакян, — а с учетных данных».

По словам Авакяна, службы безопасности должны сначала определить, какие учетные данные использует агент кодирования и какую учетную запись они представляют: токен сотрудника OAuth, приложение GitHub, сервисную учетную запись, персональный токен доступа, ключ Secure Shell (SSH) или другие делегированные учетные данные. Исходя из этого, группы безопасности могут оценить реальные разрешения:

• Какие репозитории он может читать?

• В какие он может производить запись?

• Может ли он создавать запросы на слияние, изменять рабочие процессы, получать доступ к секретам или другим подключенным системам?

«Это и становится реальной поверхностью атаки агента, — сказал Авакян. — И если никто не может быстро ответить на эти вопросы, это, вероятно, первая проблема, которую нужно решить».

Авакян заявил, что к агентам кодирования следует относиться как к привилегированным субъектам и, по возможности, предоставлять им выделенные нечеловеческие учетные записи, кратковременные учетные данные и «наиболее узкие разрешения репозитория из возможных». Он также порекомендовал составить инвентаризационный список каждого агента кодирования, а также каждых учетных данных или коннектора, которые может использовать агент, и сопоставить его фактический доступ, а не предполагаемые разрешения. Это включает в себя выявление агентов, работающих с унаследованными учетными данными сотрудников или широкими областями действия OAuth.

Но наступает момент, когда логических средств контроля оказывается недостаточно, отметил Авакян. «Если два фрагмента кода представляют принципиально разные границы безопасности или доверия, помещение их в один монорепозиторий может в конечном итоге непреднамеренно создать ненужный риск», — сказал он.