В недрах 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

Вторая тема (после runtime behaviour analysis), которая мне чрезвычайно нравится в безопасности и в безопасности Kubernetes, в частности, это уменьшение поверхности атаки - attack surface reduction. Основная суть которой: "The basic strategies of attack surface reduction include the following: reduce the amount of code running, reduce entry points available to untrusted users ...".

Возьмем пример из IoT: если умная лампочка на борту имеет CPU общего назначения и полноценную ОС Linux, то она сразу становится очень перспективной и привлекательной целью для злоумышленника для организации плацдарма для дальнейших атак. Хотя, по сути, там должен быть микроконтроллер, который позволяет регулировать яркость, цвет и включать, и выключать ее. По этой теме/проблеме есть замечательная презентация "Security, Moore’s law, and the anomaly of cheap complexity".

Для контейнерных приложений ситуация аналогичная: если атакующий попадает на контейнер, где есть подходящее ему окружение (на пример, тулы curl, wget, отладчики, интерпретаторы и т.д.), то ему и дальнейшую атаку выполнять куда проще и на другие контейнеры и инфраструктуру в целом.

При этом attack surface reduction сильно связана с runtime behaviour analysis, ведь чем более неблагоприятные условия попадает атакующий, тем больше ему приходится совершать лишних/пробных действия, что отражается на runtime behaviour и выдает атакующего.

К сожалению, такие контейнеры можно редко у кого встретить, хотя инструменты и механизмы для этого есть, на пример связка: distroless images + Ephemeral Containers (для отладочных целей (с 1.16 в alpha)).

Некоторое время назад мы уже обсуждали тему специально подготовленного image для пентеста контейнерных инфраструктур. И там речь шла о проекте botty. Сегодня хотелось бы представить проект под названием hacker-container, который сам автор описывает как: "Container with all the list of useful tools/commands while hacking Kubernetes Clusters" . На борту данного контейнера порядка 52 инструментов и есть еще список todo, что автор хочет туда добавить.

Сравнивая инструменты, что есть в его составе и в составе botty можно достаточно легко прийти к выводу, что хоть в botty и меньше инструментов, но они там больше специализируются и на контейнерах и на Kubernetes и на облаках в целом. В составе же hacker-container есть много сканеров, брутеров и других инструментов, для классических сетевых и web пенестов.

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

На сайте конференции KubeCon + CloudNativeCon Европа 2020. Выложили слайды и транскрипции выступлений (где-то только транскрипции, видео пока не доступно).
- Доклады с KubeCon + CloudNativeCon (+ фильтр "Security + Identity + Policy")
- Доклады с Cloud Native Security Day

Попозже обязательно рассмотрим отдельно наиболее интересные доклады по теме security.

В версии Kubernetes 1.19 поддержка seccomp перешла в статус General Availability (GA) (начало было положено в 1.10)! Благодаря данной штуке можно повышать безопасность ваших workload'ов с помощью ограничений допустимых системных вызовов для определенного Pod'а (и всех контейнеров внутри него) или чисто для определенного контейнера. Это сузит Attack Surface для злоумышленника и может ему очень сильно усложнить попытки поднять свои привилегии или сбежать из контейнера. Задаются эти профили в securityContext в seccompProfile секции spec при описании Pod или в PodSecurityPolicy. Более технические моменты реализации данного механизма можно посмотреть в KEP - Seccomp to GA.

Подробнее о использовании seccomp в Kubernetes можно почитать на страничке tutorials. Там же можно посмотреть, как выглядят данные профили.

Проблемой для применения в проде seccomp по-прежнему остается сложность создания полноценных fine-grained профилей, что может привести к аварийному завершению приложения. Имеющиеся инструменты oci-seccomp-bpf-hook, go2seccomp, а также "SCMP_ACT_LOG" режим самого seccomp имеет ряд недостатков и ограничений ... Хотя для начала можно начать и с типа RuntimeDefault, но нет гарантий что даже он у вас заработает.

C релизом Kubernetes 1.19 увеличилось окно поддержки с 9 месяцев до 1 года (начиная только с этой версии!). По-простому, теперь вместо поддержи 3 релизов, будет поддержка 4 релизов, что и увеличит поддержку до 1 года.

Раньше нужно было обновляться как минимум 1 раз в 9 месяцев чтобы иметь поддерживаемую версию.

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

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

Поговорим сегодня о Honeypots, а именно о Honeypot stack на Kubernetes под названием beehive. В этот стек сейчас входит 15 honeypot'ов, покрывающих:
- Android Debug Bridge over TCP/IP
- Cisco ASA honeypot
- ICS/SCADA honeypot
- SSH/Telnet honeypot
- dionaea honeypot
- Elasticsearch honeypot
- Credentials catching honeypot
- Low to medium interaction honeypot
- TCP or UDP services honeypot
- SMTP Honeypot
- HL7 / FHIR honeypot
- RDP honeypot
- Web application honeypot sensor

И за всем смотрим логи с помощью Elasticsearch и Kibana.

Если ваше приложение уже работает в K8s, то можно очень просто сделать honeypot инсталляцию вашего сервиса или специальную тестовую инсталляцию для растерзания при аудите/пентесте или BugBounty, чтобы случайно не пострадали пользовательские данные. K8s позволяет очень быстро и гибко развернуть вашу уникальную приманку (ваш собственный сервис) как у себя локально, так и в любом облаке, в любом масштабе. В данном направлении уже есть выступления на конференциях ("How to Deploy Honeypots into your Kubernetes"), так и отдельные статьи ("Creating and Deploying Honeypots in Kubernetes"). Это позволит ловить на 1-day так и 0-day атаки на ваше приложение. Тут главное, чтобы у вас был хороший мониторинг нацеленный на Container RunTime Security.


Вся тема honeypot'ов получила в последнее время вторую жизнь благодаря лозунгам "Detection through Deception", "Security Through Deception" и продуктам класса Deception Technology (спасибо маркетологам).