Добро пожаловать обратно, начинающие кибервоины!
В этой статье мы рассмотрим, как искать и эксплуатировать уязвимости в API Kubernetes Kubelet, уделяя особое внимание неаутентифицированному доступу по умолчанию.
Kubernetes — это портативная, расширяемая платформа с открытым исходным кодом для управления контейнеризированными рабочими нагрузками и сервисами. При развертывании Kubernetes создается кластер. Кластер Kubernetes состоит из набора рабочих машин, называемых узлами , на которых выполняются контейнеризированные приложения. В каждом кластере есть как минимум один рабочий узел.
Kubernetes управляет вашей рабочей нагрузкой, помещая контейнеры в поды для работы на узлах. Плоскость управления (также известная как мастер) управляет рабочими узлами и подами в кластере. Компоненты плоскости управления принимают глобальные решения относительно кластера, а также обнаруживают и реагируют на события кластера.
В кластере объединено множество компонентов. Для простоты следует помнить, что:
Kubelet — это основной компонент узла; это агент, работающий на каждом узле кластера. Он отвечает за управление всеми контейнерами, работающими в каждом поде кластера .
API -сервер Kube — это компонент плоскости управления Kubernetes, предоставляющий доступ к API Kubernetes. API-сервер представляет собой интерфейс для плоскости управления Kubernetes и единственный компонент, с которым все остальные главные и рабочие компоненты могут напрямую взаимодействовать. Разработчики и операторы могут взаимодействовать с API-сервером через клиент командной строки kubectl или посредством вызовов REST API.
Согласно правилам контроля доступа к Kubelet:
Kubelet предоставляет конечные точки HTTPS, обеспечивающие мощный контроль над узлом и контейнерами. По умолчанию Kubelet разрешает неаутентифицированный доступ к этому API. В производственных кластерах аутентификация и авторизация Kubelet должны быть включены.
Кроме того, согласно документации по аутентификации/авторизации Kubelet:
« По умолчанию запросы к HTTPS-конечной точке Kubelet, не отклоненные другими настроенными методами аутентификации, обрабатываются как анонимные. Любой запрос, успешно прошедший аутентификацию (включая анонимный), затем авторизуется. Режим авторизации по умолчанию — AlwaysAllow, который разрешает все запросы».
Это означает, что при настройке по умолчанию единственным требованием для получения полного доступа к API Kubelet является доступ к сети.
Этот API по умолчанию доступен через порт 10250/TCP и должен быть доступен только для внутрикластерного взаимодействия (kube-apiserver → kubelet). Однако отсутствие сетевой сегрегации и слабые правила брандмауэра могут позволить атаки извне кластера.
Найти этот сервис довольно просто. Например, в Shodan можно ввести: порт:10250 страна: «RU».
В некоторых случаях будет доступен только доступ для чтения. Это означает, что мы сможем получить только информацию из API: настройки кластера, имена подов и другие параметры. Эта информация не критична, но также важна для взлома.
Мы можем воспользоваться этим, например, перейдя по следующему URL-адресу: https://<IP>:10255/pods
Хотя есть и некоторые проблемы: API Kubelet не документированы, но когда это останавливало хакеров? Исходный код можно посмотреть на Github.
Нас интересует строка, которая начинается с «path(»
Там мы можем наблюдать следующие конечные точки:
и другие.
Обратите внимание на /exec/ и /run/ . Они могут использоваться для выполнения кода внутри контейнера. Инструменты для эксплуатации уязвимости уже можно найти на Github, но для лучшего понимания процесса мы воспользуемся curl.
Очевидно, что большинство результатов будут ложноположительными или будут содержать защищённые API (которые вернут ответ «Неавторизованный»). Продолжайте поиск или настройте фильтры, чтобы найти нужные.
Попробовав сделать запрос к API, мы в конечном итоге можем получить ответ:
kali> curl -k https://<IP>:10250/runningpods/
Мы только что обнаружили наш незащищённый неаутентифицированный API. Подробный список запущенных модулей/контейнеров возвращается в формате JSON. Для более наглядного представления можно использовать инструмент «jq» для анализа только имён модулей:
kali> curl -k https://<IP>:10250/runningpods/ | jq '.items[]. metadata.name '
Чтобы получить пространство имен, модули и контейнеры, мы можем использовать следующую команду:
kali> curl -s -k https://<IP>:10250/runningpods/ | jq -r '.items[]| [.metadata.namespace, . metadata.name , [.spec.containers[].name]]'
Для запуска команды в контейнере можно использовать следующую команду:
kali> curl -XPOST -k \https://<IP>:10250/run/<пространство_имен>/<pod>/<контейнер> -d “cmd=<команда_для_запуска>”
Существуют инструменты для автоматизации поиска уязвимых API Kubelet на Shodan, например Kubolt — простая утилита, предназначенная для сканирования общедоступных неаутентифицированных кластеров Kubernetes и выполнения команд внутри контейнеров.
Вот скриншот демонстрации:
В этой статье мы рассмотрели, как атаковать кластеры Kubernetes с помощью API Kubelet. Мы обсудили методы выявления и эксплуатации этих уязвимостей, включая то, как хакеры могут выполнять команды внутри контейнеров, что потенциально может привести к полному контролю над кластером. Поскольку популярность Kubernetes продолжает расти, важно уделять первостепенное внимание его безопасности для защиты от подобных угроз.
В этой статье мы рассмотрим, как искать и эксплуатировать уязвимости в API Kubernetes Kubelet, уделяя особое внимание неаутентифицированному доступу по умолчанию.
Kubernetes — это портативная, расширяемая платформа с открытым исходным кодом для управления контейнеризированными рабочими нагрузками и сервисами. При развертывании Kubernetes создается кластер. Кластер Kubernetes состоит из набора рабочих машин, называемых узлами , на которых выполняются контейнеризированные приложения. В каждом кластере есть как минимум один рабочий узел.
Kubernetes управляет вашей рабочей нагрузкой, помещая контейнеры в поды для работы на узлах. Плоскость управления (также известная как мастер) управляет рабочими узлами и подами в кластере. Компоненты плоскости управления принимают глобальные решения относительно кластера, а также обнаруживают и реагируют на события кластера.
В кластере объединено множество компонентов. Для простоты следует помнить, что:
Kubelet — это основной компонент узла; это агент, работающий на каждом узле кластера. Он отвечает за управление всеми контейнерами, работающими в каждом поде кластера .
API -сервер Kube — это компонент плоскости управления Kubernetes, предоставляющий доступ к API Kubernetes. API-сервер представляет собой интерфейс для плоскости управления Kubernetes и единственный компонент, с которым все остальные главные и рабочие компоненты могут напрямую взаимодействовать. Разработчики и операторы могут взаимодействовать с API-сервером через клиент командной строки kubectl или посредством вызовов REST API.
API Kubelet
Согласно правилам контроля доступа к Kubelet:
Kubelet предоставляет конечные точки HTTPS, обеспечивающие мощный контроль над узлом и контейнерами. По умолчанию Kubelet разрешает неаутентифицированный доступ к этому API. В производственных кластерах аутентификация и авторизация Kubelet должны быть включены.
Кроме того, согласно документации по аутентификации/авторизации Kubelet:
« По умолчанию запросы к HTTPS-конечной точке Kubelet, не отклоненные другими настроенными методами аутентификации, обрабатываются как анонимные. Любой запрос, успешно прошедший аутентификацию (включая анонимный), затем авторизуется. Режим авторизации по умолчанию — AlwaysAllow, который разрешает все запросы».
Это означает, что при настройке по умолчанию единственным требованием для получения полного доступа к API Kubelet является доступ к сети.
Этот API по умолчанию доступен через порт 10250/TCP и должен быть доступен только для внутрикластерного взаимодействия (kube-apiserver → kubelet). Однако отсутствие сетевой сегрегации и слабые правила брандмауэра могут позволить атаки извне кластера.
Найти этот сервис довольно просто. Например, в Shodan можно ввести: порт:10250 страна: «RU».
В некоторых случаях будет доступен только доступ для чтения. Это означает, что мы сможем получить только информацию из API: настройки кластера, имена подов и другие параметры. Эта информация не критична, но также важна для взлома.
Мы можем воспользоваться этим, например, перейдя по следующему URL-адресу: https://<IP>:10255/pods
Хотя есть и некоторые проблемы: API Kubelet не документированы, но когда это останавливало хакеров? Исходный код можно посмотреть на Github.
Нас интересует строка, которая начинается с «path(»
Там мы можем наблюдать следующие конечные точки:
- /стручки/
- /бегать/
- /exec/
- /прикреплять/
- /runningpods/
и другие.
Обратите внимание на /exec/ и /run/ . Они могут использоваться для выполнения кода внутри контейнера. Инструменты для эксплуатации уязвимости уже можно найти на Github, но для лучшего понимания процесса мы воспользуемся curl.
Очевидно, что большинство результатов будут ложноположительными или будут содержать защищённые API (которые вернут ответ «Неавторизованный»). Продолжайте поиск или настройте фильтры, чтобы найти нужные.
Попробовав сделать запрос к API, мы в конечном итоге можем получить ответ:
kali> curl -k https://<IP>:10250/runningpods/
Мы только что обнаружили наш незащищённый неаутентифицированный API. Подробный список запущенных модулей/контейнеров возвращается в формате JSON. Для более наглядного представления можно использовать инструмент «jq» для анализа только имён модулей:
kali> curl -k https://<IP>:10250/runningpods/ | jq '.items[]. metadata.name '
Чтобы получить пространство имен, модули и контейнеры, мы можем использовать следующую команду:
kali> curl -s -k https://<IP>:10250/runningpods/ | jq -r '.items[]| [.metadata.namespace, . metadata.name , [.spec.containers[].name]]'
Для запуска команды в контейнере можно использовать следующую команду:
kali> curl -XPOST -k \https://<IP>:10250/run/<пространство_имен>/<pod>/<контейнер> -d “cmd=<команда_для_запуска>”
Существуют инструменты для автоматизации поиска уязвимых API Kubelet на Shodan, например Kubolt — простая утилита, предназначенная для сканирования общедоступных неаутентифицированных кластеров Kubernetes и выполнения команд внутри контейнеров.
Вот скриншот демонстрации:
Краткое содержание
В этой статье мы рассмотрели, как атаковать кластеры Kubernetes с помощью API Kubelet. Мы обсудили методы выявления и эксплуатации этих уязвимостей, включая то, как хакеры могут выполнять команды внутри контейнеров, что потенциально может привести к полному контролю над кластером. Поскольку популярность Kubernetes продолжает расти, важно уделять первостепенное внимание его безопасности для защиты от подобных угроз.
