Третья часть [1,2] по мыслям о сканирование образов (images) контейнеров.

Во второй части мы говорили о мифах, недостатках и проблемах инструментов данного класса. Сейчас рассмотрим, как же всё-таки можно улучшить данную картину. Основная проблема как мы уже выяснили это количество "шума", которое генерируют данные инструменты.

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

Лучше идти по пути уменьшения количества данного "шума". И в первую очередь это будет связано не с внедрением каких-то других решений по безопасности, а с культурой разработки продукта внутри вашей компании (это вам никто не продаст в виде готовой коробочки).

1) Культура ведения кода - отдельная большая область, которая покрывает темы от монорепов до использования сторонних библиотек во внутренних репозитариях (а не выдирать уязвимые куски кода и вставлять в свой проект). Общая цель которой это упростить автоматическим средствам анализа поиск недостатков.
2) Distroless images - убрать дистрибутив с кучей его бинарей, библиотек из image. Дает сразу море преимуществ - тут и размер образа уменьшается, и attack surface уменьшается, уменьшается и возможности атакующего, что попадет внутрь такого контейнера, так и "шум" уменьшается. Общая цель убрать, то, что не используется, чтобы уменьшить от них “шум”.
3) Оптимизированный порядок слоев в образе - слои в образе должны быть от более толстых, к более тонким (к часто обновляемым). Общая цель которой это упростить и ускорить автоматическим средствам анализа поиск недостатков.

Ну и на последок можно рассмотреть честный Shiftleft security подход - на пример, это умеют некоторые решения класса SCA (Software Composition Analysis).

Блогпост с детальным обзором CVE-2020-8566 про утечка Ceph RBD Admin secrets через логи при loglevel >= 4. Напомним, что недавно было обнаружено 4 уязвимости в Kubernetes примерно одной сути и содержания - утечки secret данных при включенном подробном логировании. У атакующего должна быть возможность читать данный лог.

Четвертая часть [1,2 ,3] по мыслям о сканирование образов (images) контейнеров.

Сегодня предлагаю посмотреть очень детальное и внушительное исследование от стороннего исследователя. Он написал серию статей по данной теме:
1) Testing docker CVE scanners. Part 1: false negatives and what they mean for your security
2) Testing Docker CVE Scanners. Part 2: How good is package detection?
3) Testing docker CVE scanners. Part 2.5 — Exploiting CVE scanners
4) Testing Docker CVE scanners. Part 3: Test it yourself / Conclusions

Для повторения экспериментов автор сделал доступным репозитарий со своими скриптами и данными.

Полностью согласен с выводами автора. Приятно видеть, что я не одинок в своих оценках и выводах.

Отличная заметка "When LIST is a Lie in Kubernetes", рассказывающая о том, что к содержимому ресурсов secrets можно получить и без GET, а только лишь с помощью LIST. При этом всем данная особенность работы в Kubernetes документирована: "For these reasons watch and list requests for secrets within a namespace are extremely powerful capabilities and should be avoided, since listing secrets allows the clients to inspect the values of all secrets that are in that namespace. The ability to watch and list all secrets in a cluster should be reserved for only the most privileged, system-level components."

Так что если вы хотите кому-то (аудиторам, сканерам или т.д.) ограничить доступ к secrets с помощью LIST, то этого не происходит.

Сегодня еще отдохнем немного от темы сканирования образов (думаю еще 1-2 поста и я закрою данную тему).

Сейчас мы поговорим о Static Pods.

Это Pods, которые управляются не через Kubernetes API server, а kubelet на самой Node. В основном это нужно для служебных задач кластера, на пример, бустрапа чего-либо. Подробнее о них можно почитать в документации. Для запуска таких подов достаточно расположение YAML файл с описанием Pod по определенному пути и указанием на него в `kubelet.

Но это также очень полезная штука и для атакующих (недобросовестных сотрудников и т.д.), которые проникли на Node тем или иным способом (вариантов и способов хватает). Просто authentication token от kubelet атакующему может не хватить - на пример, чтобы создать Pod в kube-system namespace. Что делать? Выход: пойти в обход Kubernetes API server, с помощью Static pod ;)

Пятая часть из цикла [1,2,3,4] сканирования образов.

Сегодня речь пойдет про создание минимального docker образа. Есть замечательная серия постов (+ код) на эту тему под названием "The Quest for Minimal Docker Images". Сам автор об этом пишет так: "We’re going to review a number of techniques to reduce image size, without sacrificing developers’ and ops’ convenience." С уменьшением размера выкидывается все (или почти все) ненужное и сканеры образов начинают меньше шуметь + маленький размер образов для хранения.

1) Первая часть про multi-stage сборку.
2) Вторая часть об особенностях работы с различными языками Go, Java, Node, Python, Ruby, Rust и о Alpine образе.
3) Третья часть покрывает различные паттерны и анти-паттерны при работе с ЯП, фреймворками. А также использование Bazel, Distroless, DockerSlim, UPX.

Маленький комментарий о статической линковке - перед ней сканеры образов просто слепы - не забывайте об этом.

В итоге если вы по тем или иным причинам не можете использовать Distroless подход, вы можете прийти к концепции golden-image (минимального, хорошо проверенного, эталонного и т.д.) для своих команд.

Red Kube или Red Team KubeCTL Cheat Sheet - набор kubectl команд (27 штук), полезных при пентесте/аудите, и две лабы, где их можно все попробовать. Отдельно стоит отметить, что все команды автор разбил на категории в соответствии с матрицей MITRE ATT&CK. Так что это все очень хорошо классифицировано (особенно для начинающих). Но важно не забывать, что чтобы данные команды успешно выполнились у атакующего должны быть соответствующие права в системе. На пример, через скомпрометированный token полученный тем или иным образом.
Так же по мне использовать в атаке приносной бинарь kubectl - очень заметно, даже если переименовав, тем самым сбив детект у части решений по безопасности. Лучше curl (он, кстати, требуется для части этих команд), но он еще должен находится в образе – иначе тоже его нужно будет нести с собой.

Среди возможных сертификатов по Kubernetes от The Linux Foundation пополнение - CKS (точнее должен появится вот-вот до KubeCon + CloudNativeCon North America Virtual). Таким образом будет доступно 3 сертификата

- Certified Kubernetes Application Developer (CKAD) - для разработчиков.
- Certified Kubernetes Administrator (CKA) - для администраторов.
- Certified Kubernetes Security Specialist (CKS) - для специалистов по безопасности.

Для получения последнего необходимо также иметь сертификат CKA.

Учебный план сертификации по темам:
1) Cluster Setup (10%)
2) Cluster Hardening (15%)
3) System Hardening (15%)
4) Minimize Microservice Vulnerabilities (20%)
5) Supply Chain Security (20%)
6) Monitoring, Logging, and Runtime Security (20%)

Кто-то уже даже под это сделал симулятор экзамена и продает.

Недавно наткнулся на репозитарий с правилами детектов для Elastic Security Solution (развитие или дополнение ElasticSearch). Среди правил, там есть правила для AWS, Azure, GCP в соответствии с матрицей ATT&CK. Честно говоря, про Kubernetes там нет ничего. И мое внимание это привлекло лишь потому, что можно провести параллели с Falco, который также работает на основе правил (правда которые вы же и должны предварительно адаптировать под себя).

В правилах от Elastic Security Solution мне очень понравилось и позабавило поле false_positives. Понравилось тем, что авторы вообще проработали этот момент и сделали для этого хорошее описание, а позабавило что это поле есть наверно у 99% всех правил. При этом эти правила в основном для детектирования каких-то инфраструктурных вещей, что на мой взгляд определенно имеет право на существование.

А вот второй момент по детектированию аномального поведения тут реализован отлично, от того, как это сделано в Falco (в нем надо собственноручно описать нормальную модель поведения и поддерживать ее). Здесь используется отдельная категория для таких вещей как ML - machine learning. Насколько это качественно работает сказать абсолютно невозможно и единственный механизм влияния тут это численное поле anomaly_threshold. Что говорит нам о использовании нейронных сетей. При разработке своего детектора аномального поведения приложений в Kubernetes, мы также проводили эксперименты с нейронными сетями и пришли к выводу что основная их проблема это не возможность объяснить на основании чего было принято то или иное решение оператору и в случае false positive необходимость полного переобучения сети. Так что, меняя значение anomaly_threshold остается просто ждать какой-то магии и конечный результат вы вряд ли поймете.

В процессе, подготовки доклада по теме побега из контейнеров в 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