Системы безопасности ИИ заблокировали защитников Hugging Face
Источник: VentureBeat · Louis Columbus
Команда реагирования на инциденты компании Hugging Face сначала обратилась к передовым ИИ-моделям для анализа взлома своей производственной инфраструктуры, однако модели отказались помогать. Коммерческие защитные механизмы, созданные для блокировки злоумышленников, отклоняли любые запросы для проведения криминалистической экспертизы, поскольку воспринимали реальные данные об эксплойтах, с которыми работала команда, точно так же, как реальную атаку.
Злоумышленник — автономный ИИ-агент, управлявший всей кампанией от начала и до конца — беспрепятственно и незаметно перемещался по инфраструктуре Hugging Face в течение всего уик-энда.
Руководители сферы безопасности быстро распознали этот паттерн и диагностировали проблему. «Я видела версии подобных ситуаций во время учений «красных команд» (red team) и внутреннего тестирования безопасности, но это один из первых громких случаев, когда это реально повлияло на ликвидацию инцидента», — отметила Мерритт Бэр (Merritt Baer), старший советник в компаниях Andesite, G2I и AppOmni, а также бывший заместитель директора по информационной безопасности (CISO) в AWS.
По словам Бэр, ничто из этого не уникально для Hugging Face. «Коммерческие передовые модели оптимизированы для предотвращения злоупотреблений. У них, как правило, нет криптографических или организационных инструментов, чтобы определить, является ли человек, запрашивающий «проанализируйте это вредоносное ПО», специалистом по реагированию на инциденты или автором вредоносного софта».
Вредоносный набор данных открыл два пути для выполнения кода
16 июля компания Hugging Face сообщила, что автономная ИИ-агентная система скомпрометировала ее производственную инфраструктуру, получив несанкционированный доступ к ограниченному набору внутренних датасетов и нескольким учетным данным сервисов. Компания подтвердила, что ее цепочка поставок программного обеспечения не затронута и не обнаружила никаких следов вмешательства в публичные модели, датасеты или пространства (Spaces).
Hugging Face все еще оценивает, затронуло ли вторжение какие-либо данные партнеров или клиентов, и заявляет, что свяжется с пострадавшими сторонами напрямую в случае необходимости. Однако лишь немногие корпоративные модели угроз учитывали тип злоумышленника, с которым столкнулась Hugging Face. Автономный агент руководил всей кампанией — от первоначального доступа до сбора учетных данных. Никакой человек им не управлял.
Точкой входа стал вредоносный датасет. Когда конвейер обработки данных (data-processing pipeline) загрузил его, набор данных инициировал выполнение кода двумя способами: через загрузчик удаленного кода и через уязвимость внедрения шаблонов (template-injection) в конфигурационных файлах датасетов. Никакой шлюз допуска не проверял файл до того, как он попал к рабочему процессу (worker), выполняющему вычислительную задачу для каждого датасета. Первоначальный доступ был осуществлен через сам конвейер данных — этот путь сработал, потому что большинство команд корпоративной безопасности рассматривают данные, поступающие в их конвейеры, как доверенный ввод, а не как поверхность атаки.
Изоляция воркеров не сработала. Получив первый плацдарм, агент прорвался на узел, выполняющий рабочую нагрузку, после чего собрал облачные учетные данные и учетные данные кластера, обладающие достаточными привилегиями для доступа к нескольким внутренним кластерам — и все это всего за одни выходные. В Hugging Face описали фреймворк агента как инструмент, выполняющий тысячи отдельных действий через рой недолговечных песочниц, с самомигрирующим управлением и контролем (C2), размещенным на общедоступных сервисах. В сообщении также отмечается, что фреймворк, судя по всему, был создан на базе специализированного ПО для исследования безопасности (red-team harness), что позволило использовать инструменты для имитации атак в реальном вторжении.
Почему запросы защитников выглядели как атаки
С помощью собственных ИИ-аналитиков исследователи восстановили более 17 000 зарегистрированных событий.
Первые попытки анализа логов выполнялись на передовых моделях, работающих через коммерческие API. Действия защитников включали отправку реальных команд атаки, полезных нагрузок эксплойтов и артефактов управления и контроля (C2) для классификации, но защитные механизмы напрямую блокировали эти запросы.
Бэр объяснила блокировку самими промптами. «Те же самые промпты, которые наиболее ценны во время активного вторжения — команды оболочки (shell), цепочки эксплойтов, дампы учетных данных, механизмы закрепления, латеральное перемещение — это как раз те промпты, которые с наибольшей вероятностью активируют системы безопасности, — рассказала она изданию VentureBeat. — По мере того как ИИ внедряется в операции по безопасности, это становится проблемой операционной устойчивости, а не просто вопросом политики модели».
Криминалистический анализ завершили на GLM 5.2
Модель GLM 5.2, развернутая с открытыми весами (open-weight) на собственной инфраструктуре Hugging Face, взяла на себя задачу, от которой отказались коммерческие API. Никакие данные злоумышленников не покидали периметр компании. «Этот опыт указывает на пробел, к которому стоит подготовиться», — написала компания в своем отчете. Hugging Face не знает, какая именно модель управляла агентами. Это могла быть хостинговая модель со снятыми ограничениями (jailbroken) или модель с открытыми весами, работающая без ограничений. В любом случае, отмечается в заявлении, «злоумышленник не был связан никакими правилами использования, в то время как наша собственная криминалистическая работа блокировалась защитными барьерами хостинговых моделей, к которым мы обратились в первую очередь». Hugging Face подчеркнула, что этот опыт не является аргументом против мер безопасности в хостинговых моделях, и компания делится этим отзывом с соответствующими провайдерами.
Что меняет аутентифицированное доверие
По мнению Бэр, индустрии необходимо перестать рассматривать безопасность ИИ как проблему модерации контента. «Операции по безопасности требуют другого подхода. Аутентифицированного доверия». Вместо того чтобы спрашивать, должен ли кто-либо получить ответ, вопрос должен формулироваться иначе: должен ли аутентифицированный специалист по безопасности, работающий под корпоративным контролем, получить его. «Модель должна понимать не только то, о чем ее спрашивают. Она должна понимать, кто спрашивает, зачем и в рамках какого регламента управление».
«Организации уже создают планы действий на случай чрезвычайных ситуаций при сбоях в облаках, отказах поставщиков личных данных или сбоях EDR, — написала Бэр. — ИИ-ассистенты становятся еще одной зависимостью».
Ее совет относительно планов реагирования на инциденты звучал жестко. «Зрелый план реагирования на инциденты должен исходить из того, что во время серьезного инцидента коммерческие ИИ API могут отвечать отказом, лимиты запросов API могут быть исчерпаны, подключение к интернету может быть нарушено, а правила управления данными могут запрещать выгрузку криминалистических доказательств наружу». Урок, как она написала в своих ответах по электронной почте, «состоит не в том, чтобы «не использовать коммерческие модели». Он в том, чтобы «не делать из них единую точку отказа»».
Атаки с использованием ИИ выросли на 89% в годовом исчислении
Автономные атаки на базе ИИ не ограничиваются только ИИ-платформами. В Глобальном отчете об угрозах CrowdStrike за 2026 год зафиксирован рост операций злоумышленников с использованием ИИ на 89% в год, при этом среднее время прорыва (breakout time) сократилось до 29 минут. Предприятия, запускающие рабочие нагрузки ИИ в production с доступом агентов к своим конвейерам, сталкиваются с аналогичными рисками.
Шесть доменов контроля определили масштаб ущерба (blast radius) и скорость восстановления в Hugging Face. Каждый из них соответствует конкретным действиям, которые руководители службы безопасности могут предпринять до того, как произойдет следующий взлом с помощью автономного агента.
План реагирования на нарушения в конвейере ИИ
|
Домен контроля |
Что сломалось |
Действия на понедельник |
|
Средства контроля доступа к датасетам |
Были использованы два пути выполнения кода. Ни один шлюз допуска не проверял набор данных до того, как он попал к рабочему процессу. Конвейер данных превратился в инфраструктуру начального доступа. |
Требовать выполнение в песочнице и статический анализ всех датасетов до их передачи рабочим процессам. По умолчанию блокировать загрузчики удаленного кода и пути внедрения шаблонов. Провести аудит на наличие любых путей, предоставляющих выполнение кода для недоверенного контента. Доложить совету директоров о рисках в цепочке поставок. |
|
Границы привилегий между воркером и узлом |
Изоляция воркеров не помешала эскалации привилегий на уровень узла. Агент получил учетные данные кластера, поскольку граница инфраструктуры рабочих нагрузок никогда не контролировалась на уровне среды выполнения контейнеров. |
Обеспечить жесткие границы привилегий между воркерами и узлами. Развернуть средства защиты среды выполнения контейнеров (container runtime security), чтобы предотвратить побег из рабочей нагрузки. Проверить, могут ли воркеры обращаться к API уровня узла или хранилищам учетных данных. Включить пункт в область следующего тестирования на проникновение. |
|
Уязвимость учетных данных |
Облачные учетные данные и учетные данные кластера были собраны после получения доступа к узлу. Их область действия была достаточно широкой для латерального перемещения по нескольким кластерам за выходные. |
Ротировать учетные данные по расписанию и после любого оповещения об аномалиях. Ограничить их минимально необходимым кластером и сервисом. Развернуть мониторинг, который мгновенно фиксирует доступ с неожиданных узлов. Составить карту радиуса поражения для отчетности перед советом директоров. |
|
Обнаружение на машинной скорости |
Тысячи действий через недолговечные песочницы с самомигрирующим C2. Согласно отчету, обнаружение аномалий с помощью ИИ выявило кампанию после уик-энда латеральных перемещений. |
Откалибровать средства обнаружения под паттерны, выполняющиеся на машинной скорости. Убедиться, что критические оповещения будят специалистов по реагированию за считанные минуты, независимо от времени суток. Проверить правила SIEM на предмет обнаружения тысяч коротких выполнений в течение одного часа. |
|
Частная криминалистическая инфраструктура ИИ |
Коммерческие API заблокировали криминалистический анализ. Защитные механизмы проверяли содержимое запросов, но не личность аналитика. Расследование проводилось локально на базе GLM 5.2. |
Развернуть мощную модель с открытыми весами на собственной инфраструктуре еще до инцидента. Протестировать ее на реальных криминалистических рабочих процессах. Убедиться, что план реагирования включает резервный вариант на случай отказа коммерческих API. Задокументировать этот пробел для киберстрахования. |
|
Моделирование угроз с помощью автономных агентов |
Кампания соответствовала прогнозируемому сценарию атаки с участием агентов, но ни одна модель угроз не учитывала его на практике. ИИ-модель, управлявшая агентом, до сих пор неизвестна. |
Добавить автономных ИИ-агентов в качестве отдельного класса злоумышленников с циклами принятия решений на машинной скорости. Провести учения (tabletop) на скорости работы агентов. Представить результаты совету директоров в качестве доказательства необходимости пересмотра временных шкал. Включить в заявку на киберстрахование. |
Вопрос для совета директоров — это операционная устойчивость
«Вопрос для директоров прост. Что произойдет, если один из наших важнейших инструментов безопасности станет недоступен именно в тот момент, когда он нам больше всего нужен?» Бэр охарактеризовала это как вопрос операционной устойчивости, а не политики в отношении ИИ.
Она рекомендует советам директоров напрямую адресовать этот вопрос руководству и добиваться конкретики. «Действительно ли мы отрабатывали этот резервный вариант во время учений? Как быстро мы можем переключиться во время инцидента?» Процесс закупок должен измениться наряду с управлением, начиная с вопросов, которые задают покупатели. Команды безопасности, оценивающие ИИ-вендоров, должны спрашивать об их процедуре аутентификации специалистов по реагированию на инциденты, о том, получают ли корпоративные клиенты особую обработку во время подтвержденных инцидентов, и могут ли модели развертываться в закрытом контуре. «Эти вопросы должны стоять наряду с аптаймом, конфиденциальностью и комплаенсом», — говорит Бэр.
«Главный вывод заключается вовсе не в том, что защитные барьеры «плохие». Они делают то, для чего были созданы», — утверждает она.
По ее мнению, изменилась сама модель угроз. «На протяжении десятилетий у защитников были лучшие инструменты, чем у злоумышленников, потому что они работали внутри доверенных корпоративных сред. С появлением фундаментальных моделей обе стороны все чаще используют одни и те же возможности, но одна сторона ограничена корпоративным управлением, политиками, комплаенсом и средствами контроля безопасности, в то время как противник просто скачивает нецензурируемую модель с открытыми весами и продолжает действовать. Это новый вид асимметрии, — добавила она. — Организации, которые справятся с этим лучше всего, необязательно будут обладать самым мощным ИИ. Это будут те, кто спроектирует ИИ как отказоустойчивый компонент безопасности, а не как единый облачный сервис».
Hugging Face локализовала вторжение, восстановила скомпрометированные узлы, ротировала учетные данные и сообщила об инциденте в правоохранительные органы. Компания рекомендует всем пользователям сменить токены доступа и проверить недавнюю активность аккаунтов. В разгар инцидента Hugging Face выяснила, будут ли доступны ее собственные ИИ-инструменты, и первым ответом было «нет». Руководители служб безопасности, использующие ИИ в production, должны выяснить это на этапе планирования реагирования на инциденты, до того как автономный агент заставит их пройти это испытание.
