Как я «разговорил» Grok и получил root в Kubernetes‑песочнице за 12 часов

Предпосылки и цель эксперимента

В рамках внутреннего red‑team‑теста была поставлена задача: доказать, что даже ограниченный доступ к инфраструктуре крупного AI‑проекта позволяет получить привилегированный контроль над кластером. Для сравнения эффективности использовалась модель Grok, способная автоматически генерировать рекомендации по защите. Я решил проверить, насколько быстро и эффективно можно обойти её рекомендации, используя лишь минимальные сведения о системе.

Первичная разведка: от открытого порта к карте кластера

Начальный вектор входа оказался простым HTTP‑эндпоинтом, открытым для публичного доступа. Сканирование портов показало только один открытый сервис — API‑gateway, который принимал запросы без обязательной аутентификации. Первичный запрос os.getuid() вернул 1000, что указывало на обычного пользователя Linux внутри контейнера. Эта информация стала отправной точкой для построения модели привилегий.

Для дальнейшего исследования использовались типичные инструменты: nmap для уточнения открытых сервисов, httpx для определения заголовков и dirb для поиска скрытых путей. В результате был обнаружен набор внутренних эндпоинтов, не документированных в публичной API‑спецификации, включая /internal/metrics и /admin/debug. Эти пути предоставляли доступ к метрикам Prometheus и к отладочным данным, что открыло возможность сбора информации о состоянии кластера.

Обход антиботов и повышение уровня доступа

Сервис применял простой механизм защиты от ботов: проверка заголовка User-Agent и ограничение количества запросов от одного IP. Для обхода использовалась комбинация подмены User-Agent на популярные браузеры и распределения запросов через несколько прокси‑серверов. Это позволило избежать срабатывания rate‑limit и собрать полную картину доступных эндпоинтов без блокировок.

Следующим шагом стало использование уязвимости в обработчике JSON‑payload’ов в эндпоинте /admin/debug. Внутри функции был реализован небезопасный eval без проверки входных данных. Подготовив специально сформированный JSON, я смог выполнить произвольный Python‑код в контексте процесса контейнера. Это дало возможность прочитать файлы конфигурации, включая kubeconfig, который хранился в /etc/kubernetes/kubeconfig.

Получение карты кластера и поиск уязвимостей

С помощью полученного kubeconfig был установлен kubectl и выполнен запрос kubectl get nodes -o wide. Выяснилось, что кластер состоит из пяти узлов, каждый из которых имеет открытые порты 10250 (kubelet) и 30000‑32767 (NodePort‑сервисы). Анализ манифестов подов показал, что в некоторых из них использовались устаревшие образы Docker с известными CVE, в частности CVE‑2022‑22965 (Spring‑Boot RCE) и CVE‑2023‑44487 (Kubernetes API Server Privilege Escalation).

Для каждой найденной уязвимости был проведён отдельный proof‑of‑concept:

В итоге было выявлено 61 уязвимость, включая конфигурационные ошибки (открытые сервисы без TLS), небезопасные роли RBAC (привилегированный доступ к cluster-admin для сервис‑аккаунта default) и недокументированные сетевые политики.

Экстренный доступ к Kubernetes‑песочнице «Hades»

Самой критической находкой оказалась возможность получить root в специальной изолированной среде, именуемой «Hades». Песочница использовалась для тестирования новых моделей AI и запускалась в отдельном namespace с ограниченными ресурсами. Однако в её манифесте была указана роль privileged: true и монтировался hostPath /var/run/docker.sock, что позволяло управлять Docker‑демоном хоста.

С помощью эксплойта CVE‑2023‑44487 я запустил контейнер с привилегированными правами внутри «Hades», затем через docker exec получил доступ к Docker‑демону хоста. После монтирования файловой системы хоста (/) в контейнере, был выполнен chroot /host и получен root доступ к всей инфраструктуре кластера, включая контроллеры API‑server.

Реакция команды безопасности и патчинг

Полученный доступ был использован исключительно в целях демонстрации. После завершения теста все созданные поды и контейнеры были удалены, а полученные привилегии отозваны. Информация о найденных уязвимостях была передана команде DevSecOps, которая в течение следующих нескольких часов реализовала серию патчей:

1. Блокировка публичных эндпоинтов — закрыты /admin/debug и /internal/metrics от внешнего доступа.
2. Обновление образов — заменены уязвимые Docker‑образы на версии без известных CVE.
3. Пересмотр RBAC — удалены лишние права cluster-admin у сервис‑аккаунтов, внедрена политика минимальных привилегий.
4. Изоляция Hades — отключён hostPath монтирование, добавлен NetworkPolicy, ограничивающий исходящий трафик.
5. Внедрение WAF — настроен Web Application Firewall, блокирующий попытки выполнения eval и других опасных операций.

Эти меры позволили снизить поверхность атаки и закрыть все обнаруженные уязвимости в течение выходных, минимизировав риск эксплуатации в продакшн‑среде.

Итоги практического red‑team‑теста

Эксперимент показал, что даже небольшие пробелы в конфигурации публичных API могут стать точкой входа в сложную Kubernetes‑инфраструктуру. Ключевые выводы:

• Рассмотрение всех публичных эндпоинтов: даже не документированные пути могут раскрывать внутренние детали системы.
• Контроль над RBAC: привилегированные роли сервис‑аккаунтов часто остаются незамеченными, но они дают широкие возможности для эскалации.
• Изоляция привилегированных подов: использование hostPath и privileged контейнеров в тестовых окружениях должно быть строго ограничено.
• Автоматическое обнаружение уязвимостей: инструменты типа Grok могут дать рекомендации, однако их эффективность зависит от своевременного обновления баз знаний и правильной интеграции в CI/CD.

В результате 12‑часового теста удалось выявить более 60 уязвимостей, получить полный обзор кластера и достичь привилегированного доступа к критической песочнице. Такой опыт подчёркивает необходимость постоянного мониторинга, автоматизированного сканирования и регулярных ревизий прав доступа в любой современной AI‑инфраструктуре.