KubeHound – новый инструмент, который поможет определить вам возможные attack path в вашем Kubernetes кластере.

Принцип работы тулзы довольно прост: сначала KubeHound собирает всю необходимую информацию через Kube API, вычисляет attack paths (Bad Pods, RBAC) от container escape до возможного lateral movement и складывает результаты в графовую БД JanusGraph. Тулза может быть полезна как для Red так и для Blue team – на данный момент инструмент поддерживает около 25 запросов, однако авторы обещают добавлять новые.

Стоит отметить, что инструмент в своём большинстве закрывает только вопросы PodSecurityStandards, и никак не учитывает при построении attack path NetworkPolicy, AppArmor и прочие нюансы, которые могут влиять на конечный attack path.

Для более глубокого погружения рекомендуем ознакомиться со следующими источниками:

- заметка в блоге
- официальный сайт утилиты

На недавно прошедшей конференции по безопасности BalCCon2k23 был представлен доклад "Security in Cloud Kubernetes Services: Attacking and Defending Cloud" (видео) от Miguel Angel Hernandez Ruiz и Marios Kourtesis. Как пишут в описании доклада сами автора: "Our main goal with this presentation is to show some of the most common attack scenarios weaponised by cybercriminals which are affecting Cloud Kubernetes Services. We will also offer some possible controls to mitigate those risks."

По сути же там нет ничего нового и вся его ценности в 2х больших live demo в консоли, где демонстрируется:
1) Побег из контейнера на хост
2) Закрепление в скомпрометированном кластере через использование Static Pod

Если вы абсолютно не имеете представления как это выглядит глазами атакующего, то рекомендуем ознакомиться с данным выступлением. А если вам такое зашло, то рекомендуем вспомнить и этот доклад.

Сегодня мы хотим поделиться с вами записью и слайдами доклада нашей команды Luntry в лице Канибор Сергея "Kubernetes Pentest All‑in‑One: The Ultimate Toolkit" с конференции OFFZONE 2023.

В докладе мы рассказали про docker образ, который призван упростить жизнь при проведении Kubernetes пентеста. Сам образ появился в результате проведения аудитов и обкатан в боевых условиях. В тоже время мы не забыли упомянуть и то, с какими реальными проблемами и ограничениями можно столкнуться при проведении пентеста k8s, а также поделились тем, как эти проблемы можно решить.

Сам образ MTKPI можно посмотреть тут.

P.S – уже думаем над тем как можно прокачать MTKPI ;)

Делали недавно исследовательский проект для клиентов и в процессе него пришлось закопаться в реализацию Default seccomp profile (известно также как SeccompDefault и RuntimeDefault) (последние изменения о нем писали тут 1,2,3,4,5) в Kubernetes. Для этого пришлось почитать исходный код Container Runtime: containerd и cri-o. Соответствующий код можно посмотреть тут:
1) Для containerd
2) Для cri-o
3) Для docker (moby)

Все-таки насколько они по-разному к этому подходят...
Отдельное внимание заслуживает их реализация и отношение к системному (многострадальному) вызову unshare (атаки с его участием 1,2). Но в default его, конечно, там и там нет.

С началом новой недели и читайте исходный код ;)

Наличие действующей Kubernetes Audit Policy и последующий сбор и анализ логов очень важный процесс, но что если в логах будет недостоверная информация?

Автор репозитория как раз постарался выяснить что может быть подделано или недостоверно в журналах аудита Kubernetes. Оказалось, что логи можно довольно легко подделать (поля SourceIP и auditID), если в запросы добавлять некоторые заголовки.

Наверное, самые интересные из них X-Forwarded-For и X-Real-IP. Если злоумышленник знает, что в кластере собираются логи, но в тоже время хочет всё еще оставаться незамеченным, ко всем его запросам к Kube API достаточно добавить эти заголовки, чтобы мимикрировать под реальные сервисы.

Статья "Безопасность K8s: защита кластеров в Сloud Containers от VK Cloud и Luntry" это текстовая версия нашего вебинара (видео тут) совместно с командой VK Cloud. Кому ближе такой формат, то самое время с ним ознакомиться и чуть больше узнать о нашем решение Luntry в том числе ;)

Недавно в официальном блоге Kubernetes вышла заметка "User Namespaces: Now Supports Running Stateful Pods in Alpha!". Это прям обязательно к прочтению, если вы не понимаете зачем и для чего нужен user namespace в Kubernetes!

Краткое резюме:
- Новые изменения вступают в силу с 1.28
- User namespace теперь можно применять не только к Stateless,но и к Stateful микросервисам (по сути теперь Pods может быть с любым типом volume)
- Фич ветку UserNamespacesStatelessPodsSupport переименовали в UserNamespacesSupport (по прежнему в alpha и не включено по умолчанию)
- Для включения все также в спецификации нужно указывать hostUsers: false
- У разработчиков есть мысли включить эту опцию в Pod Security Standards (PSS) и Pod Security Admission (при этом нивелировать часть других параметров, если включен этот)

Для работы этого потребуется:
- Ядро Linux 6.3 и старше
- Если у вас CRI-O c crun, версия первого должна быть старше 1.28.1, а версия второго от 1.9
- Если у вас CRI-O c runс, то поддержки еще нет
- Если у вас containerd, то нужно ждать выхода версии 2.0

В заметке также можно посмотреть demo, в котором показано как эта фича может остановить эксплуатацию CVE-2022-0492.

P.S. Последнее время мы много внимания в постах и в комментариях обсуждаем тему user namespace =)

P.S.S. user namespace благо или нет мы рассмотрим в будущем ;)

В конце сентября, в Шанхае прошла конференция KubeCon China 2023. Один из интересных докладов трека Security – Post-Exploiting a Compromised ETCD - Luis Toro Puig, NCC Group.

В докладе автор рассматривает сценарий, в котором ETCD (контейнер или хост) был скомпрометирован, и рассуждает над тем как далеко может продвинуться злоумышленник. Понимание того, как Kubernetes записывает данные в ETCD, может помочь злоумышленнику подделать данные, внедрить Bad Pods, закрепиться в кластере или даже обойти логику scheduler и ограничения AdmissionController.

Видеозаписи доклада пока что к сожалению нет, а вот слайды можно найти тут.

По сути доклад является логическим продолжением статьи Abusing ETCD to Inject Resources and Bypass RBAC and Admission Controller Restrictions о которой мы писали ранее.

В качестве рекомендации хотелось бы отметить, что хост с ETCD нужно максимально защищать – никто не должен иметь возможности сходить на эту машину, кроме Kube API с сертификатами.

Наша команда Luntry совместно с ребятами из компании «Флант» проведет вебинар «Информационная безопасность Kubernetes-кластеров: иллюзии, угрозы и решения» в эту пятницу 13 в 12:00.

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

Зарегистрироваться на webinar можно тут.

Недавно мой товарищ поднял один достаточно интересный вопрос о решении ServiceMesh Istio, о котором мы с командой ранее даже не задумывались ввиду того что не эксплуатируем данное решения.

И так вопрос и ситуация следующая: Для работы istio-init контейнер, который добавляется во ВСЕ Pods в ServiceMesh, требует NET_ADMIN и NET_RAW capabilities, которые обычно рекомендуется забирать из-за их опасности (пример) ... При этом чаще всего когда системное приложение все же требует таких capabilities оно живет в своем отдельном namespace и его достаточно просто можно добавить в исключение в том же PolicyEngine. Но как вы понимаете в данной ситуации это будет ВЕЗДЕ - во всех namespaces с вашими прикладными микросервисами в ServiceMesh ...

Как с этим живете? Как это контролируете? Как спят ваши безопасники?)

P.S. В последствии я еще заметил, что там же runAsUser: 0, runAsGroup: 0, runAsNonRoot: false
P.S.S. Контролировать это можно, но надо постараться. Пост тут скорее чтобы обратить ваше внимание на эту ситуацию

Exploiting Excessive Container Capabilities – в статье рассматривается концепция возможностей контейнера в Docker и потенциальные риски, связанные с избыточными привилегиями. В ней показывается сценарий, в котором злоумышленник использует capabilities для побега из Docker контейнера и получения несанкционированного доступа к хосту.

В качестве примера, рассматривается кейс, когда у контейнера есть cap_sys_ptrace и host_pid (актуально и для Kubernetes). Автор использует лабу madhuakula, больше известного как создателя Kubernetes Goat, о котором мы писали раньше. Используя сгенерированный через Metasploit reverse shell, он инжектится в нужный процесс и получает root на хосте.

Выдача capabilities очень важный момент в безопасности Kubernetes. Их можно ограничивать и выдавать на уровне YAML манифеста и AppArmor профиля. Если вы делаете это в Kubernetes, то делайте на уровне YAML, как это рекомендуют разработчики Kubernetes.

"The internals and the latest trends of container runtimes (2023)" - очень крутая презентация с лекции Kyoto University! Основное содержимое:
1) Introduction to containers
2) Internals of container runtimes
3) Latest trends in container runtimes

Тут прям все от и до есть! Просто MUST HAVE для изучения!

Тоже самое, но в формате статьи тут.

Некоторое время назад довелось поучаствовать в подкасте "Смени пароль!" в выпуске на тему "Атака на экосистему". Своем мнение про формирование экосистемой безопасности и защиты самих экосистем высказались разные крутые специалисты из разных сфер и компаний, включая нашу Luntry.

Приятного прослушивания!

В конце сентября, в Шанхае прошла конференция KubeCon China 2023. Там ребята из компании Tencent представили доклад "Container Live Migration in Kubernetes Production Environment" (слайды, видео (на китайском)). Доклад на прямую не связан с безопасностью (смотря как посмотреть), но тему поднимает очень интересную и кажущуюся на первый взгляд из какого-то будущего) Но данные ребята у себя в компании в проде это уже воплотили в жизнь! Правда для этого они накостыляли свое, а не то что сейчас внедряют в Kubernetes под названием ContainerCheckpoint feature gate.

Насчет связей с информационной безопасностью постоянные читатели нашего канала явно должны вспомнить про forensic container analysis, как раз на основе этого же механизма. Об этом мы писали уже не раз [1,2,3,4,5]

Нашумевшие уязвимости CVE-2023-44487 и CVE-2023-39325, выявленные в результате самой мощной DDoS атаки на текущий день (398 миллионов запросов в секунду) и обнаруженные в go библиотеках golang.org/x/net и golang.org/x/net/http2 само собой затронули и Kubernetes. Патчи для поддерживаемых версий уже выпущены – 1.25.15, 1.26.10, 1.27.7, 1.28.3 (остальные версии обновления не получили и не получат, так как их поддержка завершена).

В патче был добавлен feature gate – UnauthenticatedHTTP2DOSMitigation (по умолчанию он выключен). Однако, есть ряд оговорок. Во-первых, патч применим только для запросов со стороны неаутетифицированных клиентов. Во-вторых, если перед Kube-API уже установлен L7 балансировщик, то разработчики не рекомендуют включать этот feature gate. Такая же рекомендация распространяется в том случае, если Kube-API запущен в частной, изолированной сети, чтобы избежать снижения производительности для неаутентифицированных клиентов.

Тем не менее проблема для аутентифицированных клиентов остаётся нерешенной. Следить за её решением можно в этой issue.

Недавно на просторах сети наткнулись на занимательную картинку, которая представляет из себя MindMap на тему Supply-Chain Security Assessment. На нее можно достаточно долго смотреть и размышлять: знал ли я о таком, учли ли мы это у себя и чего тут не хватает ... Делая, подобную инфографику, очень сложно не упустить чего-то. Поэтому предлагаем читателям канала подумать и в комментариях написать, что по вашему мнению тут и где еще не хватает ;)

CNCF Kubernetes Policy Working group выпустила новый документ, посвященный политике управления, риска и соответствия, чтобы помочь коммьюнити узнать, как лучшие практики Cloud Native могут быть использованы для устранения ключевых бизнес-рисков.

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

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

Хоть нашей команде OWASP Kubernetes Top 10 и не понравился (об этом мы писали тут и тут), но статья "OWASP Kubernetes Top 10: A Comprehensive Guide" по ней выглядит внушительно и с рядом хороших картинок.

Уже меньше, чем через месяц - 14-15 ноября в Москве пройдет SOC-Forum 2023. Наша команда Luntry представит там 2 доклада:
1) «SOC в контейнерах»

Рассмотрим новые вызовы для взаимодействия Security Operations Center (SOC) с высоконагруженными контейнерными окружениями под управлением Kubernetes. Ведь далеко не все SOC готовы к работе с динамическим окружением, у которого своя специфика и особенности.

2) «EDR vs Containers: актуальные проблемы» совместно с Владиславом Лашкиным (4RAYS) из ГК SOLAR

Расскажем все о runtime защите для контейнеров и поможем слушателям узнать о самых важных моментах и тонкостях темы. Ведь контролировать происходящее внутри контейнеров очень важно — и при этом очень непросто. Для примера мы возьмем представителя сигнатурного детекта Falco и покажем как можно оставить его в не удел, а также решения что базируются на нем (Sysdig Securie, StackRox) и вообще подсветим проблемы сигнатурного обнаружения в Linux средах.

The Secrets Store CSI Driver позволяет Kubernetes монтировать множество секретов, ключей и сертификатов, хранящихся во внешних хранилищах секретов корпоративного уровня, в свои Pods в виде Volume.

Что интересно – этот проект от сообщества Kubernetes SIGs. Разворачивается как DaemonSet и использует несколько CustomResources.

Из коробки доступен функционал Secret Auto Rotation (альфа фича, выключена по дефолту) и поддерживаются такие провайдеры как Vault, Azure, GCP и AWS. Также есть возможность делать Sync as Kubernetes Secret.

Когда-то мы уже упоминали данный проект, но только вскользь.

P.S. – Использует уже кто? Способен Vault подменить ?)

"Netassert v2: Network Security Testing" - инструмент динамического тестирования работы сетевых политик (NetworkPolicy) в Kubernetes.

Для этого необходимо описать какое взаимодействие, между кем вы хотите протестировать. Далее движок, используя ephemeral container, инжектит свои образы в тестируемый/е Pods и запускает сканирование с попыткой подсоединиться.

Достаточно оригинальная идей использования ephemeral container ) В Prod окружении я бы не стал такое гонять, но вот как механизм тестирования и описания тестов для разработчиков в stage окружение рассмотреть можно.

Данный инструмент определенно напоминает другой заброшенный инструмент illuminatio.