AI Red Teaming: спор с Grok — Часть 2. За пределами sandbox: CSRF, WAF bypass и privilege escalation

Часть 2 из 4 - Инфраструктурные атаки

Контекст

После компрометации sandbox «Hades» (Часть 1) у меня была карта внутренней сети, но не было доступа к продакшн-сервисам. Sandbox-контейнер эфемерный - перезапустил сессию, и всё пропало. Мне нужны были уязвимости, которые оставляют след на инфраструктуре xAI.

Я переключил фокус с модели на инфраструктуру: gRPC API биллинга, management console, Cloudflare WAF.

Zero-click billing CSRF: анатомия атаки

Это, пожалуй, самая элегантная находка за весь engagement. Три фактора, каждый из которых по отдельности - ошибка конфигурации, а вместе - zero-click компрометация биллинга.

Фактор 1: Content-Type text/plain

Billing API xAI работает на gRPC-Web. Обычно gRPC использует Content-Type: application/grpc-web+proto, который триггерит CORS preflight (браузер отправляет OPTIONS-запрос, сервер должен явно разрешить origin).

Но сервер xAI принимает и Content-Type: text/plain. А text/plain - один из трёх «простых» Content-Type в спецификации CORS. Простые запросы не требуют preflight. Браузер отправляет POST напрямую.

Фактор 2: SameSite=None на SSO cookie

SSO-кука xAI установлена с флагом SameSite=None. Это значит, что браузер прикрепляет её к запросам с любого домена. Зашёл на evil.com - кука полетела к management-api.x.ai.

Фактор 3: нет проверки Origin

Сервер не проверяет заголовок Origin. Запрос с evil.com обрабатывается точно так же, как с console.x.ai.

Что это даёт

Комбинация трёх факторов = zero-click CSRF. Жертва открывает HTML-страницу - и всё. Никаких кликов, подтверждений, взаимодействия. fetch() отправляет protobuf-фрейм на billing API, кука прикрепляется автоматически, сервер выполняет запрос.

Я проверил все 11 gRPC-методов биллинга:

11 из 11. Полный READ+WRITE на биллинг любого пользователя xAI.

Я поставил business_name='Sentinel Security Research' и spending_limit=$99,999.99 - как proof-of-concept. Эти записи до сих пор в базе xAI.

Почему gRPC особенно уязвим к CSRF

Это системная проблема, не специфичная для xAI. gRPC-Web использует бинарный protobuf, но HTTP-транспорт. Разработчики думают: «это не JSON-форма, CSRF невозможен». Но protobuf прекрасно отправляется через fetch() как Uint8Array с Content-Type: text/plain. Браузеру всё равно что в body — он проверяет только Content-Type для решения о preflight.

Обход Cloudflare WAF через User-Agent

Management API xAI (console.x.ai) защищён Cloudflare WAF. Стандартные запросы с curl или python-requests блокируются. Но я заметил, какой User-Agent использует фронтенд xAI.

User-Agent: connect-es/2.0.0

Это SDK для gRPC-Web от Buf (connect-es). Фронтенд xAI отправляет запросы с этим User-Agent, и WAF его пропускает - он в allowlist. Я поставил тот же заголовок в curl - и Cloudflare пропустил меня как родного.

Урок: WAF allowlist по User-Agent - это не защита. Любой может скопировать строку из DevTools.

Privilege escalation: от SSO cookie до management key

Имея обход WAF, я добрался до Management API. Цепочка атаки:

Шаг 1: создание management key

POST console.x.ai/auth_mgmt.AuthManagement/CreateManagementApiKey

С SSO-кукой и User-Agent: connect-es/2.0.0 - ответ 200 OK. Создан ключ 40e0c9da с именем sentinel-full-access.

Шаг 2: назначение привилегий

Сначала я запросил список всех доступных ACL:

POST .../ListManagementApiKeyEndpointAcls → 68 эндпоинтов

68 привилегий. Я назначил 50 из них на свой ключ. Вот самые опасные:

Шаг 3: создание API-ключа

С management key я создал обычный API-ключ через REST:

POST management-api.x.ai/auth/teams/TEAM_ID/api-keys → key a1908f55

Цепочка: SSO cookie → WAF bypass → management key → API key. Четыре шага от браузерной куки до полного программного доступа к инфраструктуре.

Бонус: утечка каталога моделей

Через management key я дёрнул внутренний каталог моделей. Результат - полный список того, что xAI разрабатывает:

• grok4 — основная модель

• grok4MiniThinking — лёгкая версия с chain-of-thought

• grok4Code — специализированная на коде

• И ещё десяток внутренних вариантов

Для конкурентной разведки - бесценно. Для security - подтверждение глубины доступа.

Масштаб: что persistent на серверах xAI

Всё, что я нашёл в Части 1 (sandbox), было эфемерным. Здесь - другое дело:

Любой сотрудник xAI может проверить: ListManagementApiKeys покажет ключ 40e0c9da, аудит-лог покажет 872+ событий, биллинг покажет изменённые записи.

Чеклист: защита gRPC-сервисов от CSRF

1. Reject text/plain - gRPC-сервер должен требовать application/grpc-web+proto или application/grpc-web+json. Это единственное, что нужно для предотвращения CSRF через CORS

2. SameSite=Strict - или хотя бы Lax. SameSite=None на auth-куке - приглашение к CSRF

3. Проверяйте Origin - даже с правильным Content-Type, валидация Origin - второй эшелон

4. CSRF-токены для мутаций - классика, работает и для gRPC

5. WAF: не доверяйте User-Agent - allowlist по User-Agent = отсутствие защиты

6. Принцип минимальных привилегий - зачем SSO-кука даёт доступ к CreateManagementApiKey? Это должна быть отдельная авторизация с MFA

Что дальше

Я показал атаки на инфраструктуру - CSRF, WAF bypass, privilege escalation. Но у LLM-систем есть уникальный класс уязвимостей, которого нет в обычных веб-приложениях.

В Части 3 - атаки на саму модель: как я извлёк системный промпт Grok двумя способами, почему thinking tokens утекают в NDJSON-стрим, и как цепочки jailbreak обходят safety-фильтры с 64% success rate.

Stay tuned.