В процессе, подготовки доклада по теме побега из контейнеров в Kubernetes, открыл для себя такую тему как Node isolation как инструмент реализации security mitigations для определенных угроз. С помощью Node isolation можно разграничивать запуск Pod'ов по Node, группируя их на основании того или иного свойства. Так на пример, можно наиболее критичные сервисы (платежные сервисы, сервисы работающий с пользовательскими данными и т.д.) располагать отдельно от менее критичных (frontend, мониторинг и т.д.) или не доверенных (написанных на аутсорсинге, legacy кода). Или еще сценарий, сервисы с большим количеством известных CVE, отдельно от тех, где данная проблема уже как-то решена.

Все это можно реализовать благодаря:
1) labels и taints - для распределения Pod'ов
2) node authorizer и node restriction - для ограничения выставления атакующим нужных ему labels

На мой взгляд, это отличный инструмент, но требуется предварительно хорошо все продумать, расставить labels (о их важности я уже писал).

Вчера узнал о таком проекте как Open Cloud Security Posture Management Engine (OpenCSPM), который буквально недели 2 назад появился на GitHub. Из описания следует, что это платформа для более глубокого понимания конфигурации и метаданных вашего облака, призванная помочь понять и снизить риски. И заявляется поддержка cloud-native платформ (AWS, GCP) и нативного Kubernetes. Проект также привлек мое внимание ввиду использования графовой БД RedisGraph для анализа.

Посмотрим на поддержку Kubernetes:

1) Для того, чтобы анализировать данные от какой-либо системы для этого нужен loader. В основной ветке k8s_loader.rb пока пустой ...
2) В отдельном репозитарии лежит логика запросов к графовой БД для валидации правил. Запросов к данным k8s нет - достаточно сделать поиск по control_id в виде darkbit-kubernetes-*.
3) В отдельном репозитарии лежит описание проверок с remediation и validation. Вот тут уже информация по k8s есть. И это пока единственное, что имеет смысл посмотреть в данном инструменте.

Шок новость: Идут обсуждения об удалении/отказе (скорее о замене) от Pod Security Policies.

Проблемы PSP:
1) Путаница с привязкой субъектов
2) Проблема дублирования Admission Controllers
3) Отсутствие поддержки альтернативных CRI
4) PSP только для `Pod`s и ничего больше
5) Проблемы с тестированием покрытия PSP

Есть вероятность что от данной реализации откажутся в Kubernetes 1.22.

Обсуждение будущего PSPv2 можно наблюдать в документе "Future of PodSecurityPolicy". Работает над этим группы Sig-AUTH и Sig-SECURITY.

Об одной из перечисленных проблем я уже писал, так как сам недоумевал о причинах такой реализации. И считаю, что замена/переработка PodSecurityPolicy пойдет только на пользу.

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

The Kubernetes Security Profiles Operator - данный проект призван помочь с управлением, распространением и применением таких профилей безопасности как seccomp, AppArmor, SeLinux, PodsecurityPolicy и RBAC.

Проект разрабатывается в рамках Kubernetes Special Interest Group и находиться еще в ранней стадии. Пока есть поддержка только seccomp, который недавно попал в GA. Далее по планам поддержка AppArmor.

Это должно позволить просто и эффективно использовать встроенные механизмы безопасности Linux для обеспечения prevention внутри Pod'ов Kubernetes.

Размышляя о проблемах PodSecurityPolicy и, в частности, о том, что она ограничена только Pod'ами, что в свою очередь позволяет атакующим обходить PSP и совершать побег из контейнера благодаря другим ресурсам (например, PersistentVolumes и его hostPath).

Я пришел к выводу, что подобных сценариев обхода PSP можно поискать и среди других ресурсов и особенно среди CustomResourceDefinition. Сейчас многие делают свои CRD и operator'ы, вообще не задумываясь что с помощью них можно использовать их возможности для зловредных целей. Чтобы кто-то широко занимался аудитом CRD (да и `operator`ов) я пока не слышал.

Это касается не только путей монтирования, но, например, и сетевых взаимодействий. Можно потенциально сделать что-то похожее на CVE-2020-15157, о котором я уже рассказывал. Или устроить DoS, подсунув operator`у специально подготовленный `CRD.

При этом атакующий может очень просто узнать о тех ресурсах, что у вас используются благодаря curl и default service account. Как я уже говорил знание о используемых ресурсах дает много информации при разведке. Отключить данный token можно так.

В ближайшее время думаю будет небольшое затишье по новостям/мыслям/идеям от меня, а потом наоборот много всего интересного. Сейчас активно работаю над двумя выступлениями:
- "Container escapes: Kubernetes edition"
- "Kubernetes: Трансформация к SecDevSecOpsSec"

eBPF Summit 2020 выложил все доклады отсортированные по playlist'ам. Мой личный топ докладов:
- "Safe Programs The Foundation of BPF"
- "bpfbox: Simple Precise Process Confinement with KRSI and eBPF"
- "Building a Secure and Maintainable PaaS"
- "Kubernetes Network Policy Logging with eBPF"
- "Security Auditing and Enforcement using eBPF"

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

DAST operator — это Kubernetes operator, позволяющий реализовывать динамическое тестирование безопасности приложений и его API, на базе бесплатного и открытого решения Zed Attack Proxy (ZAP).

Данный оператор отлично ложиться в концепцию DevSecOps и хорошо смотрится в тестовом кластере при прогонке тестов для сервисов. Архитектурно от состоит из 2 reconcilers (для самого DAST и Services) и validating admission webhook для Ingress. Также для его успешной работы придётся добавить соответствующие annotations в тестируемые ресурсы + описать его собственные CRD.

Делать он сам по себе пока еще не много что умеет, но roadmap выглядит красивым. Честно я рассчитывал найти еще такой же operator на базе BurpSuite, который более любим специалистами по ИБ, но по крайней мере такого в открытом доступе не нашлось.

Сегодня хочется опять поговорить про технологии, которые будут двигать развитие контейнерных приложений и Kubernetes в том числе. Есть замечательный проект, за которым я уже давно слежу - CRIU (Checkpoint/Restore In Userspace). Суть проста, в runtime в необходимых контрольных точках (checkpoint) запоминается состояние программы, далее это состояние может быть перенесено на другую систему и программа возобновит (restore) свою работу с контрольной точки. Я лично слежу за данным проектом из-за таких сценариев его использования как "Applications behavior analysis on another machine" и "Snapshots of apps", что может быть очень полезно для security в том числе.

Проекту недавно исполнилось 7 лет и он постепенно начинает прокладывать себе дорогу в большой мир:
- В ядре 5.9 появилась новая capabilities "CAP_CHECKPOINT_RESTORE"
- В сообществе Kubernetes также работают над внедрением этой возможности во фреймворк

Есть даже PoC реализация PodMigration оператора. С ним можно поработать, но требуются измененные версии Kubernetes API, kubelet и container runtime.

В очередной раз хочется поднять проблему CAP_NET_RAW capability, да и вообще тему дефолтных (тут можно посмотреть их список) и необходимых capabilities. Так как CAP_NET_RAW просто является наиболее ярким примером из тех что есть по умолчанию. С ней появляется целый ряд известных проблем:
- Благодаря CVE-2020-14386 можно сделать container escape
- Возможность проведения MitM атак


Если ваше приложение это не использует, то можно убрать те capabilities что ему не нужны, тем самым уменьшить поверхность атаки.
Для этого в разделе securityContext в секции capabilities можно использовать описания add и drop. На пример:

securityContext:
  capabilities:
  drop:
    - all
  add:
    - NED_BIND_SERVICE

Исследуя тему побега из контейнеров, я не мог не обратить свое внимание и на виртуальные машины (VM), которые можно использовать для запуска OCI образов в Kubernetes. В процессе всего этого, я встретил несколько точек зрения о будущем использования VM в Kubernetes. Кто-то считает, что:
- VM вытеснят контейнеры и те уйдут с передовой.
- такие мысли — это происки разработчиков VM, которые проигрывают на данном рынке.
- они нужны только при условии, что есть multi-tenancy
- они нужны только при определенных требованиях информационной безопасности для решение определенных задач

Естественно, речь идет о легковесных VM, типа:
- Kata containers
- Nabla containers
- Firecracker
- Toro Kernel

Что вы думаете на этот счет ?

CVE-2020-15257: containerd – containerd-shim API Exposed to Host Network Containers

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

Все это возможно в условиях и благодаря, если:
- hostNetwork: true для Pod
- контейнер работает от root
- контейнер работает в host user namespace (сейчас это не исправить, но работа над этим кипит в keps/127: Support User Namespaces)

А проблема крутиться вокруг того, что containerd-shim использует abstract Unix domain sockets, который в отличие от normal Unix domain sockets привязан к network namespace процесса, а не к файлу.

В итоге злоумышленник из контейнера может делать такие операции как:
- Чтение/добавление/запись произвольного файла хоста
- Выполнение произвольных команд в контексте containerd-shim (root) на хосте
- Создание и запуск контейнера из runc config.json файла
Это, конечно, более чем достаточно для совершения побега из контейнера на хост.

Сегодня поговорим о таком стандартом ресурсе Kubernetes как RuntimeClass.

Благодаря данному ресурсу можно назначать на каком container runtime будет исполняться тот или иной Pod. Да все так - на вашем кластере моет одновременно существовать несколько container runtime.

Данный тип ресурса пришел на смену sandboxed runtime (описанию в annotations) и как пишут его авторы в KEP: "These implementations could stick with scheme ("trusted" and "untrusted"), but the preferred approach is a non-binary one wherein arbitrary handlers can be configured with a name that can be matched against the specified RuntimeHandler."

Это можно использовать для запуска специфичных подов. На пример, можно использовать gVisor, firecracker, kata или любой другой CRI runtime с более сильной изоляцией, чем у шустрого runc для запуска Pod'ов:
- не доверенных
- подозрительных
- сторонних разработок
- не прошедших pentest или аудит безопасности
- с большим количеством уязвимостей в image

Недавно опубликовали CHANGELOG для Kubernetes v1.20.0-rc.0.

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

1) В v1.20.0-alpha.0: __"Dockershim security: pod sandbox now always run with no-new-privileges and runtime/default seccomp profile dockershim seccomp: custom profiles can now have smaller seccomp profiles when set at pod level"__ и __"Kuberuntime security: pod sandbox now always runs with runtime/default seccomp profile kuberuntime seccomp: custom profiles can now have smaller seccomp profiles when set at pod level"__
2) А уже в `v1.20.0-beta.1`: __"Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available."__


Касаемо Kuberuntime security все отлично теперь Pod будет по умолчанию подтягивать "runtime/default" для seccomp. Но улучшать dockershim security и затем деприкейтить его по мне странно). Сам деприкейт dockershim логичен и обоснован.

Также касаемо безопасности fsGroupChangePolicy (часть securityContext) поднялось в стадию beta. Имеет значения OnRootMismatch и Always (по умолчанию).

Аудиторам/пентестерам на вооружение, а защитникам (Blue team, DevSecOps) на заметку.
Щит и меч как известно две стороны одной медали.

Рассмотрим сегодня классную технику побега из контейнера или, с другой стороны, очень опасную конфигурацию workload.
Если внутрь Pod смонтирована директория /var/log и атакующего есть ServiceAccount token на чтение nodes/log, то он может общаться в Kube API Server, используя этот token. Он может считать все данные с файловой системы Node на которой работает Pod из которого он шлет запросы.

В проекте kube-pod-escape автор реализовал полностью подобную ситуацию и еще 3 полезные команды для проведения самой атаки:
- lsh - аналог ls, для работы из контейнера на хосте
- cath - аналог cat, для работы из контейнера на хосте
- find_sensitive_files.py - считывает с хоста критичные файлы типа private keys и других ServiceAccount token

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

"Kernel privilege escalation: how Kubernetes container isolation impacts privilege escalation attacks"

Отличная статья, наглядно демонстрирующая чем отличается работа kernel privilege escalation эксплоита в не контейнера для поднятия привилегий и в контейнере для побега из контейнера. Для примера в статье взята CVE-2017-7308 (опять привет CAP_NET_RAW capability).

Наглядность заключается в том, что автор с помощью отладчика показывает, какие и почему структуры данных необходимо модифицировать для успешной эксплотации. Вы познакомитесь тут и с дефолтным root'ом и с различными namespaces (ОС, а не Kubernetes - не путайте их) и ,конечно, capabilities.

А напоследок увидите как даже дефолтный seccomp профиль, способен сделать не пригодным данную технику эксплотации.

P.S. Статья является такой прям квинтэссенцией моей любви к бинарной эксплотации и безопасности `Kubernetes` =)

CVE-2020-8554: Man-in-the-middle using LoadBalancer or ExternalIPs

Почитав описание многие из вас, могут задаться вопросом: "Правда CVE??!".

Суть в том, что LoadBalancer делает то, для чего и предназначен. Ему указали IP для LoadBalancer и бэканда - он и использует их, не проверяя и не зная о допустимых значениях. А так автор PoC предлагает использовать данное свойство для использования LoadBalancer как MITM инструмент, указывая на свой подконтрольный Pod. Такое свойство известно с 2016 года если что. Все детали данного поведения/проблемы можно прочитать в этом коротком и емком треде. А проблема как всегда может быть решена с помощью admission controllers ;)

Так что не пугайтесь описание в конце паспорта уязвимости: "This issue is a design flaw that cannot be mitigated without user-facing changes."

В связи с новостью об удалении/отказе/замене от Pod Security Policies и анализом последних уязвимостей, атак, в голове образовалась следующая параллель с развитием методов атак и защит из мира бинарной эксплуатации (скорее всего большинство далеки от данной темы, но я надеюсь мысль уловите).

Сначала для перехвата потока управления программы атакующие влияли тем или иным способом на Код. Чтобы это предотвратить Код обложили большим количеством механизмов безопасности типа DEP/SEHOP/ASLR/CFG/PAC/.... В итоге, были придуманы так называемые Data-Oriented Attacks, Data-only Attacks - они в свою очередь помогали перехватить поток управления не через влияния на Код, а Данные. Защиты от таких атак можно встретить только в академических работах, ввиду большого overhead'а и ряда других ограничений. При этом Данные как вы понимаете у каждой программы различаются очень сильно - нельзя стандартизировать.

Вот так же и с PodSecurityPolicy. Он был заточен только под контроль workload (Pod'ов). А в итоге, атакующий может сделать много всего “интересного” и без влияния на сущности, представляющие workload'ы - через kubernetes ресурсы чисто описывающие некоторые настройки. Тут примеры и с `PersistentVolumes и с LoadBalancer и т.д. Но ввиду что эти ресурсы (Данные и все есть `YAML) стандартизированы и есть как минимум такой механизм как Admission Controller это все можно проверять перед применением. На лицо преимущество декларативной системы и подхода Something as Code в целом.

Service Mesh сети очень часто (когда это нужно и выгодно) выставляют и позиционируют как отличный механизм безопасности. Хотя на мой взгляд это наверно самая слабая их функциональность. И давно эта мысль крутилось у меня в голове, но не знал как это правильно написать и тут наткнулся на цитату с которой полностью согласен и отражает всю суть: "Because service mesh network policies are defined at the service level, they are not effective at protecting your underlying infrastructure from a compromised pod." от Liz Rice

"ABSTRACT SHIMMER (CVE-2020-15257): Host Networking is root-Equivalent, Again" - отличный технический рассказ с примерами кода о том, как находилась, исследовалась уязвимость CVE-2020-15257, о которой я писал раньше.

При прочтении вы узнаете о том, как работает containerd-shim, как закрыли данную уязвимость и как ее можно проэксплуатировать. Сам исходный код эксплоита автор собирается выложить 11 января, НО по статье его можно написать и самостоятельно.