Занимаясь основное время разработкой детектора аномального поведения приложений в 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 (спасибо маркетологам).

Выложили видео выступлений с KubeCon + CloudNativeCon Europe 2020

Выложили ряд видео докладов с Cloud Native Security Day:

- Opening Remarks - Emily Fox, US National Security Agency
- Collection is not Detection - Sec Ops in a Cloud Native Environment - Sarah Young, Microsoft
- PARSEC: A New Platform Abstraction for Security - Hugues de Valon & Ionut Mihalcea, Arm
- Image Provenance and Security in Kubernetes - Adrian Mouat, Container Solutions
- Cloud native or cloud agnostic? The questions you need to ask - Sriram Rajan, Rackspace
- How Secure Is Your Build/Server? - Patrick Debois, Snyk
- Pod Security as an Afterthought - Alban Crequy, Kinvolk
- Defenders Think in Lists. Attackers Think in Graphs. - Reuven Harrison, Tufin
- Kubernetes Attack and Defense: Inception-Style - Jay Beale, InGuardians
- New Paradigms for the Next Era of Security - Sounil Yu, Cyber Defense Matrix
- Closing Remarks - Brandon Lum, IBM

Интересная (но предсказуемая) эволюция арсенала преступной группы TeamTNT, атакующей облачные окружения, включая Docker, Kubernetes. Теперь на ряду с криптомайнерами, зараженными docker образами есть и легитимные инструменты. В частости известный инструмент для мониторинга Weave Scope. Они используют его для составления карты окружения жертвы, выполнения системных команд без деплоя вредоносного кода. В результате они получают мощный backdoor на основе легитимного инструмента.

Развитие атаки:
1) Через доступный Docker API устанавливают привилегированный контейнер с чистым образом Ubuntu
2) Данный контейнер сконфигурирован с маунтом к файловой системе сервера жертвы для полного доступа к файлам сервера
3) Скачивание и выполнение криптомайнеров на сервере
4) Попытка получения root доступа на сервере и создание пользователя ‘hilde’ для соединения по SSH
5) Скачивание и установка Weave Scope с git
6) Подключение к Weave Scope dashboard по HTTP на 4040 порт для полного контроля инфраструктуры жертвы.

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

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

При проектирование своего Kubernetes кластера чрезвычайно важным его элементом является Container Runtime. При этом мало кто знает, что он, по сути, состоит из 2 частей: High-level Runtime и Low-level Runtime.

High-level Runtime (CRI Implementations):
• Dockershim
• CRI-O
• Containerd
• Frakti
• rktlet

Low-level Runtime (OCI Runtimes):
• runC
• runV
• Clear Containers
• kata-runtime
• gVisor


Изучая и сравнивая Docker и Containerd - можно лишний раз убедиться, что специализированное решение (Containerd) лучше, чем решение общего назначения. Для этого я сравнил security related информацию, выдаваемую командами crictl inspect <containerid> и docker inspect <containerid>. По мимо той же прямой связи с ресурсами Kubernetes есть и нформация по capabilities, seccomp настройкам работающего контейнера.

Отдельно советую посмотреть слайды "How Container Runtimes matter in Kubernetes?" про сравнение данных вещей в плане производительности и более новое исследование "Performance Evaluation of Container Runtime".