"Вы еще не читаете Kubernetes Audit Log? Тогда мы идем к вам!" – Алиса Кириченко, Лаборатория Числитель

Мы завершили БеКон 2024. Всем, большое спасибо за участие!

В официальном блоге Kubernetes вышла статья "10 Years of Kubernetes". Тоесть у K8s День Рождение, отсчитывая от первого коммита на GitHub! В статье описаны различные вехи, история и будущее развития. Всем не равнодушным обязательно к прочтению =)

P.S. Если у вас есть вопросы по докладам со вчерашнего БеКон, то пишите их в комментариях к соответствующим слайдам и докладчики ответят на них.

P.S.S. Исторически случайно случилось, что БеКон проходит рядом с ДР k8s - мелочь, а приятно)

В завершение этой недели хотим поделиться статьей – "Six Critical Blindspots While Securing Argo CD". Будет очень актуально, если вы используете (или планируете использовать) ArgoCD в качестве GitOps оператора в своей инфраструктуре.

В статье автор рассказывает о 6 принципах, которым необходимо следовать, чтобы сделать использование ArgoCD максимально безопасным:

1) Use a dedicated project for the control plane
2) Argo resources are for Argo admins only
3) Delete the “default” project
4) Block ClusterRoleBindings in (most) projects
5) Narrow roles on remote clusters
6) Have a CVE response plan ready

Всем, привет!

У нас есть опросник по итогам БеКон 2024 - он лежит здесь. Нам очень важна обратная связь от всех кто участвовал, чтобы следующую нашу конференцию еще лучше. И это не возможно без вашей помощи. Заранее большое спасибо за вашу помощь!

Определенно в следующим году мы немного расширим подход к отбору докладов и можно будет присылать свои заявки ;)

И еще раз всем спасибо, что пришли и поддержали нас на конференции)

Очень хардкорная статья "Flipping Pages: An analysis of a new Linux vulnerability in nf_tables and hardened exploitation techniques" для любителей атак через уязвимости ядра. Примечательна она тем что данный случай рассматривается в рамках KernelCTF (о котором мы не однократно писали и который вышел из kCTF). А также что для успешной атаки тут требуется unprivileged-user namespaces, о котором мы рассказывали в одном из наших докладов на последнем БеКон ;)

Если во время пентеста вы оказались на Node и вам потребовалось собрать данные с etcd, а набирать в консоле kubectl и etcdctl не хочется, то вот этот скрипт может вам помочь.

4 июля в 17:00 в рамках конференции Kuber Conf /24 от Yandex Cloud наша команда Luntry представит доклад "Механизмы Kubernetes против атак supply chain" на треке Безопасность.

Поговорим про проблематику и актуальность Supply Chain, а также рассмотрим как можно защититься от этого встроенными механизмами Kubernetes.

Мероприятие будет доступно как офлайн, так и онлайн. Необходима предварительная регистрация.

Недавно увидели статью "A Guide To Kubernetes Logs That Isn't A Vendor Pitch" в канале нашего хорошего товарища Сергея Солдатова. А сегодня хотим поделиться своими впечатлениями о ней.

На первый взгляд она очень массивная, но на самом деле большую ее часть занимают скриншоты и примеры событий, логов. Но если вы начнете ее читать, то потратите минут 7-10. В начале автор говорит, что нужно собирать логи с 4 уровней:
- Code
- Container
- Cluster
- Cloud

Постоянные читатели нашего канала явно узнают в это "The 4C's of Cloud Native Kubernetes security" ;) Основной ориентир тут на уровень Cluster и естественно главный действующий герой это Kubernetes Audit Log cо своей AuditPolicy. Статья очень общая и каких-то откровений, новшеств там нет ... И честно не очень то и далеко ушла от официальной документации.

Тут бы мы больше рекомендовали посмотреть слайды (видео будет позже) "Вы еще не читаете Kubernetes Audit Log? Тогда мы идем к вам!" – Алиса Кириченко с БеКон 2024.

Сегодня делимся вами слайдами с доклада "PIVOT!" — Bouncing between your app, your cluster and your cloud с прошедшей конференции KCD Zurich 2024.

В докладе автор рассказал о распространненых векторах атак для Managed Kubernetes в EKS, AKS и GKE. О некоторых из них (как и об инструменте MKAT, который упоминается в докладе) мы уже рассказывали на канале [1,2].

Тем не менее, данные слайды можно использовать как cheatsheet с полезными техниками для проведения пентеста в Managed Kubernetes.

Очень хорошая заметка "Stop worrying about ‘allowPrivilegeEscalation’", но с очень противоречивым названием, которое привело к тому, что автору потом пришлось к началу стать добавить еще пояснение.

Материал обязателен к изучению, но не обращайте внимание на название. Также внимания заслуживает и доклад "Латаем огрехи в образах приложений с помощью Kubernetes" с БеКон 2024 нашего коллеги Анатолия Карпенко, где ‘allowPrivilegeEscalation’ также освещается ;)

Всем, привет!

Рады сообщить, что стали доступны фотографии с нашей конференции БеКон 2024!

Taking a look at the Kube-Proxy API – очередная статья от Rory McCune, на этот раз о Kube-Proxy API.

В Kubernetes есть несколько компонентов, которые предоставляют API (например, kube-apiserver или kubelet). Но мало кто знает, что kubeproxy также предоставляет API.

В статье упоминается несколько эндпоинтов, но наиболее интересным выглядит эндпоинт /metrics – в ответе возвращаются prometheus метрики, а также информация о том какие feature gates включены в кластере. Наверняка это будет полезно, если вы исследуете Managed Kubernetes (когда у вас нет доступа к Control Plane).

Тут нельзя не упомянуть доклад "How Attackers Use Exposed Prometheus Server to Exploit Kubernetes Clusters", в котором авторы рассказали какую информацию может извлечь атакующий из торчащих наружу Prometheus endpoints, и как это можно использовать для атаки.

Время идет, а проникновение через публично доступный Docker Engine никуда не девается.

В статье "Attackers deploying new tactics in campaign targeting exposed Docker APIs" разбирается недавняя атака, которая как по мне ничем особо не примечательная. Тут только атакующие написали несколько новых вспомогательных инструментов и все.

Помните, что наружу публиковать Docker API не надо и что на него также можно навесить Policy Engine. Об этом рассказывал Павел Сорокин на БеКон 2023 в докладе "OPA с shared Docker executor".

В продолжение поста про метрики kubeproxy хочется затронуть тему Kubernetes Profiling и вместе с тем заметку из блога Rory McCune "Taking a look at Kubernetes Profiling".

По умолчанию профайлинг включен в kube-apiserver, scheduler, controller-manager и kubelet. Доступ к этой информации можно получить обратившись к эндпоинту /debug/pprof/profile, однако для kube-apiserver, kube-controller-manager и kube-scheduler нужны необходимые права RBAC, тогда как для kubelet любой пользователь, обладающий правами на node/proxy может получить доступ к информации о профилировании. Ранее мы уже освещали какие возможности представляются атакующему с правами nodes/proxy.

Один из наиболее интересных сценариев (с точки зрения безопасности), где можно использовать эту функциональность, раскрывается в случае, когда у пользователя, взаимодействующего с кластером есть возможность просматривать Kubernetes API server logs, поскольку это может позволить ему проэксплуатировать CVE-2020-8561 и начать использовать malicious webhooks.

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.