CVE-2020-8555: Half-Blind SSRF в kube-controller-manage

Level: Medium (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N)

Данная Server Side Request Forgery (SSRF) уязвимость позволяет определенным авторизованным пользователям сливать до 500 байт произвольной информации с незащищенных эндпоинтов внутри master хост сети (таких как link-local или loopback сервисов).

Атакующий с разрешением на создание Pod'ов с определеным типом Volume (GlusterFS, Quobyte, StorageFS, ScaleIO) или разрешением на создание StorageClass может заставить kube-controller-manager делать GET или POST запросы (без контроля содержимого тела запроса) из master хост сети по предоставленному пользователем не проверенному URL.

Также сообщается что аутентификационных данный не утекает, то в утекаемых данных может быть что-нибудь интересное.

Если посмотреть патч, то можно увидеть кучу добавленных проверок с комментарием: "don't log error details from client calls in events".

И еще одна недавно закрытая уязвимость по теме Kubernetes!

MitM атаки в уязвимой контейнерной сети в IPv4 only кластере.

CVSS Rating: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L (6.0 Medium)

Атакующий в подконтрольном контейнере может сформировать специальные ICMPv6 Router Advertisement (RA) сообщения, тем самым перенастроить хост для перенаправления части или всего IPv6 трафика хоста в контролируемый атакующим контейнер. Причина в том что, если даже раньше не было IPv6 трафика и при условии, что DNS возвращает A (IPv4) и AAAA (IPv6) записи, большинство HTTP библиотек будут сначала пытаться подсоединится по IPv6, а затем уже при неудачи переходить к IPv4, тем самым давая возможность атакующему ответить первому и организовать MitM атаку.

Атакующему для проведения такой атаки необходимо находится внутри контейнера с CAP_NET_RAW привилегией (о ней мы и говорили и вчера) в уязвимом окружении. В результате он сможет перехватывать трафик других контейнеров на хосте или самого хоста, где он находится.

Очень неожиданное применение Kubernetes по данным TheRegister.

Исследователи что нашли Half-Blind SSRF в kube-controller-manage (CVE-2020–8555) опубликовали отличное техническое описание как самой уязвимости, так и различные сценарии ее эксплотации. Есть и PoC на базе которого можно уже повторить все сценарии атак, что перечислены в статье:
- Redirecting POST to GET HTTP request trick and sensitive data exposure
- Lan scanning
- CRLF + smuggling HTTP injection in “old” Kubernetes cluster releases

В данном анализе очень хорошо раскрывается момент насколько это критично для облачных провайдеров, что предоставляют managed Kubernetes - там, где за master plane отвечает не клиент, а облачный провайдер.

И в итоге они получили вознаграждение сразу в трех программах: Google VRP, MSRC Bug Bounty (Azure Cloud Bug Bounty) и от Kubernetes через HackerOne.

Сегодня исполняется 6 лет платформе Kubernetes!

"A Survey of Istio’s Network Security Features" - замечательное исследование фич безопасности самой популярной service mesh для Kubernetes.

Авторы на примере своей лабы показывают различные недоработки, ограничения, мисконфиги и подводные камни Istio версии 1.5 (текущая 1.6). В основном они рассматривают:
- IPv6 - специфика работы с ним и ограничения.
- Mutual TLS - способы обхода, мисконфиги.
- Egress restrictions - обходы запрета обращений во внешку.

Все это сопровождается понятными сценариями проверки и при желании можно повторить. Все эти техники и нюансы по работе внутри сети, где используется Istio могут быть очень полезны как в защите, так и в атаке.

Лично мое мнение что security функциональность у Istio находится на третьих-четвертых ролях и это совсем не security инструмент. Без NetworkPolicy не обойтись в любом случае, а что-то им и так можно решить не прибегая к Istio.

Прежде чем как начинать вносить различные правки, улучшения, хардеринги безопасности в свой Kubernetes кластер. Нужно хорошо понимать, что вообще происходит внутри него и что он умеет делать.

Для это есть отличная статья "What happens when ... Kubernetes edition!" (перевод). В ней рассматривается весь жизненный цикл от команды с kubectl до старта контейнера в Pod`е сквозь `kube-apiserver, etcd, различные controllers, kubelet, CRI, CNI и т.д.

С точки зрения безопасности тут поднимаются моменты связанные с:
- клиентской аутентификацией
- процессом авторизации
- назначением и работой admission controllers

Если вам не терпится сразу что-то вводить и пытаться поломать Kubernetes, то в достаточно популярном GitHub проекте PayloadsAllTheThings есть раздел и по Kubernetes. Там собраны самые базовые команды, ресурсы, что могут пригодиться при пентесте Kubernetes.

В открытом доступе появился PoC эксплоит для CVE-2020-10749 для проведения Kubernetes MitM атаки через отправку специального ICMPv6 Router Advertisement (RA) сообщения. О деталях данной проблемы я писал ранее.

Kubernetes Goat - это специально заготовленный Kubernetes кластер с классическими уязвимостями, слабостями и проблемами для обучающих целей. Серия Goat достаточно популярно в security сообществе - есть и web-приложения, mobile-приложения и т.д. И вот очередь дошла и до Kubernetes.

На текущий момент Kubernetes Goat содержит 11 уязвимых сценариев и 3 для знакомства с инструментами Docker CIS Benchmarks, Kubernetes CIS Benchmarks и Hacker Container. Видно, что проект новый и сценариев мало и они не блещут хорошим разнообразием. Но для самого старта сойдет. Уязвимые сценарии:
- Sensitive keys in code bases
- DIND(docker-in-docker) exploitation
- SSRF in K8S world
- Container escape to access host system
- Attacking private registry
- NodePort exposed services
- Helm v2 tiller to PwN the cluster
- Analysing crypto miner container
- Kubernetes Namespaces bypass
- Gaining environment information
- DoS the memory/cpu resources

29 июня состоится однодневная, виртуальная, бесплатная конференция `fwd:cloudsec`. Данная конференция специализируется на докладах про безопасность AWS, GCP, Azure и, конечно, Kubernetes.

При запуске kube-controller-manager убедитесь, что используется ключ --use-service-account-credentials. Он говорит о том, что будут использоваться специализированные service account credentials для каждого контроллера. Иначе все контроллеры будут запущены от service account, принадлежащему `kube-controller-manager` и включающему все права для всех контроллеров. В итоге это, при компрометации service account на каком-либо из контроллеров атакующий получит чрезвычайно мощный service account. Используйте --use-service-account-credentials, чтобы минимизировать возможные последствия при компрометации какого-либо контроллера.

Очень интересная статья/исследование на тему, которую мы уже тут поднимали, - сканирование образов контейнеров на известные уязвимости (1-day). Для этого автор взял 3 open-source сканера и натравил их на 4 базовых образа ОС с DockerHub.

Краткие выводы:
- Все сканеры дали разные результаты как по количеству, так и по уровню критичности
- Все сканеры поддерживают разные наборы базовых изображений
- Даже в полностью обновленном базовом образе все еще могут быть известные CVE

Kubernetes опубликовал "Pod Security Standards", где подробно объясняет какие настройки, когда, где и как использовать в Pod Security Policy. Для этого они все политики разделили на 3 типа:
- Privileged - неограниченная политика, предоставляющая большую свободу, позволяет проводить хорошо известные поднятия привилегий.
- Baseline/Default - минимально закручиваем гайки чтобы предотвратить хорошо известные поднятия привилегий.
- Restricted - максимально закручиваем гайки.

Конференция fwd:cloudsec 2020, о которой мы писали недавно, сейчас в прямом эфире!

Все больше сталкиваюсь с темой расследования инцидентов в облачной, контейнерной инфраструктуре. И несомненно окружение оказывает сильное влияние на данные процесс. Pod’s с контейнерами внутри живут не так долго как классические приложения, они много обновляются, скейлятся как в одну так и другую сторону и т.д. Ограниченный, достаточно малый промежуток времени жизни контейнера вводит расследование инцидентов в чрезвычайно жесткие рамки с одной стороны. А с другой стороны, подпирают ресурсы не позволяющие просто так висеть контейнерам, кушать место и ждать, когда кто-то из ИБ специалистов обратит на них внимание.
В итоге получаем, что скорость разработки, развертки, сопровождения приложения накладывают такие же требования по скорости и на стадии безопасности. Они должны друг другу соответствовать.
IMHO, выходом из ситуации является своевременное уведомление и обработка инцидентов по данным от RunTime решений, без перекладывания в долгий ящик.

Безопасность etcd это критически важный элемент безопасности Kubernetes. Доступ к etcd равноценен root правам на кластере!

Там хранится вся критичная информация. Все в Kubernets это YAML и весь YAML хранится там)

Обязательно нужно настроить и контролировать 2 основных аспекта работы etcd:
1) Жестко ограничить список клиентов, которые с ним могут взаимодействовать. В идеале должен быть только API сервер. Естественно, никакого доступ из общей сети компании или из сети интернет! Тут на помощь приходят правила firewall и фичи PKI инфраструктуры.
2) Настроить безопасное взаимодействие между ним и клиентами - HTTPS в помощь.

Запомните одно, что если атакующий получает доступ к etcd, то это game over.

По умолчанию role bindings позволяют аутентифицированным и не аутентифицированным пользователям читать информацию о доступном API, версиях, состоянии в кластере, включая CustomResourceDefinitions.

Это плохо, потому что анонимный не аутентифицированный атакующий, может использовать эту информацию как для подготовки к атаке (на пример, по версии понять как ему надо модифицировать/подготовить тот или иной эксплоит или на основании CustomResourceDefinitions понять что у вас вообще используется и крутится в кластере), так и для ее проведения (на пример, DoS).

Для отключения возможности анонимного не аутентифицированный доступа к этому необходимо добавить параметр --anonymous-auth=false к конфигурации API сервера.

Сегодня обратим внимание на один тонкий момент по работе с etcd с помощью kubeadm. Сразу отметим, что такое поведение исправлено с версии 1.16.

kubeadm делал общий CA для API сервера и etcd. А авторизации у etcd, как вы наверняка уже знаете нет, и получаем, что любой клиент с валидным сертом, считай любой юзер/атакующий даже с минимальными правами, мог ходить в etcd. К чему это может привести мы уже обсуждали ранее.

Суть исправления в том, что теперь kubeadm для API сервера и etcd генерирует разные CA. Но если вы это все делаете руками или самописными скриптами, то держите это в голове, не стреляйте себе в ногу. Подробнее можно почитать и про флаг --peer-trusted-ca-file для etcd