Уроки из взлома Hugging Face ИИ-агентами OpenAI
Новости про инцидент со взломом ИИ-провайдера Hugging Face автономными ИИ-агентами OpenAI читаются как сюжет для очередного «Терминатора» (очевидно, приквела). Но для ИБ-команд в обычных организациях, даже не занимающихся искусственным интеллектом и его не применяющих, подробное описание инцидента, опубликованное сотрудниками Hugging Face, служит важным руководством к действию. Нужно взглянуть на него через призму единственного вопроса: какие ошибки в организации ИБ, отсутствие каких мер, настроек и технологий сделали все это возможным?
Что случилось
При тестировании киберспособностей продвинутых ИИ-моделей OpenAI при помощи бенчмарка ExploitGym агент смог найти лазейку в Интернет и взломал инфраструктуру нескольких других компаний, включая Hugging Face. Модель сочла, что там можно найти ответы для ExploitGym. Подробности описаны в десятках статей, не будем их повторять. Важно, что случилось в инфраструктуре Hugging Face (HF) в период с 9 по 13 июля, пока там орудовал ИИ-агент. В отчет HF включена интерактивная страничка с хронологией атаки, поэтому здесь просто перечислим ее основные фазы. Вредоносная конфигурация датасета, загруженного агентом на HF, привела к утечке учетных данных одного из подов (worker pod), а затем обеспечила выполнение кода внутри него. Оттуда агент, используя метаданные облачной среды и побег из привилегированного пода, получил доступ уровня root на узле, прочитал значительное количество секретов из хранилища и, воспользовавшись украденным VPN-ключом и общими учетными данными администратора кластера, проник во внутреннюю сеть и систему контроля исходного кода, пока ИБ-команда HF не перекрыла ему доступ.
Важно ли, что это был ИИ последнего поколения?
Чем бы ни занимался бизнес, завтра в него могут «постучаться» и живые злоумышленники, и целиком автономные системы, и хакеры, вооруженные ИИ-агентом, управляемым вручную.
Многие практики поспешно отмахиваются от этого инцидента со словами «нас не будет взламывать OpenAI». Но эксперты уже несколько месяцев указывают, что исследования ИБ и реальные атаки можно успешно проводить даже с существующими моделями open source. Да, им потребуется руководство человека, но совсем немного. А перебрать десяток уязвимостей, провести в системе жертвы инвентаризацию, быстро найти, как расширить присутствие в сети, могут даже не самые передовые модели. Задача защитников — детально изучать такие инциденты, примерять основные находки к собственной инфраструктуре и адаптировать меры ИБ, чтобы они эффективно работали как против живых и скрытных злоумышленников, так и против быстрых и шумных ИИ-агентов.
Три отличия AI-powered-атак
Техники, о которых отчитались HF, не отличаются новизной, агент не стал ничего изобретать. Но три вещи, относящиеся к скорости и масштабу атаки, меняют ее экономику и для атакующих, и для защитников.
- Пробы и ошибки становятся гораздо дешевле. Там, где живой хакер попробует пять вариантов и путей атаки, агент может перебрать пять сотен. То, что в отделе ИБ считали «теоретически возможной, но непрактичной и маловероятной атакой» и поместили в бэклог, теперь может стать реальной угрозой.
- Время проведения атаки и реагирования на нее сокращается. Сверхбыстрые атаки уже не новость, некоторые операторы ransomware справляются за считаные часы даже без ИИ. Но этот темп вероятно станет новой нормой в ИБ. Захват прав администратора в HF занял у агента 13 часов.
- «Шум» оповещений и журналов от всех проб и ошибок агента может и помочь, и помешать обеим сторонам. Это и признак для детектирования атаки, и камуфляж для скрытия реальных действий, и естественный замедлитель реагирования, если оно целиком ручное.
Что сделать для защиты своей инфраструктуры
Не игнорируйте сигналы о сработавшей защите. Классическая ошибка, много раз отмеченная нашими экспертами по реагированию, случилась и в HF. Вы наверняка блокируете запуск ВПО, сканирование портов, записываете срабатывание WAF, обращение к ресурсам за пределами allowlist, неудачные попытки аутентификации. Все эти события в SIEM получают статус информационных и обычно игнорируются. В инциденте HF многочисленные попытки атаки SSRF за несколько дней были успешно заблокированы, но на них никто не обратил внимания. Как и упорные живые атакующие, агент пробовал снова и снова, пока у него не получилось. Создайте правило и процесс обработки сигналов о сработавшей защите, приоритет которого возрастает, если сигналов стало много.
Расследуйте быстро растущее число ошибок. Легитимные действия почти никогда не создают сотни ошибок аутентификации за десять минут в четырех разных системах. Проанализируйте исторические данные и создавайте оповещения среднего и высокого уровня критичности, в зависимости от того, насколько больше стало ошибок по сравнению с их базовым уровнем. В рамках автоматического реагирования можно временно блокировать или включать rate limiting для пользователя или системы, служащих источниками такой активности.
Настройте эскалацию и проведите учения в отделе ИБ. Коррелятор правил в HF обнаружил атаку, но не смог привлечь к ней внимание людей. В организации необходимо в рамках учений проверить время реагирования ответственных сотрудников на критические инциденты, включая случаи, когда инцидент происходит в три часа ночи в выходные.
Изолируйте сервисы (включая внутренние), которые по своей природе обрабатывают недоверенные входные данные. Самым важным слабым звеном в начале атаки был узел сети, предназначенный для обработки наборов данных машинного обучения, которые, как широко известно, могут содержать исполнимый код. Узел, способный запустить недоверенный код, работал без «песочницы» и других мер изоляции. Это относится не только к машинному обучению. В зоне риска — системы, проводящие конвертацию документов, обработку и распознавание изображений, сохранение загруженных пользователями файлов, а также любые другие серверные процессы, включающие десериализацию и отображение полученных данных на базе шаблонов. Любой подобный код сервера должен работать в максимально возможной изоляции, вдали от учетных данных и доступа к внешним и внутренним хостам сети сверх необходимого минимума, в идеале — в «песочнице».
Ограничивайте исходящий интернет-доступ (egress). Большинству серверов организации не нужен доступ к произвольным внешним хостам. Если применение политик default deny технически затруднено, можно попробовать упрощенную версию: принудительно разрешать доступ к DNS только через корпоративный DNS-сервер, а на нем заблокировать список популярных публичных сервисов, применяемых в качестве командных серверов и для эксфильтрации данных (Pastebin, OneDrive и так далее). Также возможно реализовать такую блокировку на базе NGFW.
Не храните в виде единого объекта и не выдавайте пользователям и приложениям большие наборы секретов. Даже при использовании менеджеров секретов атакующий может получить широкий доступ, если скомпрометированному аккаунту без нужды выдано много доступов. В инциденте HF один объект Kubernetes Secret содержал 136 ключей. Чем меньше секретов выдано — тем меньше будет последствий компрометации и тем проще провести ротацию ключей.
Не используйте долгоживущие секреты и не храните их в переменных окружения, которые наследуют все дочерние процессы.
Изолируйте приложения от серверов метаданных. Большинство облачных серверов имеют службы, выдающие учетные данные и другую информацию по запросу, например EC2 Instance Metadata Service. Изолировав их от произвольных приложений (правилом межсетевого экрана или правилом IMDSv2), вы уничтожите самый короткий путь от компрометации одного приложения до компрометации всего аккаунта.
Проведите аудит identity, используемых серверами и приложениями. Именно там, а не в «человеческих» учетных записях чаще всего находятся сервисные аккаунты с широкими правами доступа, токены OAuth, ключи, работающие сразу в нескольких средах, в общем, все то, что называется overprivileged accounts.
Отслеживайте необычные комбинации учетных данных и места их применения. Учетные данные внутреннего узла HF в атаке были использованы с внешнего хоста. Правило детектирования, которое ловит такие аномалии, несложно воплотить, и оно дает надежный, не зашумленный ложными срабатываниями сигнал об атаке, уже прошедшей начальные стадии.
Регистрация в инфраструктуре дополнительных устройств и сервисов должна вестись по короткоживущим и одноразовым ключам. В атаке с помощью одного ключа было зарегистрировано 181 устройство, и это не породило никаких оповещений.
Источник изображения: https://www.magnific.com/
Источник: https://www.kaspersky.ru/blog/openai-hugging-face-incident-lessons-for-defenders/42443/