За годы работы по обеспечению безопасности сред на базе облачных технологий я заметил повторяющееся «слепое пятно». Мы одержимы «входными дверями», такими как открытые панели управления, неправильно настроенные RBAC или неустраненные уязвимости контейнеров. Мы укрепляем периметр, но часто игнорируем механизмы, работающие внутри.
Современные злоумышленники вышли за рамки простой тактики «вломился и украл». Им недостаточно просто запустить майнер криптовалюты на несколько часов; им нужна устойчивость. Им нужна точка опоры, которая переживет перезагрузку узла, перезапуск пода или даже обновление кластера.
Самым опасным и упускаемым из виду механизмом для обеспечения такой устойчивости является паттерн контроллера Kubernetes. Компрометируя или регистрируя вредоносный контроллер, злоумышленник обращает автоматизацию самого кластера против него, создавая самовосстанавливающийся бэкдор, который невероятно трудно обнаружить. Это высшая техника «жизни за счет земли» для облачной эпохи.
Использование цикла управления в качестве оружия
По своей сути Kubernetes — это механизм автоматизации. Он постоянно сравнивает желаемое состояние (YAML) с фактическим состоянием (запущенные поды) и устраняет расхождения. Эта логика содержится в контроллерах.
Вредоносный контроллер работает путем подписки на события кластера. Вместо развертывания приложения он отслеживает определенные триггеры, такие как создание нового пространства имен или развертывание определенного секрета, и автоматически внедряет вредоносный код.
Сценарий: «Теневой» инжектор сайдкаров
Мы видели, как это разворачивалось в реальных условиях в рамках Siloscape — сложной вредоносной кампании, обнаруженной Palo Alto Networks Unit 42. В отличие от обычных скриптов криптомайнинга, Siloscape интересовали не только вычислительные ресурсы; ему нужен был сам кластер. Он нацеливался на контейнеры Windows, выходил на базовый узел и использовал учетные данные узла для распространения через API-сервер.
Аналогичным образом, группировка TeamTNT, как задокументировано, использовала вредоносное ПО Hildegard для эксплуатации API kubelet с целью обеспечения устойчивости. Это не теоретические упражнения для аудитории. Это задокументированные кампании, в которых злоумышленники использовали плоскость управления, чтобы обратить Kubernetes против его владельцев.
Рассмотрим злоумышленника, который получает аналогичный ограниченный доступ на запись к API-серверу кластера. Этот доступ может быть получен через скомпрометированные учетные данные конвейера CI/CD или утечку kubeconfig разработчика, который имеет достаточно разрешений для создания MutatingWebhookConfigurations, но не полные права администратора кластера. Злоумышленнику не нужно напрямую развертывать рабочую нагрузку; ему нужно лишь указать API-серверу выполнить свою логику на рабочих нагрузках всех остальных.
Вместо запуска подозрительного пода с именем mining-rig он регистрирует MutatingAdmissionWebhook.
Как показано на Рисунке 1, этот вебхук действует как контроллер. Каждый раз, когда создается легитимный под (например, платежный сервис), API-сервер отправляет определение пода на утверждение вебхуку злоумышленника. Вебхук изменяет спецификацию пода, чтобы внедрить вредоносный сайдкар-контейнер, прежде чем он будет сохранен в etcd.
Скрытая опасность:
- Он невидим для kubectl get pods: Вредоносный сайдкар часто скрыт глубоко в спецификации пода, и если злоумышленник использует распространенное имя, такое как proxy-agent, он сливается с легитимным трафиком mesh.
- Он переживает очистку: Если вы удалите скомпрометированный под, контроллер Deployment создаст новый. Новый под снова вызовет вебхук, и бэкдор будет внедрен повторно. Устойчивость заложена в жизненный цикл самого кластера.
Соответствие угрозы: Этот метод соответствует Устойчивости (TA0003) в матрице MITRE ATT&CK для контейнеров. Он специально использует собственный цикл управления кластера для поддержания доступа, что делает его гораздо более устойчивым, чем традиционные бэкдоры на основе оболочки.
Охота на призраков в API
Чтобы поймать это, вам нужно смотреть дальше стандартных журналов. Вам необходимо проводить аудит конфигурации плоскости управления кластера.
1. Аудит MutatingWebhookConfigurations
Выполните эту команду, чтобы увидеть, кто перехватывает ваши создания подов:
kubectl get mutatingwebhookconfigurationsИщите вебхуки, указывающие на внешние URL-адреса или сервисы в неизвестных вам пространствах имен (например, kube-public или default). Если вы видите вебхук с именем compliance-check, указывающий на IP-адрес за пределами вашей VPC, считайте это огромным тревожным сигналом.
2. Мониторинг изменений RoleBinding
Контроллерам нужны разрешения. Вредоносному контроллеру требуется ServiceAccount с повышенными привилегиями для нанесения ущерба. Отслеживайте свои журналы аудита на предмет новых RoleBindings, которые предоставляют разрешения watch или list для Секретов или Подов.
3. Проверка аномальных OwnerReferences
Объекты Kubernetes используют OwnerReferences для сборки мусора. Если вы видите поды, которые заявляют, что принадлежат контроллеру, которого не существует или который не соответствует стандартным шаблонам развертывания, немедленно проведите расследование.
Блокировка механизмов
Чтобы предотвратить устойчивость на основе контроллеров, вы должны ограничить доступ к механизмам кластера.
- Ограничение регистрации вебхуков: Используйте RBAC Kubernetes, чтобы гарантировать, что только администраторы кластера (и, в частности, учетная запись конвейера CI/CD) могут создавать или изменять MutatingWebhookConfigurations. Разработчики никогда не должны иметь такого разрешения.
- Сетевые политики для плоскости управления: Если вы используете плоскости управления с самостоятельным управлением, убедитесь, что API-сервер может взаимодействовать только с известными, разрешенными конечными точками вебхуков.
- Подписывайте свои образы: Используйте контроллер допуска, такой как Kyverno или OPA Gatekeeper, чтобы проверить, что каждый образ контейнера в поде, включая внедренные сайдкары, подписан доверенным ключом вашей организации.
Заключительные мысли
Злоумышленники поднимаются по стеку по мере созревания кластеров Kubernetes. Их больше не устраивают простые побеги из контейнеров; они нацеливаются на сам уровень оркестрации.
Паттерн контроллера Kubernetes мощен, поскольку он обеспечивает автоматизацию и самовосстановление. В руках злоумышленника эти же свойства создают постоянную, устойчивую точку опоры. Мы должны перестать относиться к API-серверу как к доверенному черному ящику и начать проводить аудит вебхуков, которые связывают наши кластеры воедино.
Эта статья опубликована в рамках сети экспертных авторов Foundry.
Хотите присоединиться?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Niranjan Kumar Sharma
