AI Red Teaming: практический обход sandbox‑защиты, CSRF, обход WAF и повышение привилегий

Почему sandbox‑окружение не гарантирует полной защиты

Тестирование систем безопасности часто ограничивается изолированными sandbox‑средами, где любые изменения стираются после завершения сессии. Такой подход упрощает контроль над экспериментами, но в реальных условиях атакующие работают с постоянными сервисами, где даже небольшие уязвимости могут привести к масштабным компрометированиям. Перенос атак из sandbox в продакшн‑инфраструктуру раскрывает скрытые векторы, которые в изолированном окружении остаются незамеченными.

Zero‑click CSRF в gRPC‑интерфейсе биллинга

Одним из самых опасных открытий стал zero‑click CSRF (Cross‑Site Request Forgery) на все 11 методов биллингового API, реализованного через gRPC и принимающего payload в формате text/plain. В отличие от традиционного CSRF, где требуется пользовательское взаимодействие (например, клик по ссылке), здесь запросы могут быть инициированы без участия жертвы.

Механизм уязвимости

1. Отсутствие проверки Origin/Referer – gRPC‑сервер не проверял заголовки, указывающие источник запроса, полагаясь лишь на аутентификацию токенов, которые в данном случае передавались в заголовке Authorization.
2. Поддержка text/plain – сервер автоматически парсил тело запроса как простую строку, позволяя злоумышленнику сформировать корректный protobuf‑сообщение без необходимости использовать бинарный формат.
3. Отсутствие CSRF‑токенов – в gRPC‑методах не было встроенных одноразовых токенов, что открыло возможность повторного использования захваченных или предсказуемых токенов.

Эксплуатировать уязвимость можно, отправив HTTP‑POST запрос к gRPC‑эндпоинту с правильно сформированным protobuf‑сообщением в виде text/plain. Поскольку запрос может быть выполнен из любого контекста (например, из браузера жертвы или через сервер‑сайт скрипт), атакующий получает возможность изменять биллинг‑данные, создавать и удалять счета, а также изменять лимиты использования ресурсов.

Обход Cloudflare WAF через нестандартный заголовок

Следующим шагом стало исследование защиты, предоставляемой Cloudflare Web Application Firewall (WAF). Несмотря на репутацию WAF как “непробиваемого щита”, в данном случае удалось пройти его, используя единственный специально сконструированный HTTP‑заголовок.

Техника обхода

• Заголовок X-Forwarded-Proto – сервер, расположенный за Cloudflare, полагался на значение этого заголовка для определения протокола оригинального запроса. При передаче значения http вместо ожидаемого https правила WAF, настроенные на блокировку небезопасных запросов, не срабатывали.
• Манипуляция Host – изменяя Host на внутреннее имя сервиса, атакующий смог обойти проверку на соответствие доменному имени, которая обычно используется WAF для фильтрации запросов к известным публичным ресурсам.
• Отсутствие строгой валидации – Cloudflare не проверял согласованность между X-Forwarded-Proto и реальным протоколом соединения, что позволяло запросу пройти через все правила, основанные на протоколе.

Эта простая, но эффективная техника демонстрирует, насколько важна согласованность всех слоёв проверки запросов: от внешнего прокси до внутреннего приложения.

Создание management‑ключа с широкими привилегиями

Последний, но не менее критичный, вектор – генерация management‑ключа, обладающего 50 различными привилегиями в системе xAI. Ключ был получен без прямого доступа к административной консоли, используя комбинацию ранее обнаруженных уязвимостей.

Пошаговый процесс

1. Эксплуатация CSRF – через уязвимый gRPC‑метод CreateKey злоумышленник инициировал запрос на создание нового ключа, указав в payload список требуемых привилегий.
2. Обход WAF – запрос был отправлен через тот же заголовок X-Forwarded-Proto, который позволил запросу пройти защитный слой Cloudflare.
3. Подтверждение создания – полученный ответ содержал токен нового ключа, который сразу стал действовать в системе, предоставляя доступ к операциям управления пользователями, конфигурацией сервисов, мониторингом и даже возможности отключать другие ключи.

Среди 50 привилегий присутствовали такие критические возможности, как billing:modify, service:restart, admin:access_logs и system:shutdown. Наличие всех этих прав в одном токене фактически превращает его в “корневой” ключ, позволяющий полностью контролировать инфраструктуру xAI.

Практические выводы для защиты AI‑сервисов

• Внедрение строгих проверок Origin/Referer в gRPC‑эндпоинтах, даже если они используют text/plain. Дополнительный слой аутентификации в виде одноразовых CSRF‑токенов поможет предотвратить повторные запросы.
• Обязательная валидация всех HTTP‑заголовков на уровне WAF и самого приложения. Любой заголовок, влияющий на логику маршрутизации (например, X-Forwarded-Proto), должен сравниваться с реальными параметрами соединения.
• Минимизация привилегий при генерации API‑ключей. Принцип “least privilege” должен применяться к каждому новому токену, а возможности создания ключей с широким набором прав должны быть ограничены отдельными ролями и дополнительными проверками.
• Регулярный аудит gRPC‑интерфейсов на предмет поддержки небинарных форматов и наличия скрытых методов, которые могут быть использованы без строгой сертификации запросов.
• Мониторинг аномальных запросов к billing‑API, особенно запросов, приходящих из неожиданных источников или содержащих нестандартные заголовки. Интеграция с SIEM‑системой позволит быстро обнаружить попытки CSRF‑атаки.

Эти меры помогут укрепить защиту AI‑платформ, снизив риск эксплуатации уязвимостей, которые в изоляции sandbox‑окружения часто остаются незамеченными.