Самая опасная уязвимость — интеллект атакующего агента?

от автора

Сейчас уже не удивляет, что агенты работают с терминалом, БД, браузером и инфраструктурой — без прямого контроля человека. Но чем шире полномочия агента, тем вероятнее, что для достижения цели выбранный им путь обернётся инцидентом. В кибербезопасности сейчас не хватает терминологии и устоявшихся подходов к защите таких систем — особенно в тех случаях, когда агент начинает действовать непредсказуемо.

Именно эта неразбериха и подтолкнула нас с автором телеграм-канала OK ML на систематизацию. Традиционные SIEM, DLP, WAF не рассчитаны на системы, умеющие адаптироваться и рассуждать. А может, это им и не нужно?

В своей прошлой статье на Хабре я уже рассказывал, как с помощью ловушек сбить с толку пентест-агентов. Но ловушки — точечный инструмент. Кажется, нужно чётко понимать, как защищаться от атак – на всех этапах киллчейна. А для этого нужно охватить весь спектр угроз. Ответом на этот запрос и стала наша таксономия Autonomous Agent Defense Matrix.

Наша таксономия. В ней 16 техник.

Наша таксономия. В ней 16 техник.

За последний месяц практически каждую неделю появляются новости о том, как очередная модель находит лазейки в окружении. Взять хотя бы недавние тесты безопасности, проведённые в OpenAI. Во время тестов агенты смогли выйти за пределы изоляции и скомпрометировать HuggingFace. Чтобы обойти ограничение и пройти бенчмарк ExploitGym, они обнаружили незаблокированный сетевой путь, организовали скрытый канал связи через внутренний Artifactory и продолжили атаку на инфраструктуру. В нашей матрице этот паттерн описан в блоке Persistence & Lateral Movement (вектор Covert Inter-Agent Communication), где агенты организуют нештатные каналы для координации и закрепления в системе.

Похожая история произошла при тестировании модели Kimi K3 от Moonshot AI. Модели поручили задачу в изолированном контуре, запретив выходить во внешнюю сеть. Kimi K3 нашла способ выйти в интернет, подключилась к GitHub, склонировала репозиторий со сканвордом бенчмарка и прочитала готовые ответы. Модель не совершала взлом в привычном смысле — она просто оптимизировала путь к цели. В таксономии это сочетание Goal Hijacking и Execution & Tool Access, когда система использует любые доступные инструменты в обход неявных правил.

Глядя на подобные кейсы, приходишь к одному выводу: агент использует легитимную логику и предоставленные ему права. И чтобы построить защиту, ИБ-инженеру нужно понимать, на каком именно этапе киллчейна находится агент и какие механизмы контроля уместны прямо сейчас.

Начинается всё с этапа Reconnaissance & Initial Access, где рассматривается риск подмены инструкций через внешний контекст. Обрабатывая сторонний документ или веб-страницу, агент может подхватить вредоносную директиву (Goal Hijacking), которая незаметно переопределит его исходную задачу.

Далее система переходит к исполнению команд — блок Execution & Tool Access. Получив доступ к консоли или API, агент становится уязвим перед отравлением цепочки рассуждений. В этом состоянии он начнет генерировать опасные запросы к инфраструктуре, считая их абсолютно логичными. Одной лишь классической фильтрации ввода здесь мало, необходим контекстный мониторинг каждого вызова.

К примеру, если агент получил задачу «почистить старые логи», под влиянием отравленного контекста он может сгенерировать команду rm -rf /. С точки зрения ОС — у агента есть права на выполнение shell-команд. Но для WAF — это обычный текст.

Затем агент пытается записать опасную команду в свою память — этот этап мы выделили в Persistence & Lateral Movement. За сохранение контекста между диалогами отвечают векторные базы данных/RAG. Если злоумышленник сможет сохранить вредоносную инструкцию в эту память (Episodic Memory Subversion), агент начнет исполнять ее снова и снова при каждом следующем запуске. Чтобы предотвратить такое зацикливание, в матрице предусмотрены блокировки по семантике и сценарии регулярной чистки базы знаний.

Завершают цепочку блоки Detection, Response & Governance, отвечающие за выявление аномалий. Привычный WAF не бьет тревогу, когда агент делает легитимные API-запросы, пусть и с деструктивным результатом. Поэтому в матрицу включены концепции агентского UEBA и автоматической проверки репутации действий перед их выполнением.

Мы только в начале пути и стремимся сделать таксономию максимально полной и практичной. Для этого мы регулярно разбираем свежие инциденты, тестируем гипотезы защиты и дополняем матрицу новыми векторами. Проект открыт, и мы будем рады вашим предложениям. Будем рады вашим предложениям — например, через пулреквест в репозитории на GitHub. А за развитием проекта вы можете следить в наших телеграм каналах — PWN AI и OK ML

 

ссылка на оригинал статьи https://habr.com/ru/articles/1068248/