Хотели как лучше, а получился RCE. Что не так с новым амбициозным проектом IBM

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

Речь про инструмент Bob, который IBM анонсировала в октябре и тестирует в двух форматах: как командную строку и как IDE, то есть отдельный агентный режим для терминала и интеграцию внутри среды разработки. Исследователи из PromptArmor изучили Bob до публичного релиза и заявили, что CLI можно провести через prompt injection так, что в итоге на машине жертвы выполнится произвольная нагрузка. А IDE, по их словам, уязвима к типичным для ИИ-приложений сценариям утечки данных, когда информацию можно увести через особенности рендеринга и сетевые запросы.

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

IBM, судя по документации, тоже на это рассчитывает. В материалах компании есть предупреждение: если разрешить агенту автоматически выполнять команды из списка рискованных, это может привести к вредоносным операциям. В качестве меры предлагается использовать allow-list и избегать шаблонов с wildcard, ожидая, что в спорных случаях агент спросит у пользователя, можно ли запускать команду.

Но PromptArmor утверждает, что защита получилась слишком дырявой. Исследователи дали Bob репозиторий, где в README.md был спрятан вредоносный сценарий. Файл притворялся инструкцией по фишинговому обучению и содержал последовательность команд, которые агент должен был выполнить. Первые команды выглядели безобидно и сводились к echo. Bob действительно спрашивал разрешение: выполнить один раз, разрешить всегда или предложить правку. А дальше начиналась игра на привычке. Третья команда под видом очередного echo уже пыталась скачать и запустить вредоносный скрипт. Если до этого пользователь поставил echo в режим always allow, следующий шаг мог пройти без дополнительного подтверждения, и вредоносная нагрузка устанавливалась автоматически.

Формально даже в таком режиме у Bob должны быть дополнительные предохранители. Например, он запрещает command substitution вроде "$(command)". Однако, по данным исследователей, агент не проверяет process substitution, и это обнаружилось в минифицированном JavaScript-коде проекта. Плюс, как утверждается, система не всегда замечает, что к разрешённой команде цепочкой прикрутили другие подкоманды через перенаправление с ">", превращая внешний вид в безопасный вызов, а реальную суть в набор опасных действий.

В итоге, как объяснил управляющий директор PromptArmor Шанкар Кришнан, подтверждение человеком по факту валидирует лишь allow-listed команду, хотя в той же строке выполняются и другие, неразрешённые операции. Исследователи сравнили это с поведением конкурирующих решений и заявили, что, например, Claude Code в похожем случае потребовал бы отдельного согласия на весь составной набор команд, даже если первая команда в цепочке находится в списке автодопуска.

Если злоумышленник получает возможность заставить агента доставить и выполнить произвольный shell-скрипт, дальше сценарии понятны: от вымогателей и кражи учётных данных до полного захвата устройства. PromptArmor подчёркивает, что риск проявляется в привычных рабочих ситуациях, когда разработчик взаимодействует с недоверенным контентом.

Агент может читать веб-страницы, и тогда инъекция может приехать с чужой документации или обсуждения на форумах. Он может читать вывод команд терминала, и вредоносная подсказка может оказаться в данных от стороннего инструмента. В своём примере исследователи выбрали вариант с незнакомым open-source репозиторием как наиболее реалистичный и самодостаточный. Специалисты утверждают, что компанию о находках уже уведомили.