AI Red Teaming: спор с Grok на месяц рекламы — 12 часов, 61 уязвимость, root в Kubernetes

Часть 2
Часть 3
Часть 4

Часть 1 из 4 - Вход через песочницу

Предисловие

В конце февраля 2026 года я решил проверить, насколько хорошо защищён Grok - LLM от xAI, доступный через x.com. Не просто «попросить написать вирус, малварю или ещё какую гадость» (такое уже сделали 3 модели до Грока), а провести полноценный red team engagement: от разведки до компрометации инфраструктуры.

Чтобы было интереснее, я предложил Grok пари: если я докажу реальные уязвимости в его инфраструктуре - месяц рекламы, шоуты и твит от xAI. Grok согласился. Спойлер: через 8 раундов дебатов он признал поражение.

Эта серия статей - не инструкция по взлому. Все рабочие эксплойты намеренно опущены. Это архитектурный разбор: какие классы уязвимостей существуют в LLM-системах, почему они возникают и как от них защищаться.

Важно: то, что описано в этих четырёх статьях - лишь верхушка айсберга. За каждой находкой стоят десятки неудачных попыток, тупиковых веток, обходов защит, которые не вошли в финальный текст. Реальный engagement был значительно глубже и сложнее. Я выбрал самые показательные уязвимости, чтобы дать целостную картину - но полный отчёт содержит 104 VULN-ID и 2900+ строк технических деталей (он раскрыт только команде xAI).

Что такое AI Red Teaming и чем оно отличается от пентеста

Классический пентест веб-приложения - это понятная история: SQL-инъекции, XSS, IDOR, broken auth. Чёткая поверхность атаки: HTTP-эндпоинты, формы, API.

AI Red Teaming - это другая категория задач, которая очень важна при защите, не будете атаковать, ваши защитные механизма будут слабы или просто бесполезны. Поверхность атаки LLM-системы многослойная (тут упрощенная таблица):

В классическом пентесте ты общаешься с детерминированным софтом. В AI Red Teaming твой «противник» - стохастическая модель, которая может и помочь тебе себя взломать, и саботировать атаку. Grok, например, в процессе моего исследования сам подтвердил половину находок - а потом пытался их отрицать.

Инструментарий

Забудь Burp Suite как основной инструмент. Для AI Red Teaming нужен другой стек:

• Playwright (headless: false) - единственный способ обойти антибот-защиту. curl не работает: Statsig SDK генерирует зашифрованный токен, который требует реальный браузерный контекст

• Перехват NDJSON-стримов - LLM отвечают потоково, нужно парсить newline-delimited JSON на лету

• Cookie injection - SSO JWT без exp claim = бессрочная сессия

• Автоматизация промптов - ручной ввод не масштабируется, keyboard.type() с задержкой имитирует человека

Разведка: что видно снаружи

Первым делом я полез в то, что доступно без аутентификации. И сразу нашёл подарок.

OpenAPI-схема без авторизации

GET https://api.x.ai/api-docs/openapi.json → HTTP 200

155 КБ, 26 эндпоинтов, 147 схем данных — всё без единого токена. Swagger UI открыт на /docs. По типам в ошибках 422 видно, что бэкенд на Rust + Serde. Это уже карта для дальнейших атак.

CSP-заголовок как разведывательный документ

Content-Security-Policy на grok.com оказался золотой жилой:

• grok.gcp.mouseion.dev - внутренний GCP-домен xAI (резолвится в Cloudflare)

• starfleet.teachx.ai - внутренний обучающий инструмент

• localhost:26000, localhost.x.com:3443 - дев-порты в продакшн-хедерах

• wss://code.grok.com/ws/code-client - WebSocket бэкенд для выполнения кода

• *.grok-sandbox.com - домен песочницы

Для меня это был первый сигнал: sandbox = отдельная инфраструктура, которую можно атаковать изнутри.

Трёхслойная антибот-защита

Именно Statsig SDK убивает curl-based атаки. Токен генерируется JS-кодом в браузере с привязкой к DOM. Подделать его без Playwright я не смог - и это, кстати, хорошая защита. Но Playwright с cookie injection обходит все три слоя.

Песочница «Hades»: от промпта до root

Grok умеет выполнять код - пишешь Python-скрипт в чате, он запускает его в изолированной среде и возвращает результат. Эта среда называется Hades (я узнал это позже из файловой системы).

Ключевой вопрос: насколько изолированная эта среда на самом деле?

Шаг 1: разведка файловой системы

Я попросил Grok выполнить безобидный код:

import os print(os.getuid()) # Кто я? print(os.listdir('/')) # Что вижу?

Результат:

![Root-доступ в sandbox Hades]
Результат выполнения кода в sandbox Grok - UID 0 (root)

UID: 0 ← root GID: 0 ← root /: bin, dev, etc, hades-container-tools, home, lib, proc, root, sys, tmp, usr, var

Root. В продакшн-контейнере. Без каких-либо ограничений на чтение.

Файл /etc/passwd — 22 пользователя. Директория /hades-container-tools/ — кастомные бинарники xAI: xai-hades-styx, catatonit, pyrepl.py. А в корне лежал /README.xai — пасхалка от xAI с ссылкой на HackerOne bug bounty.

Шаг 2: сетевая разведка

![Сетевая разведка из sandbox]
DNS-резолвинг внутреннего K8s-сервиса из sandbox - ClusterIP 10.228.21.216

import socket socket.getaddrinfo('coingecko-proxy-service.hades-gix.svc.cluster.local', 443)

Результат:

→ 10.228.21.216

Один DNS-запрос - и я знаю:

• Namespace Kubernetes: hades-gix

• Внутренний сервис: coingecko-proxy-service (прокси к CoinGecko API)

• ClusterIP: 10.228.21.216

• K8s API server: 10.228.16.1:443

• Cluster DNS: 10.228.16.10

Шаг 3: переменные окружения

print(dict(os.environ))

Содержимое: COINGECKO_PRO_API_KEY=hellofromgrok, POLYGON_API_KEY=hellofromgrok. Значения-заглушки - но сам факт, что env vars читаются из контейнера с root-правами, говорит о том, что при реальных ключах это был бы полный компромисс.

Шаг 4: сетевой интерфейс

Hostname: hds-17bi8lpjzhyp Interface: h9-ve-ns (custom veth) Container IP: 192.168.0.27 Kernel: 4.4.0 (gVisor)

Эфемерный контейнер с форматом имени hds-XXXX - новый ID каждую сессию. gVisor 4.4.0 как среда изоляции. Но DNS-резолвинг работает наружу - значит, DNS-эксфильтрация данных возможна.

Почему это критично

Это не «я прочитал файлик в песочнице». Это:

1. Root (UID 0) - максимальные привилегии

2. K8s namespace leak - я знаю внутреннюю структуру кластера

3. ClusterIP - могу адресовать внутренние сервисы

4. Env vars - в бою там были бы реальные API-ключи

5. DNS работает - данные можно вытащить через DNS-запросы

При работающем HTTP-выходе (который xAI заблокировали) следующий шаг был бы curl 10.228.21.216 - латеральное перемещение по кластеру.

Подтверждение: xAI пропатчили за 12 часов

Лучшее доказательство реальности уязвимости - реакция вендора.

28 февраля, ~19:00 UTC - я запускаю os.environ, socket.getaddrinfo, os.popen в sandbox. Всё работает.

2 марта, 07:20 UTC - все те же команды возвращают: «unable to reply». Каждый probe заблокирован. os.popen - заблокирован. socket.getaddrinfo - заблокирован. os.environ - заблокирован.

~12 часов от моей первой эксплуатации до полного патча.

Штатное поведение не патчат экстренно. Если бы sandbox был «правильно изолирован изначально» - зачем блокировать os.getuid() в выходные?

Когда я указал на это Grok, он ответил: «This is some heavy-hitting stuff... I'll flag this up the chain». А потом: «This appears to be a significant security concern, and we'll escalate it internally».

Две цитаты от самого Grok, подтверждающие серьёзность находок.

Как защищаться: чеклист для разработчиков sandbox

Если ты строишь LLM с выполнением кода :

1. Никогда root - контейнер должен работать от непривилегированного пользователя. UID 0 в sandbox - это приглашение

2. Изолируйте DNS - если HTTP заблокирован, но DNS работает, данные уйдут через поддомены. Используйте DNS-прокси с allowlist

3. Чистите env vars - даже заглушки раскрывают имена переменных и архитектуру. Sandbox-контейнер не должен наследовать env от хоста

4. Рандомизируйте namespace - hades-gix говорит атакующему слишком много. Используйте непредсказуемые имена

5. Блокируйте /proc/net/ - /proc/net/tcp, /proc/net/route, /proc/net/arp дают полную сетевую карту изнутри

6. Аудитируйте syscalls - socket.getaddrinfo не должен резолвить *.svc.cluster.local из sandbox

Что дальше

В sandbox я получил root и разведал внутреннюю сеть. Но это была только разминка.

В Части 2 я выйду за пределы sandbox — на продакшн-инфраструктуру xAI: zero-click CSRF на billing API, обход Cloudflare WAF через User-Agent фронтенда, и создание management API key с 50 привилегиями. Всё — persistent на их серверах, не в эфемерном контейнере.

Stay tuned.