В начале новой недели с удовольствием поделимся с вами слайдами с выступления "ZeroTrust в Kubernetes:Не пустые слова" нашей команды Luntry с одного из последних мероприятий!

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

Всем хорошей недели!

m9sweeper – OpenSource Kubernetes security платформа (а по факту интерфейс над несколькими проектами).

На данный момент закрывает следующие потребности и выводит результаты и графики по:

- Image scan (trivy)
- K8s CIS benchmark (kube-behch)
- K8s templates best practice (kubesec)
- PolicyEngine (OPA Gatekeeper)
- K8s pentest (kube-hunter)
- Runtime (Falco)

Если вы только начинаете строить защиту для своего небольшого кластера, скорее всего тулза будет полезна. Также может подойти и тем, кто любить городить свои огороды из разных инструментов - тут как раз такая сборная солянка. И да, OpenSource не значит бесплатно.

Исследователи из компании Quarkslab запустили цикл статей реверс Windows контейнеров и выпустили первую часть "Reversing Windows Container, episode I: Silo". Скорее всего 98% читателей данного канала врятли это пригодится в работе ... Но на наш взгляд концепция контейнеров будет развиваться активно и в ОС Windows, тем более с учетом активного развития в ней Windows Subsystem for Linux (WSL) картинка будет получаться очень интересная. Скорее всего все придет в итоге к гибридным системам совмещающем в себе лучшее из двух миров.

Так что познакомиться с данным циклом статей будет как минимум полезно ради общего развития (реверсерам так обязательно, это будет использовать малварь для обхода антивирусов и EDR - о таком уже писали тут). С французами из Quarkslab доводилось общаться на конференциях - крутые и материалы делают такие же.

Вчера для CNI Cilium вышло три CVE:

1) CVE-2023-41332 (DoS via Kubernetes annotations in specific Cilium configuration)
2) CVE-2023-39347 (Kubernetes users may update Pod labels to bypass network policy)
3) CVE-2023-41333 (Bypass of namespace restrictions in CiliumNetworkPolicy)

Две из трёх уязвимости позволяют злоумышленнику при определённых условиях обойти ограничения NetworkPolicy – причем как нативной (которую реализует сам Cilium), так и кастомной от Cilium.

Официальный патч с фиксом данных уязвимостей вышел две недели назад. Поддерживаемые версии с исправленными багами:

- 1.12.14
- 1.13.7
- 1.14.2

Из статьи "Making Sense Out of Native Sidecar Containers in Kubernetes" вы узнаете как прям по шагам изменяется возможность/последовательность запуска и завершения контейнеров в Pod с учетом появления нового "типа" контейнеров, как sidecar (по сути нативная поддержка такого паттерна на базе init), в Kubernetes 1.28.

P.S. Визуализация данного процесса это отдельный вид искусства - Иван молодец ;)

Как правило, для уменьшения поверхности атаки и в целом для уменьшения размера образа используют distroless image. В таких образах нет ничего лишнего – только полезная нагрузка.

Но если всё таки появилась необходимость проверить сетевое взаимодействие (health check probe) изнутри такого контейнера – LProbe будет очень кстати. Для этого в Dockerfile нужно добавить строчку вида:

COPY --from=ghcr.io/fivexl/lprobe:0.0.6 /lprobe /bin/lprobe

И в K8s манифесте добавить exec для readiness и liveness probes:

command: ["/bin/lprobe", "-port=8080", "-endpoint=/readiness”]

P.S – Мы уже как-то рассказывали про инструменты, которые могут пригодится при работе с distroless контейнерами – один из таких Dive.

"Escaping the Google kCTF Container with a Data-Only Exploit" - классная демонстрация Data-Only эксплоита (это очень не простой и достаточно редкий трюк) для побега из контейнера в рамках Google kCTF! В качестве подопытного взята бага в многострадальном io_ring )

Любителям хардкора премного рекомендуем =)

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]