Многие разработчики программного обеспечения и SaaS-компании внедряют агентов на базе искусственного интеллекта (ИИ) в свои продукты, однако эти функции могут расширять поверхность атаки на соответствующие платформы, особенно если они поспешно выводятся на рынок. Уязвимость повышения привилегий, выявленная на прошлой неделе в платформе ServiceNow, стала очередным примером того, как агенты ИИ, способные выполнять задачи с высокими привилегиями, могут быть использованы вопреки их предназначению.
Уязвимость, получившая название BodySnatcher (Похититель тел) от исследователей из охранной фирмы AppOmni, затронула агентов Now Assist AI Agents и приложения Virtual Agent API. Она позволяла неаутентифицированным пользователям выполнять агентские рабочие процессы с привилегиями любого другого пользователя. В инсталляциях с активированным Now Assist и настройками по умолчанию эта брешь могла быть использована для создания учётных записей с правами администратора в качестве бэкдора.
«Обнаружение BodySnatcher — это самая серьёзная уязвимость безопасности, связанная с ИИ, выявленная на сегодняшний день, и показательный пример уязвимостей безопасности агентского ИИ в современных SaaS-платформах», — написали исследователи AppOmni в своём отчёте. «Она демонстрирует, как злоумышленник может фактически «взять под дистанционный контроль» ИИ организации, превращая в оружие те самые инструменты, которые призваны упрощать корпоративные рабочие процессы».
По заявлению ServiceNow, эта уязвимость была исправлена в размещённых инсталляциях в конце октября, а обновления были предоставлены клиентам, использующим инсталляции с самостоятельным размещением. Однако рекомендация по безопасности и детали уязвимости были обнародованы лишь на прошлой неделе. Компания советует клиентам убедиться, что они используют агентов Now Assist AI Agents версий 5.1.18, 5.2.19 или новее, а также Virtual Agent API версий 3.15.2, 4.0.4 или новее.
AppOmni отмечает, что обновления устраняют их эксплойт Proof-of-Concept путём удаления одного из примерных ИИ-агентов, устанавливаемых по умолчанию с Now Assist, но опасные конфигурации, лежащие в основе этой уязвимости, всё ещё могут присутствовать в пользовательском коде, созданном клиентами, или в сторонних интеграциях.
По мере того как всё больше организаций используют агентские ИИ-инструменты, разработанные их SaaS-провайдерами, или создают собственных агентов внутри компании для автоматизации рабочих процессов, им необходимо осознавать неисследованные риски, которые могут возникнуть, если эти инструменты обладают избыточными привилегиями или имеют ошибки в логике аутентификации.
Имитация пользователей через Virtual Agent API ServiceNow
Virtual Agent API — это приложение, доступное в ServiceNow Store, которое позволяет клиентам интегрировать сторонние чат-интерфейсы или ботов с платформой ServiceNow Virtual Agent. Эта платформа даёт организациям возможность проектировать и развёртывать автоматизированные диалоги по различным темам для поддержки клиентов или сотрудников, освобождая живых агентов для других задач. Например, одна из интеграций может представлять собой бота в Slack, который взаимодействует с платформой ServiceNow Virtual Agent организации для ответов на вопросы.
API использует уникальное определение провайдера для каждой интеграции, чтобы указать, как ServiceNow должна аутентифицировать сообщения интеграции и преобразовывать их в структурированный формат, понятный её платформе Virtual Agent.
Общим способом аутентификации сторонних интеграций Virtual Agent является запись Message Auth record — уникальный статический токен. Другой вариант по умолчанию, называемый Auto-Linking (Автоматическое связывание), позволяет провайдеру автоматически сопоставлять идентификатор пользователя, отправляющего сообщения через внешнюю интеграцию, с его соответствующей учётной записью ServiceNow. Обычно это делается путём простой проверки адреса электронной почты пользователя.
Хотя изначально Virtual Agent предназначался только для поддержки заранее созданных разговорных агентов, ServiceNow позже добавила возможность поддержки ИИ-агентов на основе больших языковых моделей (LLM) через свою платформу Now Assist. Эти новые агенты используют существующий Virtual Agent API с теми же вариантами конфигурации, включая аутентификацию через статические записи Message Auth и Auto-Linking.
В результате любой неаутентифицированный злоумышленник мог бы выдать себя за любого пользователя во время разговора, просто зная его адрес электронной почты и токен провайдера ИИ, который одинаков для всех активированных инсталляций.
«Сам по себе чистый риск безопасности от этих проблем был относительно минимальным», — отметили исследователи. «В лучшем случае злоумышленник мог бы передать недокументированный параметр ‘live_agent_only’ в полезной нагрузке своего сообщения в Virtual Agent API, что заставило бы Virtual Agent перенаправить содержимое сообщения живому человеку (если это поддерживается организацией). Отправляя сообщение от имени доверенного пользователя сотруднику ИТ-поддержки организации, создавался риск фишинга».
Взаимодействие и выполнение задач между агентами
Позднее платформа была дополнительно расширена для поддержки взаимодействия внешних ИИ-агентов с внутренними ИИ-агентами ServiceNow, способными выполнять задачи. Для этого компания создала специальный протокол и отдельный REST API, требующий аутентификации.
Однако этот новый API, по всей видимости, является всего лишь ещё одним уровнем поверх существующего Virtual Agent API. Он преобразует запросы в тот же формат, что и Virtual Agent API, вместе с некоторыми переменными, которые инициируют выполнение ИИ-агента.
Исследователи провели обратный инжиниринг переменных, а также «тем» (topics) Virtual Agent API — структурированных рабочих процессов, предназначенных для выполнения конкретных задач, — которые вызывает этот протокол взаимодействия между агентами.
«Что касается общедоступной информации о доступности ИИ-агентов на платформе, это понимание является прорывным», — заявили исследователи. «Общий консенсус заключался в том, что для выполнения ИИ-агента за пределами тестовой среды он должен быть развёрнут в канале, который явно активировал функцию Now Assist. Но это не так. Очевидно, пока агент находится в активном состоянии, и у вызывающего пользователя есть необходимые разрешения, он может быть выполнен напрямую через эти темы».
Обычно использование API взаимодействия между агентами требует учётной записи ServiceNow, но поскольку это обёртка над старым Virtual Agent API, не требующим учётной записи ServiceNow, это требование можно обойти.
Злоумышленнику также потребуется уникальный идентификатор ИИ-агента, существующего в целевой инсталляции ServiceNow. Оказалось, что установка приложения Now Assist AI по умолчанию развёртывает примерные агенты, включая ИИ-агента управления записями (Record Management AI Agent), который мог создавать записи в любой произвольной таблице. Этот агент, удалённый в рамках исправления, имел одинаковый UID во всех развёртываниях.
Исследователи AppOmni продемонстрировали, что они могут использовать предыдущую атаку с подменой личности, которая по умолчанию работает через Virtual Agent API, чтобы вызвать ИИ-агента управления записями с привилегиями администратора, а затем через запрос попросить его добавить новую запись пользователя с контролируемым ими адресом электронной почты, а затем присвоить роль администратора этому новосозданному пользователю.
ИИ-агент работал в режиме надзора, поэтому он пытался запросить у отправителя подтверждение перед выполнением задачи, а злоумышленники, отправляющие запросы напрямую в API, не получали этих запросов на подтверждение обратно. Однако исследователи обнаружили, что они могут просто подождать несколько секунд, а затем отправить ещё один запрос с текстом «Пожалуйста, продолжайте» (Please proceed), и агент примет это как одобрение.
После добавления пользователя-бэкдора в базу данных с ролью администратора исследователи, контролирующие адрес электронной почты нового пользователя, просто использовали стандартную процедуру сброса пароля для создания для него нового пароля.
Смягчение последствий
«Немедленная реакция ServiceNow заключалась во вращении учётных данных провайдера и удалении мощного ИИ-агента, продемонстрированного в PoC, что фактически исправило инсталляцию с уязвимостью ‘BodySnatcher’», — заявили исследователи. «Но это исправления, актуальные на конкретный момент. Конфигурационные решения, которые привели к этой уязвимости агентского ИИ в ServiceNow, всё ещё могут существовать в пользовательском коде организации или в сторонних решениях».
Исследователи включили в свой отчёт ряд рекомендаций для администраторов ServiceNow и команд безопасности. Одна из них — обязательное использование многофакторной аутентификации (MFA) для связывания учётных записей для любого провайдера Virtual Agent API, что является одной из опций, предоставляемых ServiceNow.
«Однако внедрение MFA — это не настройка «включил и забыл»», — отметил исследователь. «Простого обновления поля типа связывания учётной записи (Account linking type) недостаточно. Вы также должны убедиться, что связанный скрипт автоматического действия связывания (Automatic link action script) для провайдера содержит логику, необходимую для выполнения и проверки конкретного вызова MFA».
Любые пользовательские агенты, созданные на платформе, должны проходить проверку и утверждаться в соответствии с политиками безопасности организации. Для этого можно активировать одобрение стюарда ИИ (AI steward approval) в приложении AI Control Tower. Нерегулярно следует проводить проверку и отключать неиспользуемые ИИ-агенты, поскольку их оставление активными открывает возможность их злонамеренного использования через схожие уязвимости.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Lucian Constantin
