Тем временем, в ArgoCD нашли критическую уязвимость (9.1 по CVSS) CVE-2024-31989: Use of Risky or Missing Cryptographic Algorithms in Redis Cache, эксплуатация которой не требует особых привилегий и может привести к полному захвату Kubernetes кластера.

Исследователей нашедших уязвимость, заинтересовал Redis, который деплоится в кластер при установке ArgoCD, а точнее возможность подключения к нему (из любого Pod) без необходимости указывать username и password. Там они обнаружили множество ключей, которые содержали данные о развернутых приложениях. Однако ключи были сжаты в формате gzip. В документации говорится, что Redis служит в качестве кэширующего слоя, уменьшая количество запросов, отправляемых к Kube API и Git-провайдеру.

Используя исходный код ArgoCD в качестве образца, ресерчеры написали код на Go для распаковки содержимого gzipped и раскрытия его значений. Как и ожидалось, в ключах была закэширована информация о приложениях, управляемых ArgoCD, включая их манифесты и сведения о кластере Kubernetes.

Однако, для того чтобы заставить ArgoCD задеплоить манифесты, доставленные через Redis, нужно было также добавить ключ с контрольной суммой. К счастью исследователей, этот хэш генерировался без какой-либо секретной подписи и им с легкостью удалось его воспроизвести (base64 encoded FNV64a). Как итог, добавив пару ключей в Redis им удалось задеплоить BadPods и получить реверс шелл, сбежав на Node.

Уязвимость затронула все версии ArgoCD, необходимые патчи доступны в версиях 2.11.1, 2.10.10, 2.9.15, 2.8.19. В качестве основной меры митигации можно рассмотреть использование NetworkPolicy для ограничения общения с инстансом Redis.

P.S. Более подробно об уязвимости можно почитать в этой статье.

Практически через месяц - 26-27 июня пройдет вторая самостоятельная двухдневная конференция CloudNativeSecurityCon. Сейчас стало доступно ее расписание, с которым рекомендуем ознакомиться - там много всего интересного (чтобы быть в тренде). И что приятного можно найти параллели с докладами с нашим небольшим, ламповым БеКон)

В глаза бросаются темы про runtime security, безопасность на базе service mesh и внимание к Linux user namespace.

AWRBACS – очередной инструмент для анализа RBAC в Kubernetes.

Со слов автора, AWRBACS создан не для того, чтобы заменить rakkes, kubectl-who-can или другие инструменты и плагины для анализа RBAC в Kubernetes, а, скорее, для их дополнения.

Инструмент позволяет смотреть права для конкретного пользователя в кластере, указать Service Account или запустить автоматическую проверку по всем субъектам в кластере. Также автор реализовал проверку прав у пользователей, добавленных через кастомные вебхуки для авторизации (Keycloak, LDAP, IAM). Если такой механизм будет действовать в кластере, то встроенные механизмы k8s, на примере, kubectl auth can-i могут работать некорректно (про это можно почитать в одном из наших предыдущих постов).

Более подробно о самом инструменте можно почтитать в заметке автора.

В этом году наша команда Luntry на мероприятии PHDays Fest 2 представила исследование «Кубик Runtime в конструкторе Kubernetes для безопасности». В рамках доклада были рассмотрены такие инструменты/механизмы как Sandbox/AppKernel, microVM, WASM, Sandbox API, Confidential Containers.

Сейчас уже доступны и слайды и видео.

В комментариях будем рады ответить на любые вопросы по данной теме.

Осталось 1 неделя до БеКон 2024. И у нас сформировался новый стикер пак! Он будет роздан всем участникам!

Последние билеты можно взять тут.

P.S. Увидимся уже совсем скоро ;)

Сегодня хотим поделиться инструментом k8spider, который был вдохновлен dnscan, используемый в заданиях на Kubernetes LAN Party.

Тулза будет полезна при разведке, когда находясь внутри скомпрометированного Pod, нужно понять какие сервисы есть еще в Kubernetes кластере. Есть поддержка Service ip-port BruteForcing / AXFR Domain Transfer Dump / Coredns WildCard Dump.

#tools

root@pod:/var/www/html/tools# env |grep KUBERNETES
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT_443_TCP=tcp://10.43.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_ADDR=10.43.0.1
KUBERNETES_SERVICE_HOST=10.43.0.1
KUBERNETES_PORT=tcp://10.43.0.1:443
KUBERNETES_PORT_443_TCP_PORT=443
root@pod:/var/www/html/tools# ./k8spider all -c 10.43.43.1/24
INFO[0000] PTRrecord 10.43.43.87 --> kube-state-metrics.lens-metrics.svc.cluster.local. 
INFO[0000] PTRrecord 10.43.43.93 --> metrics-server.kube-system.svc.cluster.local. 
INFO[0000] SRVRecord: kube-state-metrics.lens-metrics.svc.cluster.local. --> kube-state-metrics.lens-metrics.svc.cluster.local.:8080 
INFO[0000] SRVRecord: metrics-server.kube-system.svc.cluster.local. --> metrics-server.kube-system.svc.cluster.local.:443 
INFO[0000] {"Ip":"10.43.43.87","SvcDomain":"kube-state-metrics.lens-metrics.svc.cluster.local.","SrvRecords":[{"Cname":"kube-state-metrics.lens-metrics.svc.cluster.local.","Srv":[{"Target":"kube-state-metrics.lens-metrics.svc.cluster.local.","Port":8080,"Priority":0,"Weight":100}]}]}

После поста про сетевые атаки, должен быть пост про сетевую защиту)

Недавно вышел хороший лонгрид "Cilium: Network Policies". Достаточно простым языком рассказывается как устроены сетевые политики, какие они бывают и как с ними работать. Все, конечно, на примере кастомных политик Cilium. Очень наглядно продемонстрирована такая важная сущность в Cilium как Security Identities, вокруг которой крутиться вся работа NetworkPolicy (а про его проблемы мы писали тут и тут). Также, интересно показан и раскрыт момент с DNS Traffic Visibility. Все остальное достаточное простое и очевидное, но хорошо проиллюстрировано. Так что все новичкам этот материал строго рекомендуется.

Сегодня мы рады анонсировать последний доклад в нашей программе БеКон 2024.

Это будет доклад "Вопросы сертификации системного программного обеспечения" от начальника 2 управления ФСТЭК России Дмитрия Шевцова про сертификацию операционных систем, средств контейнеризации, средств виртуализации и систем управления базами данных. Поговорим про историю, развитие и будущее данного момента. Конечно, будет затронут 118 приказ про "Требования по безопасности информации к средствам контейнеризации".

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

Финальное расписание можно посмотреть на сайте. Билеты еще можно взять, на входе они продаваться не будут!

Увидимся уже совсем скоро =)

Завершить эту неделю хотим докладом с Kubecon North America 2021 – "Kubernetes Exposed! Seven of Nine Hidden Secrets That Will Give You... Ian Coldwater & Brad Geesaman". Спикеры представили несколько интересных приемов, которые могут быть полезны при проведении пентестов.

Наше внимание приковал трюк с обходом Policy Engine – для того чтобы его повторить атакующий должен иметь права на создание Pods и Services с External IP.

Для начала необходимо создать Deployment с nginx и Service с External IP с выставленными Pod IP и Service IP от Kyverno. Суть атаки состоит в том, чтобы заскейлить nginx до 2 реплик, попробовать создать Pod в обход политики Policy Engine и заскейлить nginx до 3 реплик, а после опять до 2. Это необходимо для того чтобы заставить kube-proxy сбросить iptables и увеличить шансы на деплой в обход политики Policy Engine.

Через какое-то время Kyverno попадает под Leader Election и вырубается, в этот момент создается Bad Pod.

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

Мы решили проверить и воспроизвести трюк с обходом Policy Engine из прошлого поста и рассказать как обстоят с этим дела в 2024 году (прошло 3 года с момента выхода доклада).

Авторы в докладе упомянули, что этот трюк позволяет обойти любой Policy Engine движок. На Kyverno, при отсутствии enforce политики на создание Service с ExternalIP, действительно получается сложить вебхук и как следствие забайпасить любую политику, а вот с OPA Gatekeeper такого не происходит.

Начиная с версии Kyverno 1.11 была добавлена поддержка механизма API Priority And Fairness, который позволяет избежать таких ситуаций.

Наша конференция уже совсем скоро и мы хотим попросить вас немного накидать нам бустов https://t.me/boost/k8security , чтобы мы могли более интересно и активно передавать новости с мероприятия для всех кто не может на нем присутствовать.

Заранее всем большое спасибо!

Вроде все красиво и правильно на данном скриншоте ... НО есть один нюанс)

Ответ, на него с разъяснением вы можете получить из полезного выступления "Least Privilege Containers: Keeping a Bad Day from Getting Worse" c Kubecon 2023 от инженеров Google.

Ответ: это не будет работать из-за сочетания не root пользователя и дополнительной capability.

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

Уже завтра состоится наша конференция, времени осталось совсем немного!

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

Для все кто не сможет быть на площадке мы будем делиться атмосферой в историях и оперативно выкладывать слайды здесь на канале. При этом в комментариях к постам вы можете задавать свои вопросы и после выступлений докладчики на них ответят!

"Почему защитой k8s должно заниматься целое подразделение?" – Артем Мерец, Tinkoff

"Латаем огрехи в образах приложений с помощью Kubernetes" – Анатолий Карпенко, Luntry

"Мечтают ли антивирусы о docker-образах?" – Владимир Капистка, samokat. tech

"Все ли Service Mesh одинаковы полезны для ИБ?" – Максим Чудновский, СберТех

"От стандартных к нестандартным методам управления секретами в контейнерах" – Валерий Кунавин

"Linux user namespace в чертогах Kubernetes" – Дмитрий Евдокимов, Luntry

"Мультитенантность в Kubernetes: есть ли серебряная пуля?" – Константин Аксенов, Флант

"Строим заборы между сервисами", – Андрей Бойцев, Яндекс Финтех