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

CVE-2020-8558: Node setting allows for neighboring hosts to bypass localhost boundary

Level:
1) MEDIUM (5.4) в обычном кластере.
2) HIGH (8.8) в кластере где API server insecure port не отключен.

В kube-proxy была обнаружена уязвимость, которая позволяет соседним хостам обращаться к TCP/UDP службам, связанным с 127.0.0.1, работающими на Node или в namespace сети Node. Например, если администратор кластера запускает TCP службу на Node, которая прослушивает 127.0.0.1:1234, то из-за этой ошибки эта служба будет потенциально доступна для других хостов в той же LAN, что и Node, или для контейнеров, работающих на той же Node, что и сервис. Спасти от этого может наличие аутентификации на данном сервисе. IPv6-only сервисы на localhost не подвержены данной проблеме.

Во вотором случае, злоумышленник, имеющий доступ к другой системе в той же LAN или контролирующий контейнер, работающий на master сервере, может выполнять произвольные API запросы без аутентификации к Kubernetes API (127.0.0.1:8080)!

Безопасность Harbor. В октябре 2019 года под эгидой CNCF проводился 3rd party security audit для Harbor v1.9.1-rc1 и Harbor Helm v1.2.0 (На момент написания актуальные версии v2.0.1 и v1.4.1). Весь аудит состоял из двух фаз:
1) Пентеста
2) Анализа исходного кода

Было найдено 6 security проблем, из них 4 классифицированы как уязвимости (2 High уровня и 1 как Critical):
- HAR-01-001 Web: Missing CSRF protection leads to privilege escalation (Critical, CVE-2019-19025)
- HAR-01-002 API: SQL Injection via project quotas (High, CVE-2019-19026)
- HAR-01-005 ACL: Unauthorized project-access through project name (Medium)
- HAR-01-006 Web: DOMXSS in outdated Swagger UI (High)
и 2 как слабости:
- HAR-01-003 API: Split-API Injections due to unsanitized input (Low)
- HAR-01-004 Auth: Potential SQL Injection via user-groups (High, CVE-2019-19029)

Для всех уязвимостей в отчете есть PoC'и.

При этом если посмотреть на страницу Security Advisories данного проекта, то там будет всего 7 уязвимостей и пересечения с данным отчетом всего 3. Почему отсутствуют другие уязвимости из отчета там непонятно...

Вчера на свет появился Kubernetes v1.19.0-rc.1 и там есть интересное изменение с точки зрения безопасности, направленное на уменьшение поверхности атаки (attack surface).

Теперь Pod sandbox всегда будет запушен с no-new-privileges и runtime/default seccomp профилем. Как побочный эффект, это позволяет конечным пользователям устанавливать seccomp профили на уровне Pod'ов такие же как и на уровне контейнеров. Естественно, при условии, что Pod имеет контейнеры только с настройкой AllowPrivilegeEscalation = false.

Обнаружено 2 новые уязвимости в Kubernetes:

CVE-2020-8557: Node-local denial of service via container /etc/hosts file

CVSS Rating: Medium (5.5)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H/CR:H/IR:H/AR:M

Суть в том что вредоносный Pod, в который смонтирован /etc/hosts файл с Node, может туда писать огромное количество данных и заполнить все место на Node и вызвать отказ в обсаживании там. Ошибка в расчете при использовании ephemeral storage. Актуально для Pods с контейнерами с возможностью писать туда или свойствами: CAP_DAC_OVERRIDE capabilities, UID 0 (root) правами или allowPrivilegeEscalation: true (по умолчанию).


CVE-2020-8559: Privilege escalation from compromised node to cluster

CVSS Rating: Medium (6.4)
CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H

Если злоумышленник может перехватить определенные запросы к Kubelet, то он может отправить redirect response, по которому может последовать клиент, используя учетные данные из исходного запроса. Это может привести к компрометации других Node.
Данная уязвимость актуально для вас только в том случае, если вы рассматриваете Node как security boundary или если кластеры разделяет между собой certificate authorities и аутентификационные данные.

В недрах Gartner родился (новый монстр) концепция - куб киберугроз. Каждая из граней куба представляет определённое свойство: уровень/слой приложения/инфраструктуры (Cloud тут естественно присутствует), цель атакующего и стадию, на которой работает механизм защиты (до, во время и после инцидента). А внутри получившихся 27 более маленьких кубов отмечаются соответствующие уровни риска. В принципе, достаточно простая и понятная концепция, которую можно визуализировать что у вас есть чего нету и на каком уровне. По мне внутри можно расположить что конкретно у вас для этого сделано. Так, на пример, можно выписать какие настройки Kubernetes где и как помогают до инцидента (PodSecurityPolicy, Network Policy и т.д.), во время инцидента (run-time защита и т.д.) и после инцидента (Логи и т.д.).

Сегодня рассмотрим 2 простеньких, но полезных запроса на GitHub'е проекта Kubernetes:
- https://github.com/search?q=org%3Akubernetes+CVE&type=Issues
- https://github.com/kubernetes/kubernetes/issues?q=CVE

Суть их проста до безобразия - поиск сокращения CVE (Common Vulnerabilities and Exposures) в issue во всех проектах, что есть у организации Kubernetes и непосредственно в репозитарии Kubernetes. По такому сокращению (это часть идентификатора уязвимости) можно находить как обсуждения каких-то уже известных уязвимостей в сторонних пакетах, используемых в проекте, так и новые, что были выданы компонентам Kubernetes.

Пентестерам на заметку. Есть такая замечательная тулза `crictl на Go для troubleshooting'а при работе с различными `CRI-совместимыми runtime'мами. Она из коробки поддерживает dockershim, containerd, cri-o, frakti.

Так в случае если вы попали на Node (тем или иным способом) или внутрь проброшен кто-то из: unix:///var/run/dockershim.sock , unix:///run/containerd/containerd.sock, unix:///var/run/crio/crio.sock, unix:///var/run/frakti.sock, tcp://localhost:3735 (для Windows), и вы без понятия что за container runtime используется в инфраструктуре, то crictl заговорит с ними сразу на одном языке. Тулза имеет широкий список команд из коробки и понимает, что такое Pod. На хост инструмент можно удобно забрать с помощью curl или wget с официального репозитария)

Занимаясь основное время разработкой детектора аномального поведения приложений в Kubernetes, узнаешь много нового о приложениях и ловишь интересные кейсы. На пример, я думаю мало кто ожидает и знает, что процесс calico-node известного CNI раз в сутки с каждой Node лезет и отстукивается в сеть интернет ... Дальнейший анализ коллег показал, что это все из-за настройки по умолчанию UsageReportingEnabled (стоит в true). Ее назначение заключается в анонимном докладе версии Calico, размере кластера на projectcalico.org

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

В последние пару дней меня заспамили новостью про Ngrok Mining Botnet, который атакует Docker сервера в AWS, Azure и других облачных платформах, у кого открыт доступ к Docker API.

В процессе атаки злоумышленники запускают свои контейнеры на базе alpine образа с DockerHub с curl внутри. Делают container escape через mount корневой директории хоста, модифицируют cron file и скачивают Doki backdoor.

Авторы стать пишут про "undetected Doki backdoor". Почему они называют это undetected совершенно непонятно?! Тут и новый образ, и новое поведение образа (если вдруг вы используете уже такой же), но если вы не знаете, что у вас и как работает, то возможно и в правду это undetected для вас. Но приводить результат скана VirusTotal в 2020 году как доказательство undetected это прям очень смешно)

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

И по этой теме мне очень нравится высказывание Thomas Dullien / Halvar Flake: "The only thing that ever yielded real security gains was controlling complexity."

Вчера началась программная часть конференции BlackHat USA 2020.

Был представлен доклад с громким названием "Defending Containers Like a Ninja: A Walk through the Advanced Security Features of Docker & Kubernetes" (слайды уже доступны). На самом деле это выжимка из документаций (https://docs.docker.com/ и https://kubernetes.io/docs) по настройке и харденингу контейнеров (демона и образов) Docker и немного про Swarm и Kubernetes окружения. Все собрано достаточно добротно в одном месте - можно использовать как checklist для настройки docker. Хотя части про Swarm и Kubernetes тут скорее притянута за уши для увеличения значимости доклада.

Но есть цитата, которая мне очень понравилась и пересекается с моим предыдущим сообщением: "Complexity is the worst enemy of security"