Контроль над инфраструктурой не всегда начинается с прямого взлома. Иногда достаточно того, что система доверяет пользователю больше, чем должна. Дальше в дело вступают ошибки изоляции, прав и конфигурации.
В статье — кейс одного внутреннего пентеста от ITG Security, который начался с, казалось бы, обычной аутентификации на корпоративном ресурсе. Но привел к контролю над инфраструктурой. Никаких сложных цепочек — всего лишь аккаунт, у которого забыли проверить принадлежность к компании.
С чего все началось
Изучая переданный заказчиком скоуп, наша команда обратила внимание на JupyterHub. Аутентификация в этом ресурсе была настроена через любой GitHub-аккаунт, без проверки того, связан ли он с компанией. Уже на этом этапе стало понятно, что точка входа выглядит слишком открытой для корпоративного сервиса.
После успешного входа JupyterHub автоматически развернула персональный сервер. На первый взгляд все выглядело безопасно, ведь доступ должен был быть строго ограничен рамками учетной записи, но в действительности все оказалось иначе. Из-за ошибок в настройке прав и механизмов изоляции нам удалось получить доступ к notebooks других пользователе. Там хранились логины и пароли к различным системам, базам данных и другая конфиденциальная информация.
Уже этого было достаточно, но это только начало истории. Следующий шаг привел нас к Kubernetes, и то, что произошло дальше, полностью изменило масштаб происходящего.
Компрометация Kubernetes кластера
Изучив содержимое JupyterHub и собрав найденные артефакты, команда обнаружила функциональность, которая позволяла получить доступ к терминалу сервера, автоматически созданного системой. Доступ открывался от имени стандартного пользователя JupyterHub — jovyan, у которого по умолчанию нет повышенных привилегий.
Дальнейший анализ содержимого машины, в частности директории /opt, привел к еще более важной находке — там оказался токен spark. Обычно Spark используется для запуска и управления задачами обработки данных в Kubernetes, но в данном случае этот токен фактически открывал возможность управлять контейнерами и ресурсами кластера.
Так обычный инструмент для работы с данными превратился в точку входа к управлению инфраструктурой.
Права и разрешения
Следующим шагом мы решили проверить, валиден ли найденный токен и какие возможности он дает внутри кластера. Для этого, используя инструмент kubectl, были проверены права учетной записи, в результате чего выявлено наличие разрешений на выполнение всех типов операций — create, update, delete, patch, get, list, watch — в отношении всех типов ресурсов в пространстве имен spark.
По сути, такой набор прав открывал возможность создавать произвольные поды с любой конфигурацией безопасности, в том числе привилегированные контейнеры. А это уже означало переход от доступа к отдельному сервису к реальному воздействию на инфраструктуру кластера.
Создание привилегированного пода
Чтобы проверить этот сценарий на практике, командой ITG Security была подготовлена YAML-конфигурация, позволяющая запустить контейнер в привилегированном режиме и смонтировать внутрь него файловую систему узла кластера. Фактически это означало выход за пределы изоляции пода и получение доступа к ресурсам самого сервера.
В качестве целевой системы был выбран GitLab — как по запросу заказчика, так и потому, что для пентестеров такой доступ существенно расширял дальнейший вектор воздействия.
После запуска оставалось убедиться, что под успешно создан, и получить внутри него интерактивную оболочку.
Побег из контейнера
На следующем этапе мы воспользовались легитимным инструментом для входа в пространство имен уже запущенного процесса. Для этого использовался nsenter, который позволил подключиться к пространствам имен контейнера по идентификатору процесса PID. Команда выглядела так: nsenter -t PID -m -u -i -n -p /bin/bash.
Получив интерактивную оболочку от имени пользователя root, мы получили доступ к конфиденциальной информации, включая секреты GitLab. Затем через ruby rails console был создан пользователь GitLab с административными правами.
После этого удалось успешно авторизоваться в административной панели GitLab под созданной учетной записью. Дальше тем же способом были получены доступы и к другим системам заказчика, выгружены конфиденциальные данные, сертификаты и секреты Kubernetes, а также получен доступ к kube-system.
С точки зрения бизнеса такой сценарий уже не является локальным инцидентом, а становится полноценной компрометацией инфраструктуры. Речь идет об утечке чувствительных данных, доступе к критически важным системам, потере контроля над ИТ-средой, возможных финансовых потерях из-за простоев и штрафов, а также о репутационных рисках, если факт компрометации станет известен клиентам или партнерам.
Контейнеризация инструмент, а не гарантия безопасности
Контейнеризация и Kubernetes многими по-прежнему воспринимаются как «волшебная защита» инфраструктуры. Но практика показывает, что сами по себе контейнеры не делают систему безопасной. В ходе тестирования внутренней инфраструктуры компании мы убедились, что даже современный кластер можно полностью скомпрометировать, если базовые меры безопасности не внедрены или настроены формально.
Контейнеризация действительно упрощает деплой, масштабирование и изоляцию приложений, но не заменяет базовые меры информационной безопасности. Распространенное представление о том, что Kubernetes и Docker сами по себе ограничивают возможности атакующего, на практике оказывается мифом.
Реальными причинами компрометации обычно становятся вполне базовые вещи — ошибки в конфигурации сервисных аккаунтов, недостатки аутентификации, отсутствие мониторинга и слабый контроль привилегий.
Кластер под контролем
Этот сценарий наглядно показывает, как одна логическая ошибка в механизме аутентификации может привести к цепочке событий, которая уходит далеко за пределы первоначальной точки входа. В данном случае все началось с внешнего аккаунта без подтвержденной принадлежности к компании, а закончилось управлением инфраструктурой компании.
Чтобы не допускать подобных инцидентов, важно соблюдать несколько базовых принципов безопасности:
- контролировать права пользователей и сервисных аккаунтов;
- регулярно проверять настройки RBAC во всех namespace;
- обеспечивать изоляцию контейнеров;
- ограничивать возможность запуска привилегированных подов, особенно с доступом к файловой системе узлов.
Не менее важно ограничивать использование токенов и ключей, выдавать им только минимально необходимые права, вовремя обновлять их и отзывать устаревшие. И наконец, конфигурацию кластера необходимо регулярно проверять и аудировать, чтобы находить потенциальные уязвимости раньше, чем ими воспользуется злоумышленник.