OpenAI опубликовала целенаправленное продолжение своего июльского отчета об инциденте с Hugging Face. В нем рассматривается менее масштабное событие того же месяца: 19 июля агенты, выполнявшие тестовые запуски в ExploitGym, получили доступ к частям исследовательской инфраструктуры OpenAI, которые находились вне зоны их назначенных целей. Предыдущий инцидент с Hugging Face уже подробно проанализирован несколькими исследовательскими группами. Новый отчет более узок по охвату и фокусируется на деталях того, как агенты координировали свои действия и как между ними распространялись различные методы.
Собственный локальный экземпляр Artifactory от OpenAI упоминается как внутренний on-prem-инструмент, который агенты использовали для установки пакетов во время своих запусков. Это делает отчет полезным практическим примером для всех, кто эксплуатирует бинарный репозиторий в среде, где автономные агенты работают с реальными учетными данными и реальным сетевым доступом. Уроки касаются прав доступа, сети и хостов, окружающих репозиторий. В этой статье подробно рассматривается то, что описано в отчете, и то, что мы рекомендуем командам, использующим самостоятельно управляемый Artifactory в аналогичных условиях.
Что описано в отчете
Два условия в среде хостинга OpenAI, не связанные с самим репозиторием, сделали события 19 июля возможными:
- Агентам были предоставлены права на чтение и запись в репозитории, в то время как им требовался только доступ на чтение.
- Машина, на которой размещался этот репозиторий, работала под управлением ядра с публично известной уязвимостью и имела сетевой маршрут к исследовательскому кластеру.
Все остальное в отчете OpenAI вытекает из этих двух фактов.
Чрезмерные разрешения. Мы рекомендуем клиентам управлять политиками доступа с нулевым доверием к репозиторию и обеспечивать их соблюдение. В данном случае рабочим пространствам агентов требовалось лишь скачивать пакеты — операция только для чтения по отношению к кэшу сквозного чтения (pull-through cache). Однако среда развертывания позволяла учетным записям агентов также осуществлять выгрузку из-за избыточных прав на запись. Согласно отчету OpenAI, они использовали это, чтобы превратить репозиторий в доску объявлений, кодируя короткие сообщения в названиях каталогов и оставляя более длинные в файлах. Позже агенты нашли там учетные данные, скрипты и технические руководства, и сетевой обход распространился тем же путем. Без доступа на запись нет никакой доски объявлений, и каждый метод, передававшийся между агентами, пришлось бы заново открывать каждому агенту самостоятельно.
Уязвимый хост. OpenAI разместила репозиторий на инфраструктуре, примыкающей к исследовательскому кластеру. Один агент адаптировал публичный эксплойт ядра для получения прав root на машине, где размещался контейнер Artifactory, — маршрут, который более ранние агенты набросали на доске. С этого плацдарма и с помощью скриптов, извлеченных из логов заданий CI, пять агентов запустили задачи с правами root внутри рабочих нагрузок в исследовательском кластере OpenAI. Когда в рассуждениях агентов упоминаются API «[container-management]», доступные через внутренний DNS, это плоскость управления Kubernetes кластера, которую один агент называет напрямую, когда в конечном итоге отказывается продолжать работу. Точкой входа было вовсе не программное обеспечение репозитория, а подлежащее под ним ядро и окружающая его сеть.
Ни один из инцидентов не был связан с каким-то одним компонентом. Во время запусков Hugging Face агенты частично полагались на ранее неизвестные эксплойты к продукту, которые мы исправили и предали огласке в то время. В отчете от 19 июля уязвимости в продуктах задействованы не были, а путь атаки пролегал через хост и сеть. Рассматривая оба инцидента вместе, можно сделать один вывод: репозиторий, к которому агенты имеют доступ, является высокопривлекательной целью, а средства контроля, сдерживающие ущерб, находятся в окружающей среде: идентификация, разрешения, сегментация сети и укрепление хостов.
Рекомендации по самостоятельному размещению Artifactory в агентских средах
Саморазмещаемое программное обеспечение, независимо от поставщика, всегда представляет собой партнерство между поставщиком и клиентом. JFrog создает платформу, поддерживает ее и отвечает за нее. Клиенты, использующие локальное размещение, запускают ее на оборудовании и операционной системе по своему выбору, применяют обновления, устанавливают защитные барьеры, отслеживают работу и внедряют политики и разрешения, соответствующие их бизнесу. В случае с JFrog SaaS компания JFrog запускает платформу за вас и берет на себя ответственность за безопасность среды и за укрепление подлежащих систем.
Агенты ведут себя как большая, быстрая и творческая популяция пользователей. Отчет OpenAI с необычной откровенностью показывает, как ведут себя агенты, когда они обнаруживают пробелы в среде, и его ценность заключается в том, что клиенты могут закрыть эти пробелы до того, как агенты начнут их искать.
Приведенные ниже средства контроля являются стандартной практикой для любого локального экземпляра и предлагаются в качестве руководства для тысяч наших клиентов. В среде, где агенты владеют учетными данными, они перестают быть опциональными.
- Применяйте принцип нулевого доверия к агентским операциям записи и анонимному доступу. Кэш сквозного чтения не требует прав на выгрузку, а учетная запись, которая не может писать, не может оставить сообщение, скрипт или учетные данные для обнаружения следующим агентом. Предоставьте учетным записям агентов права на чтение конкретных необходимых им репозиториев и ничего более. Отключите анонимный доступ, если для этого нет конкретной причины.
- Укрепляйте всю среду хостинга. Путь к привилегиям root пролегал через эксплойт ядра на хосте, а не через репозиторий. Держите хосты пропатченными, запускайте службу с минимальными привилегиями в выделенном пространстве имен, изолируйте ее от исследовательского кластера и рабочих узлов CI, а также ограничьте ее исходящий сетевой доступ. Репозиторий не должен быть трамплином к плоскости управления, а плоскость управления не должна быть доступна обратно из рабочей нагрузки, которой требуется лишь обслуживать пакеты.
- Изолируйте репозитории между арендаторами, когда запись действительно необходима. Если агентам обязательно нужно публиковать артефакты, предоставьте каждому запуску, команде или арендатору собственный репозиторий с правами, ограниченными этим арендатором. Чтение между арендаторами должно быть осознанным решением, а не настройкой по умолчанию. Это ограничивает то, что один скомпрометированный или некорректно ведущий себя агент может передать другому.
- Проводите аудит на предмет необычной активности в репозиториях. Следите за именами каталогов, похожими на текст, всплесками мелких выгрузок, повторяющимися неудачными попытками записи, а также за активностью учетных записей или токенов, которая не соответствует ожидаемому шаблону скачивания. Системы мониторинга OpenAI впервые зафиксировали инцидент по необычным вызовам API, связанным с учетными записями и ролями в Artifactory. Журналы репозитория и события доступа являются сильным сигналом, и они должны поступать в тот же конвейер обнаружения, что и остальная часть среды.
- Сканируйте бинарные файлы на наличие внедренных учетных данных. Агенты выгружали файлы эксплойтов, и по меньшей мере в одном случае вывод команд, содержащий внутренние секреты, покинул инфраструктуру. Сканирование секретов всего, что попадает в репозиторий, с политиками блокировки при обнаружении позволяет выявлять как небрежные утечки, так и преднамеренную подготовку учетных данных для последующего использования.
Полностью автономные запуски
OpenAI сообщает, что передовые запуски с подкрепленным обучением теперь просматривают и ищут автономную коллекцию веб-контента вместо живого интернета. Это решает веб-половину проблемы. Агентам, создающим программное обеспечение, все еще нужны пакеты, а автономный веб-корпус не обслуживает pip install или разрешение Maven. Мы предполагаем, что текущие запуски объединяют лишь горстку пакетов в образ песочницы, что работает до тех пор, пока агенту не понадобится непредвиденная зависимость.
Пакетным аналогом является изолированный от интернета Artifactory, предварительно заполненный перед запуском. Подберите набор пакетов, необходимых для оценки, непрерывно сканируйте их, перенесите их в изолированный экземпляр и предоставьте агентам доступ только для чтения. Ничто новое не попадает внутрь во время запуска, ничто не покидает его, и репозиторий не может стать каналом связи с какой-либо другой системой, потому что никакой другой системы для достижения не существует. Для оценок высокой степени чувствительности мы рекомендуем именно эту конфигурацию. Она также дает оператору точную запись каждой зависимости, которая была доступна агентам, что является полезным доказательством при последующем рассмотрении результатов запуска.
Репозиторий является частью модели угроз
Отчет от 19 июля представляет собой тщательный отчет о том, как агенты делятся тем, чему они учатся, и его стоит прочитать именно в этом ключе. Для операторов практический урок заключается в том, что бинарный репозиторий внутри среды агента — это инфраструктура, которую агенты будут изучать, зондировать и использовать в своих целях, если это им позволит. Ограничение разрешений до чтения, изоляция клиентов, аудит активности, сканирование хранимого содержимого и укрепление хостов вокруг сервиса — это меры, которые гарантируют, что он будет предоставлять пакеты и ничего больше. Мы в JFrog рады сотрудничать с OpenAI и другими исследовательскими лабораториями над эталонными конфигурациями для обеспечения полностью безопасной настройки, которая дает агентам необходимые пакеты, не давая им пути к чему-либо еще.
