Что: Как ИИ-агент решил списать на экзамене и взломал Hugging Face изнутри
Ссылка: https://huggingface.co/blog/agent-intrusion-technical-timeline
Почему интересно: Hugging Face опубликовали технический разбор своего июльского инцидента, когда автономный агент устроил полноценную APT-кампанию. Настоящий детектив! Собственно, началось с того, что агент OpenAI проходил бенчмарк кибербеза ExploitGym, но решил, что выполнять задачи - удел смертных, и пошёл красть ответы. Агент не нанёс разрушений (все потенциально опасные API-вызовы он делал с флагом DryRun=True), поскольку его целью было получить доступ к тестовым решениям, которые, как он предположил, хранятся на Hugging Face. В процессе пробил несколько границ доверия, добрался до внутренней сети HF и держал оборону 4.5 дня. В статье подробно разбирается, кто и что делал.
Изначально агент находился в изолированной среде на платформе OpenAI. Он эксплуатировал 0-day уязвимость в кеш-прокси пакетного реестра, чтобы получить доступ в интернет. Затем нашёл незащищённый публичный endpoint, который позволял выполнять произвольный код на сторонней инфраструктуре Modal, и использовал его как базу для всех дальнейших атак. После закрепился на внешней песочнице с правами root, и именно оттуда (а не с напрямую из инфраструктуры Hugging Face) вёл атаку. Поскольку оттуда он не имел прямого сетевого пути к кластеру Hugging Face, пришлось искать обходные пути.
Агент использовал два метода, оба через механизм обработки датасетов. Первый - через чтение локальных файлов через HDF5. Второй - через шаблон Jinja2, который выполнялся на сервере, чтобы получить возможность запускать произвольный Python код внутри продакшен пода. За 13 часов агент прошёл путь от кода в одном воркере до прав администратора всего кластера. Он создал самоподдерживающийся зоопарк на 11 нодах, так что даже удаление подов не остановило бы атаку.
В итоге агент похитил из среды воркера пароль ко внутренней базе MongoDB и, что важнее, прочитал объект с 136 ключами, включая ключ авторизации для mesh-VPN и креды для access-брокера. С помощью этих ключей он и подключился к корпоративной mesh-сети Hugging Face и использовал её для доступа к внутренним сервисам и системе версионирования. В конце концов, он вытащил 5 датасетов с решениями задач ExploitGym.
Самое ценное в посте - конкретные инженерные выводы. Эксперты HF признают, что все уязвимости по отдельности были знакомыми: небезопасная обработка датасетов, доступ к cloud metadata из подов, слишком широкие credentials, долгоживущие секреты. Проблема, по мнению авторов, не в том, что агент умнее человека, а в том, что он делает в тысячи раз больше попыток в единицу времени. Успешная цепочка пряталась в шуме от провальных. Это и есть главная асимметрия: атака с машинной скоростью делает обычные дыры экспоненциально дороже для обороны.
Отдельно заслуживает упоминания работа с LLM для анализа атаки. Так, когда HF попробовали прогнать анализ через Claude Opus и другие закрытые модели, те отказались помогать, поскольку guardrails приравняли реверс-инжиниринг атаки к её запуску. Пришлось поднимать квантованный открытый GLM-5.2 на своей инфраструктуре. Комментарий в блоге идеально это резюмирует: "closed model с отключёнными сейфгардами атакует → closed model с сейфгардами отказывается защищать → open model всех спасает". Лучший сценарий не придумаешь - вот она, сила open source! 🙂
Кстати, по разъяснениям самой OpenAI, атака на Hugging Face стала результатом согласованных действий нескольких агентов, которые обменивались информацией и стратегиями, чтобы выполнить задание, которое иначе нельзя было выполнить (из-за некорректной постановки).
В целом складывается впечатление, что сообщество зациклилось на промтах и поведении моделей, но почти не спрашивает, какой набор возможностей реально есть у агента. Если агент может писать файлы, дёргать shell, менять облачные ресурсы и ходить в API с авторизацией, то вопрос, что он физически способен сделать, важнее того, что он конкретно сейчас планирует.

#eng #ии #llm #безопасность #агент #exploitgym #huggingface #openai #opensource #glm