По умолчанию 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"

В официальном блоге Kubernetes есть статья "11 Ways (Not) to Get Hacked" от июля 2018 года.

Статья как вы понимаете совсем не новая, но проблемы/рекомендации, описанные в ней до сих пор актуальные.

В статье автор все рекомендации разделил на 2 части - те, что надо реализовать на Control Plane и те, что на Workloads. Для первой категории по большому счету нужно что-то указать, поставить, использовать - есть четкое руководство к действию. Во второй категории все намного сложнее - тут вы должны понять, разобраться, сконфигурировать и все в зависимости от конкретно ваших приложений, что крутятся в кластере.

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

Это приводит к мысли о том, что как бы вы отлично не знали все настройки безопасности Kubernetes, без знания что и как делают ваши приложения в нем добиться хорошей безопасности невозможно.

Сегодня рассмотрим Restricted PodSecurityPolicy из Pod Security Standards. Что такое PodSecurityPolicy можно вспомнить тут.

Хотелось бы выделить следующие несколько моментов:
1) Политики для seccomp и apparmor используются в default конфигурации, так что их еще можно захардеренить.
2) seLinux имеет значение RunAsAny, потому что предполагается, что используется не он, а AppArmor.
3) ReadOnlyRootFilesystem стоит в false, хотя в усиленном варианте тут должно быть true (тут непонятно почему у них так ...)
4) Не определены настройки sysctl профиля: forbiddenSysctls, allowedUnsafeSysctls - используется список по умолчанию (разрешены все безопасные sysctl).

Bonus:
5) Не забывайте об ограничениях по ресурсам (об этом говорили тут)

Так что можно сказать это не идеальная Restricted политика, но очень хорошая для первоначальной цели ...

С 17 по 20 августа в online формате пройдет KubeCon и CloudNativeCon Европа 2020.

За что зацепился мой взгляд:
1) Ряд докладов про сканирование образов контейнеров и при этом все от одной компании с таким продуктом ;)
2) Доклад про запущенную в январе Kubernetes Bug Bounty Program.
3) Доклад про Kubernetes Common Configuration Scoring System (KCCSS) про аналог Common Vulnerability Scoring System (CVSS). Проект уже доступен тут.
4) Доклад про Threat Modelling от сотрудников Citibank - потенциально могут интересно рассказать свой личный опыт. А могут все свести к пересказу проекта от CNCF Financial Services User Group о котором я рассказывал ранее.
5) Доклад про сетевую изоляции 1500 микросервисов - тоже представление личного опыта по решению данной задачи.
6) Доклад про seccomp и интересный проект https://dockersl.im/
7) Доклад "Advanced Persistence Threats: The Future of Kubernetes Attacks" от крутых и известных ребят. Но это пересказ их доклада с RSA Conference 2020.

+ есть Cloud Native Security Day.

Консультируя, время от времени встречаю вопросы о различных стандартах в сфере Kubernetes. Прям стандартов нет, но есть два хороших документа, которые могут служить заменой/подменой таковым:

- CIS Kubernetes Benchmark (271 стр) - step-by-step checklist для Kubernetes.
Состоит из рекомендаций для: Control Plane Components (Master Node Configuration Files, API Server, Controller manager, Scheduler), etcd, Control Plane Configuration, Worker Nodes (Worker Node Configuration Files, Kubelet), Policies (RBAC and Service Accounts, Pod Security Policies, Network Policies and CNI, Secrets Management, Extensible Admission Control, General Policies).

- NIST Special Publication 800-190 "Application Container Security Guide" (63 стр) - руководство о контейнерных угрозах, рисках и то ка ким можно противодействовать без привязки к системе оркестрации.

Основные разделы: Introduction to Application Containers, Major Risks for Core Components of Containers Technologies, Countermeasure for Major Risks, Container Threat Scenario Examples, Container Technology Life Cycle Security Considerations.

Есть еще и CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.0.0 и CIS Google Kubernetes Engine (GKE) Benchmark v1.0.0. Также у CIS в разделе Cloud Providers можно найти документы по: Amazon Web Services, Google Cloud Computing Platform, Microsoft Azure и Oracle Cloud Infrastructure.

Стоит отметить с какой скоростью в Kubernetes вносятся изменения и улучшения, данные документы лишь ориентир, так как они не обновляются так часто.

P.S.
NIST - National Institute of Standarts and Technology
CIS - Centre of Internet Security