k8s (in)security

Исследователи из Orca Research Pod обнаружили опасную мисконфигурацию в GKE, которая может позволить злоумышленнику с любой учетной записью Google взять под контроль неправильно настроенный кластер Kubernetes, что потенциально может привести к серьезным инцидентам безопасности, таким как криптомайнинг, отказ в обслуживании и кража конфиденциальных данных.

Мисконфигурации дали название Sys:All ввиду вероятного широко распространенного заблуждения, что группа system:authenticated в GKE включает только проверенные и детерминированные идентификаторы, тогда как на самом деле она включает любую аутентифицированную учетную запись Google (в том числе за пределами организации).

По минимальным оценкам, ресерчеры обнаружили 250 000 активных кластеров GKE, сотни из которых содержали секреты, позволяющие осуществлять lateral movement и получать доступ к конфиденциальным данным. Подробнее об этих случаях можно почитать здесь.

Kyverno, в свою очередь, оперативно выпустила политику, закрывающую этот мисконфиг.

Исследователи из Wiz опубликовали базу данных инцидентов Cloud Security – Cloud Threat Landscape!

Изначально, база была исключительно внутренней, создавалась для аналитики угроз и поддерживалась собственными силами. Однако, эту кладезь знаний решили опубликовать. База содержит в себе более 100 задокументированных инцидентов в области Cloud Security, профили злоумышленников, используемые ими инструменты, техники и маппинг на Mitre Tactic.

Кстати говоря, если верить этой базе, то Kubernetes является most targeted технологией из всех представленных там.

Несомненно, этот ресурс будет полезен Threat Intelligence специалистам, изучающих Cloud Threats, SOC аналитикам, и в целом всем, кто погружен в тему Cloud Security.

4 марта в Москве в рамках DevOpsConf 2024 наша команда Luntry выступит с докладом "Безопасность Kubernetes кластеров: Вредные советы".

У всех у нас есть какой-то опыт, и мы всегда стараемся переносить его с собой повсюду. Так, на пример, велик соблазн перенести свой опыт обеспечения безопасности Linuх/Docker инфраструктур (не говоря уже о Windows) на Kubernetes кластера. При этом, к сожалению, до конца, не понимая самой природы Kubernetes. И это может быть ваш личный опыт или опыт кого-то из коллег, которые писали корпоративный стандарт с “лучшими практиками” по безопасности в Kubernetes, а вам ему уже необходимо следовать ... К сожалению, то, что работало раньше и где-то очень полезно, на практике не эффективно, бесполезно или вообще может привести к печальным последствиям.

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

И в рамках этого проведем конкурс и разыграем 1 проходку на конференцию. Для этого в комментариях к этому посту напишите какие самые странны, бесполезные, смешные требования вы встречали в процессе работы в корпоративных стандартах, ТЗ и т.д. по теме безопасности контейнеров, Kubernetes, DevSecOps =) Через неделю мы выберем победителя!

P.S. И для все у нас есть еще специальный промокод со скидкой 5% - k8security

В последнем релизе Kyverno 1.11 компания Nirmata, помимо обновленной версии, представила также инструмент для тестирования Kubernetes операторов – chainsaw.

Изначально, в качестве инструмента для тестирования Kubernetes opertator использовался KUTTL, но довольно быстро разработчики столкнулись с рядом ограничений и нехваткой нужного функционала. Так и появился chainsaw.

Chainsaw предоставляет декларативный подход к тестированию операторов и контроллеров Kubernetes. Это значит, что само наполнение тестов описывается тоже декларативно, с помощью YAML.

Помимо этого, chainsaw может встраиваться в пайплайн, что несомненно является плюсом.

Перед прочтением новой статьи "Better Together: Real Time Threat Detection for Kubernetes with Atomic Red Tests & Falco" у нас были (хоть и маленькие) надежды на что-то интересное, но они были быстро развеяны ...

Что можно узнать из статьи:
1) Как Atomic Red Team запустить в виде Kubernetes Deployment manifest
2) Чтобы не отставать от атакующего нужно постоянно писать свои правила: "revising the executed techniques and crafting custom rules." , "This iterative process aims to extend MITRE ATT&CK coverage"
3) Чем больше правил, тем больше шансов что-то поймать (и пускай для этого даже лучше ставить не последнюю версию Falco): "we can install Falco via Helm on a fixed version prior to the segregation of rules into different rules feeds" (а про вычислительные ресурсы при таком раскладе писать не будем)
4) Проще искать, когда знаешь что искать: "To ignore this noise, let’s instead just check for the specific Falco rule we are looking to detect".
5) Правил из коробки никогда не бывает достаточно: "Again, we have an [out-of-the-box rule]" , "CUSTOM RULE".
6) Пост вроде про Kubernetes, но для убедительности все будем показывать из темы хостовых ОС: "Adversaries may clear system logs to hide evidence of an intrusion. macOS and Linux both"
7) Но где-то глубоко внутри самих описаний правил все же будем признавать, что сначала надо разобраться как у нас вообще все работает: "However, it requires customization after profiling your environment."

В общем какая-то очень слабая статья получилась у Developer Advocate из Project Falco - хотя опять же все претензии выше не к конкретному решению, а к самому сигнатурному подходу, что мы уже не раз рассматривали. На пример, в нашем докладе. «EDR vs Containers: актуальные проблемы».

Ежегодное соревнование хакеров Pwn2Own, известное тем, что исследователи демонстрируют 0-day эскплоиты и компрометируют Tesla Model 3, Windows, macOS, Ubuntu и различные другие системы, приложения и устройства, в этом году расширяется и пополняется новой категорией – Cloud-Native/Container category.

Организаторы готовы выплатить $60,000 (в рамках китайского TianfuCup 2022 цена такая же) исследователям при условии, что их эксплоит должен быть запущен внутри контейнера/microVM и в результате совершить побег на хост (container escape).

$30,000 выплатят тому, кто сможет использовать уязвимость в кодовой базе gRPC для получения возможности выполнения произвольного кода.

Однако, это не единственные мероприятия, где можно заработать деньги за поиск уязвимостей в containers/Kubernetes. За баги найденные в соревнованиях kCTF и kernelCTF от Google (которые идут круглый год и без остановки) тоже выплачиваются баунти.

P.S. Как правило, на черном рынке подобное дороже в 5-10 раз в зависимости от спроса.

Современные микросервисы состоят на 60-80% из стороннего кода и отчет "The State of Software Supply Chain Security 2024" будет как никогда кстати, чтобы разобраться что и как у нас сейчас с цепочками поставки.

Kubetools – репозиторий с самой большой подборкой Open Source инструментов для Kubernetes на любые случаи жизни.

Все тулзы поделены на категории. Если говорить об инструментах в security направлении, то в первую очередь будут интересны следующие категории:

- Security Tools
- Network Policies
- Service Mesh
- Observability

Что интересно, наш инструмент MTKPI для проведения пентеста Kubernetes кластеров тоже попал в эту подборку! Если вы ещё не знакомы с ним, то советуем ознакомиться – репозиторий, слайды, видео.

На канале мы уже рассказывали про некоторые подборки – например по krew security plugins.

Недавно с нашими друзьями решали задачу харденинга окружения, в котором (как и у многих) для работы с секретами в Kubernetes используется HC Vault, а сегодня этим решением хотим поделиться и со всеми читателями.

Задача стояла в закручивании гаек (настройки SecurityContext, limits и т.д.) для волтовых init и sidecar контейнеров, чтобы на них не кричал PolicyEngine (а это считай на все нагрузки, где они используются) и как следствие они соответствовали внутренним стандартам компании. Использование PodSecurityContext (не путайте с SecurityContext) не решало задачи и задействовать механизм исключений не очень то и хотелось.

При этом как вы понимаете задача усложняется тем, что их самих в исходных ресурсах Pods нет и они уже добавляются в процессе выкатки через mutating admission webhook ...

В итоге, решением оказалось использование аннотаций vault.hashicorp.com/agent-init-json-patch и vault.hashicorp.com/agent-json-patch =) Берите и пользуйтесь!

P.S. Задача, кстати, очень напоминает задачу для ServiceMesh Istio, которую мы рассматривали тут.

P.S.S. Мы вам этого не говорили, но можно через этот механизм встраивать и backdoors и разные другие нехорошие вещи - придумать уже можете сами ;)

В январе 2024 года AWS CloudShell получил новую возможность: запуск контейнеров Docker. Это заинтересовало автора статьи "Deep dive into AWS CloudShell", поскольку Docker-in-Docker обычно подразумевает наличие привилегированных контейнеров. В статье автор рассказывает можно ли всё таки получить container escape в этом окружении, а также знакомит читателей с тем, что из себя представляет внутреннее устройство CloudShell.

P.S – Интересно, что раньше CloudShell использовал Firecracker microVM, но сейчас перешел на обычные EC2 инстансы. Как вы думаете, почему так?

Давненько мы ничего не писали про нашу любимую eBPF технологию, которую мы активно у себя в Luntry используем. И вот, вышла замечательная статья "BPF Memory Forensics with Volatility 3", позволяющая заглянуть в недра данной технологии. Но сразу отметим что не со стороны разработчика, а со стороны исследователя, который на руках исходных код может и не иметь ... То есть будем анализировать скомпилированный код и память. И все это с помощью утилиты Volatility 3. Если быть еще быть более точным, то статья будет больше полезна вирусным аналитикам, что хотят исследовать malware, rootkit на базе eBPF (писали и рассказывали уже о таком тут, тут и тут).

Вообще, на самом деле нужно быть очень внимательным даже при использовании OpenSource проектов на базе eBPF, так как это большие возможности и права в системе (на пример, чаще всего это привилегированные контейнеры), и нужно очень хорошо понимать что и как там делается. Так что читайте исходный код)

В декабре, на прошедшей конференции KubeDay India 2023 был представлен доклад Sign, Attest, and Verify! A Practical Guide for Software Supply Chain Security - Anushka Mittal & Vishal Choudhary, Nirmata.

Докладчики рассказывают о проблеме целостности образов и о том как её можно решить. Для этого они используют Notary и Cosign, чтобы подписать и верифицировать образ, и Kyverno, чтобы ограничить недоверенные образы в нагрузках Kubernetes. В конце доклада авторы наглядно демонстрируют эти возможности в небольшом демо.

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

Сегодня рассмотрим тему, которой мы не касались ни разу за все время существование данного канала (а это почти 4 года) - шифрование образов контейнеров! Вряд ли вы вообще о таком задумывались, но если касались темы Confidential Containers/Computing, то это вам знакомо.

Основным путеводителем для нас тут будет презентация "Advancing image security and compliance through Container Image Encryption!". Так для практического ознакомления с темой шифрования образов можно использовать:
- ocicrypt
- imgcrypt
- podman
- skopeo
- buildah

А для расшифровки настроенные:
- Containerd
- CRI-O

Кстати, можно шифровать конкретные слои (а не весь образ), на пример, с вашими ML модельками и контролировать их запуск только в вашей контролируемой среде и нигде более.

P.S. Есть кто уже шифрует?)

В версии Kubernetes 1.29 и более поздних обнаружено интересное изменение для кластеров, созданных через Kubeadm. Оказалось, что admin.conf больше не является членом группы system:masters из-за изменений, внесенных в Kubeadm, включая введение нового super-admin.conf. Теперь Kubeadm генерирует два файла: оригинальный admin.conf и новый super-admin.conf. admin.conf был изменен таким образом, чтобы иметь права cluster-admin но так, чтобы они могли быть отозваны путем удаления прав этой группы, а super-admin.conf остался членом system:masters, права которого нельзя отозвать.

Более подробно об этом можно почитать в статье "When is admin not admin?, when it's super-admin!" , за авторством Rory McCune.

Это ещё один показательный пример того, почему важно следить за изменениями в Kubernetes и понимать, как настроен ваш кластер. Это изменение упрощает отмену прав первоначальной учетной записи, но важно понимать, как оно работает и как может повлиять на ваш кластер.

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

Надеемся, что все хорошо провели праздники, отдохнули и теперь готовы как губка впитывать новую информацию, учиться, развиваться вместе с нами!

Мы совсем недавно на нашем сайте Luntry привели в порядок раздел Исследования, который содержит абсолютно все наши публичные исследования/выступления (как в формате слайдов, так и видео) с 2021 года (мы в теме, когда это еще не было мейнстримом)!

На наш взгляд этот раздел может быть хорошим стартом для новичков (и не только), которые погружаются в тему безопасности контейнеров и Kubernetes!

P.S. Если у вас есть еще идеи как сделать этот раздел более удобным для обучения, то предлагайте! Так у нас в планах еще добавить теги ко всем работам ;)

Команда нашего канала и вся команда Luntry хочет всех вас поздравить с наступающим Новым Годом! И если все личные пожелания - вы скорее всего получите от родных, близких и друзей, то мы направим наши поздравления в профессиональное русло)

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

Желаем вам, чтобы ваши контейнерные окружения с этапа архитектуры предусматривали механизмы безопасности (а не по остаточному принципу или в виде заплаток поверх всей системы), а политики безопасности учитывали специфику контейнеров, Kubernetes и соответствующие модели угроз (а не использовались со времен Windows 98)!

В общем, чтобы технологический прогресс и здравый смысл не убегали от вас вперед ;)

Заканчиваем эту неделю (и год) постом про повышением привилегий в GKE кластере через FluentBit и Anthos Service Mesh. Авторы рассматривают кейс Second-Stage Cloud Attacks – это тип атаки, при котором злоумышленник уже получил определенный уровень доступа к кластеру Kubernetes.

Можно выделить следующие шаги в этой атаке:

0) Злоумышленник получает RCE в контейнере FluentBit
1) Воспользовавшись смонитрованной директорией /var/lib/kubelet/pods получает доступ к ServiceAccount токенам
2) Используя избыточно высокопривилегированные права в кластере, которые назначены Anthos Service Mesh злоумышленник создает полезную нагрузку в неймспейсе kube-system используя и одновременно воруя другой высокопривелигрованный ServiceAccount – clusterrole-aggregation-controller.
3) Cluster-Admin profit!

Мисконфигурация GCP-2023-047 уже исправлена:

- убрали маунт /var/lib/kubelet/pod
- ограничили права в кластере Anthos Service Mesh

Немного цифр о канале по этому году.

Спасибо что нас читаете, комментируете, реагируете, пишите в личку, предлагаете идеи!

Спасибо за вашу активность)

P.S. Данные по прошлому году тут.

Сегодня в центре нашего внимания будет заметка "Don’t pin base image exact version tags" одного из наших читателей, который скидывал нам ее как-то в комментариях. Эта заметка лично мне очень запомнилась, потому что в ней рассматривается не популярная точка зрения на одну уже устоявшеюся задачу/проблему. И с этой точкой зрения (аргументированной) можно как соглашаться, так и нет, но самое важно, как по мне подобные заметки заставляют шевелиться серое вещество в наших головах... А не просто слепо следовать устоявшимся правилам, регламентам, мнениям больших компаний и авторитетов индустрии. Я считаю, что если ничего не ставить под сомнение и не пытаться находить новые пути/решения, то и никого прогресса никогда не будет - будем просто ходить про протоптанным дорожкам и переливать воду в решете ...

Давайте подискутируем в комментариях!

P.S. Наш вчерашний пост был из этой же категории.

А сегодня давайте поиграем в игру!

Уважаемые читатели расскажите пожалуйста нам зачем вы (или не вы) сканите хостовую ОС, на которой работает кластер Kubernetes, на известные уязвимости в пакетах? Какой сценарий атаки вы в таком случае рассматриваете? Какую модель нарушителя берете в рассмотрение? (Задачу прибавить работы коллегам не рассматриваем и "так написал коллега до меня" тоже!)

Лично мое мнение, что это максимально бесполезное дело в кластере Kubernetes и у меня есть следующие аргументы на этот счет:
1) Контейнеры используют пакеты из образа и хостовых никак не касаются
2) Ни один разработчик платформы Kubernetes не рассматривает вообще сценариев, что при работе с кластером человеку нужно ходить на Nodes, тоесть прямых доступов не надо. Общался с ребятами из Deckhouse, Штурвал, OpenShift, Talos. В сценариях с отладкой помним про kubectl debug на пример.
3) Любой пентестер знает, что если попал на тачку где работает Container Runtime Socket (а он есть на всех Nodes!), то все Game Over - повышение привилегий у тебя в руках.
4) Сценарии что у вас еще просто так запускается не контейнризированный софт (о котором не известно Kubernetes) не берем во внимание - это уже совсем другой класс проблем (и по мне более серьезный). И вы скорее напортачите с распределением ресурсов (ведь Kubernetes не учтет эту нагрузку если вы в ручную это не занесете) и в один день там просто случиться авария.

Теперь ваш ход =)

P.S. Игра называется Риск ориентированный подход! Игру придумали не мы ;)