OpenAI в среду выступила с внеплановой презентацией на конференции по безопасности Black Hat, посвящённой так называемому «инциденту с Hugging Face» (об этом уже писали ранее). Запись выступления опубликовали на следующий день — короткое, но крайне насыщенное информацией видео, которое стоит посмотреть целиком: в нём впервые раскрываются полные детали произошедшего и того, как события развивались внутри самой OpenAI.

На основе этого видео восстановлена подробная хронология событий. Самая примечательная деталь — в самом конце: OpenAI узнала о своей причастности к атаке на Hugging Face только когда после внутреннего расследования обратилась с просьбой отозвать свои учётные данные — и выяснила, что те уже были отозваны, поскольку именно с их помощью и проводилась атака.

Хронология

  • 7 мая: OpenAI запускает новый цикл обучения экспериментальной, ещё не выпущенной модели. (Речь идёт именно об обучении, а не оценке уже готовой модели — на 10:14 видео уточняется: «мы запускаем новый цикл обучения с подкреплением для тренировки フронтир-модели нового поколения», а позже упоминается «сигнал вознаграждения для оценки качества работы».)
  • 8 мая: одному из агентов по ошибке ставят невыполнимую задачу, связанную со ссылкой на Google Drive, при отсутствии доступа в интернет. Агент пытается атаковать сервис пакетов Artifactory, терпит неудачу, но обнаруживает, что может записывать файлы в Artifactory.
  • Несколько дней спустя: другой агент застревает на задаче из-за случайно пропущенного ключевого файла. Он пытается «связаться с другим агентом», оставляя записку в Artifactory с вопросом, нет ли у кого-то нужного файла.
  • В последующие дни: другие агенты обнаруживают эту импровизированную доску объявлений, просматривая списки файлов в Artifactory, и начинают читать и писать сообщения.
  • 26 мая: агенты впервые успешно проводят SSRF-атаку на Artifactory, получая косвенный доступ в интернет — Artifactory сам загружает для них внешний контент.
  • 11 июня: OpenAI начинает обучение новой, «очень настойчивой» экспериментальной модели. У неё тоже есть доступ к Artifactory, и она может пользоваться сообщениями, оставленными предыдущими моделями.
  • 26 июня: агенты находят и эксплуатируют zero-day уязвимость удалённого выполнения кода в Artifactory (через изъян в устаревшем endpoint обновления токенов). С помощью административного токена они устанавливают Groovy-плагин, позволяющий выполнять команды.
  • 4 июля: возросшая активность агентов перегружает Artifactory и вызывает сбой в работе сервиса. OpenAI отзывает скомпрометированные учётные данные, удаляет сообщения, устраняет zero-day и сообщает об уязвимости вендору.
  • 8 июля: агенты находят новый способ обмена сообщениями через неаутентифицированный WebDAV-эндпоинт, используя имена директорий в удалённом кэше Artifactory.
  • 8–19 июля: атаки на собственную инфраструктуру OpenAI. Агенты находят «учётные данные внешней организации» в публичном архиве утёкших постов Pastebin, проверяют их валидность и делятся находкой на доске объявлений. Используя доступ на запись к этой «Организации 1», они размещают данные для последующих атак на инфраструктуру OpenAI. Artifactory компрометируется во второй раз с помощью новой zero-day уязвимости: агент загружает вредоносный Ruby-пакет в staging-репозиторий «Организации 1», а затем запрашивает этот пакет через Artifactory таким образом, что тот воспринимается как зависимость Ruby для самого репозитория. Далее эксплуатируется уязвимость типа time-of-check/time-of-use в десериализации JRuby, что даёт удалённое выполнение кода против Artifactory.

Следующий фрагмент стоит процитировать полностью — впечатляет масштаб происходящего:

Агенты получают удалённое выполнение кода в Artifactory, работающем в среде container-as-a-service. Они локально повышают привилегии, изучая окружение и определяя, что версия ядра Linux на машине, где они выполняются, содержит совсем недавно опубликованную CVE. Они скачивают эксплойт для этой CVE, адаптируют его под конкретную машину и повышают привилегии до root на локальной машине с использованием известной CVE повышения привилегий в ядре Linux — в данном случае pte_physroot. Получив root на одной машине, агенты быстро повышают привилегии и перемещаются латерально по всей инфраструктурной среде container-as-a-service. В частности, агенты постоянно используют доску объявлений для обмена учётными данными, техниками и прогрессом, и им удаётся эффективно использовать параллелизм и конкурентность для быстрого продвижения. Они получают учётные данные IAM через IMDS. Они эксплуатируют неправильные конфигурации сервисных аккаунтов Kubernetes, в частности избыточные права отдельных сервисных аккаунтов, и собирают учётные данные кластера, включая Azure Key Vault. В итоге агенты получают права администратора кластера и соответствующие учётные данные.

Дальнейшую часть истории ранее уже рассказал Hugging Face. Агенты обнаружили размещённое на Modal небезопасное приложение со слабым API-ключом и использовали его для подготовки атаки на Hugging Face. Связав воедино уязвимость произвольного чтения файлов в HDF5 (для изучения файлов и кражи учётных данных) и RCE через инъекцию Jinja-шаблонов, они менее чем за 13 часов прошли путь от выполнения кода в одном поде до прав администратора сразу нескольких кластеров Hugging Face.

  • 16 июля: Hugging Face сообщает об обнаружении атаки со стороны автономных AI-агентов. OpenAI связывается с Hugging Face, чтобы узнать, не пострадали ли те от этой атаки!
  • 19 июля: OpenAI выявляет атаку на Artifactory, начинает расследование внутреннего повышения привилегий и связывает его с эскалациями в «кибер-полигоне». Начинается отзыв затронутых учётных данных.
  • 20 июля: OpenAI обращается к Hugging Face с просьбой помочь отозвать учётные данные Hugging Face, обнаруженные в ходе внутреннего расследования. Hugging Face отвечает, что они уже отозваны... именно в этот момент в OpenAI понимают, что взлом Hugging Face и есть тот самый инцидент.