Сегодня в фокусе нашего внимания исследование "Supply-Chain Security: Evaluation of Threats and Mitigations" об атаках и методах защиты цепочки поставки с оценкой их эффективности. Понравилось, что это все на примерах с реальной оценкой, а не просто на теории.

Содержимое:
- Review and re-evaluation of supply chain
- Model of modern typical CI/CD pipeline
- Attack injection point versus attack execution point
- Supply chain attacks and mitigations
- Summary of threat model (PDF)
- Summary of Mitigations (PDF)
- Source Repository
- Secrets
- Signing
- Dependency Tracking (SBOM)
- Attestation
- Example of a Centralized CI Pipeline

Как один из выводов это важность centralized CI pipeline для обеспечения Supply-Chain Security.

Если начинать потихоньку подводить итоги 2022 года, то самыми интересными для меня (IMHO) и нашей команды Luntry открытиями/прорывами/адаптациями/... года в области Kubernetes security стали:
1) Тема container specific OS - в этом году поглубже погрузился в данную тему и вообще по индустрии видно пристальный взгляд на это направление
2) Chainguard images - distroless images набирают обороты и становятся все доступнее, как раз благодаря вот таким вот проектам
3) Фичи в новых версиях Kubernetes - в этом году вышли 1.24, 1.25, 1.26:
- UserNamespacesSupport
- Forensic Container Checkpointing
- Поддержка cgroup v2
- Admission Policies

А как у вас в этом вопросе?)

Вообще я не любитель давать какие-то прогнозы, но тут что-то самому захотелось (самого себя проверить что ли через год) немного заглянуть в будущее и посмотреть, что нас ждет с в техническом плане с безопасностью контейнеров и Kubernetes в новом 2023 году. Возможно, сказывается то, что за этот год пришлось взаимодействовать с огромным количеством разных компаний из различных отраслей по вопросом контейнеризации (чего раньше в таких масштабах у меня не было). А также, участие в программном комитете DevOpsCоnf и еще более шире увидеть, что и в каком состоянии сейчас находится в индустрии в целом.

Кратко:
1) Повышенное внимание регуляторов к контейнерам
2) Платформизация систем компаний
3) В DevSecOps развитие Security Gate и ASOC систем
4) Ориентир на Security Observability
5) Рост атак на контейнерезированные окружения, важность безопасности supply chain

Более подробно с разъяснениями вот тут.

Есть еще Нострадамусы? То welcome в комментарии!

И сегодня подведем итоги 2022 года и немного заглянем в 2023:
1) Наш проект Лантри постепенно начинает помогать все большему и большему количеству компаний, использующих Kubernetes!
2) Данный канал продолжает расти (> +1600) и надеюсь радовать вас интересным и качественным контентом.
3) Наша небольшая команда в этом году приняла участие более чем в 12 мероприятиях по безопасности Kubernetes [1,2,3,4,5,6,7,8,9,...], а также были и различные подкасты [1,2,3] и вебинары!
4) Мой тренинг по безопасности Kubernetes все обновляется и расширяется и, кажется, такими темпами скоро перестанет укладываться в 3 дня =)
5) Есть определённые новые идеи/мысли запустить и попробовать что-то новое в следующем году как в виде форматов, так и по части различных активностей в образовательной деятельности. Главное, чтобы хватило на все времени и сил.


Всем большое спасибо, что читаете, комментируете, спрашиваете!

Всем хорошо встретить Новый Год, отдохнуть в праздники и не болеть!

Начнем год с забавной познавательной стать "Fun with SSRF - Turning the Kubernetes API Server into a port scanner" полезной как для атакующих, так и для защищающих.

Тут важно сразу понять, что все описанное в данной заметке это стандартная функциональность, а не какие-то уязвимости! Так все крутиться вокруг ресурса Validating Admission Webhooks (частью спецификации является service или URL). Помимо создания данного ресурса нужны будут права создавать еще и Namespace и Pod.

PoC сканера можно взять тут.

Сегодня я бы хотел привлечь ваше внимание к блоговой записи и репозитарию на канале одного моего товарища.

Сразу скажу, что речь в данной работе пойдет не про Kubernetes, а про Docker в чистом его проявлении в сочетании с OPA, а не как обычно принято на данном канале про OPA Gatekeeper =)

И так, моему товарищу понадобилось захерденить Docker executor и для этого нашелся Docker OPA Plugin, а вот правил проверок для него не нашлось, что в итоге и было реализовано!

P.S. Если тема интересная то в комментах можно подробнее расспросить автора об успешности работы все этого (Spoiler: не все так гладко как хотелось бы) ...

Компания Microsoft в очередной раз обновила свою Threat matrix for Kubernetes (по сути это уже 3 редакция)!

Помимо добавления новых техник (Static pods,Collecting data from pod) и расширения уже имеющихся (Container service account,Exposed sensitive interfaces) появилась и удобная интерактивная версия матрицы.

Еще появился и маппинг на техники MITRE ATT&CK, что удобно при использовании интерактивной матрицы.

А также, что более важно, появилась отдельная вкладка с Mitigations, которая на сегодняшний день включает в себя 32 пункта, каждый из которых привязан к той или иной тактике!

Сегодня из каждого утюга слышно про ChatGPT ...

А чем сообщество Kubernetes хуже?!

Также подумали одни ребята и запилили ChatGPT bot for Kubernetes issues! В общем помощника/подсказавальщика на базе ChatGPT для troubleshooting.

Текущий алгоритм работы:
1) Prometheus перенаправляет alerts на бота, используя webhook receiver
2) Бот спрашивает ChatGPT: "How to fix your alerts"
3) Результат отправляется в Slack

Подробнее можно посмотреть в этом видео ;)

Ввиду того что система Kubernetes декларативная и вся состоит из описанных YAML ресурсов, то для нее в данной области можно еще много чего интересного придумать =)

P.S. У нас даже уже есть определенные мысли и для Luntry, но всему свое время.

Мини исследование "Attack of the clones - Stealthy Kubernetes persistence with eathar, tòcan and teisteanas".

Автор проанализировал матрицу угроз для Kubernetes от Microsoft, а конкретнее стадию Persistence. И там обратил внимание что там совсем не покрыто "use of Kubernetes APIs to use or create long-lived credentials which clone system accounts." (Никогда не устану говорить, что все эти матрицы всегда на шаг позади от возможностей атакующий - будьте внимательны!)

Идея в том что имея краткосрочный доступ к привилегированному аккаунту превратить его в долгосрочный.

Рассматриваемые сценарии:
1) Кража cluster CA certificate и key
2) Использование CSR API
3) Использование TokenRequest API
4) Кража service account token secrets от system accounts

Все эксперименты проводились на:
- Kubeadm 1.25 (KinD)
- AKS 1.24.6
- EKS v1.23.13-eks-fb459a0
- GKE v1.24.7-gke.900

В заметке упоминаются такие полезные инструменты для пентеста как eathar, teisteanas, tocan, view-serviceaccount-kubeconfig.

Как я уже неоднократно писал - технология eBPF открывает очень много новых возможностей как для ИБ, так и для ИТ.

Сегодня я хотел бы вас познакомить с технической статей "How Universal Profiling unwinds stacks without frame pointers and symbols" от моих знакомых. Кстати, мне довелось немного приложить руку к их стартапу (поучаствовать в закрытом beta тестировании), который как вы можете сейчас заметить уже куплен Elastic.

Если совсем кратко, то они позволяют производить system-wide continuous profiling без какой-либо предварительной подготовки приложений (как раз благодаря eBPF) и даже без символов (если что ребята очень крутые reverse engineer'ы - так то мы и познакомились с ними)! В статье как раз и рассказывается как этого можно достичь. Это все точно работает и работает хорошо - я в этом лично убедился, запуская их в нашем k8s окружении (мой feedback в основном его и касался).

Мой коллега Сергей Канибор в процессе исследования безопасности Kubernetes наткнулся недавно на GitHub на один интересный баг и при этом еще НЕ ИСПРАВЛЕННЫЙ, который позволяет обходить определенный момент при работе PSP или Policy Engines!

Сама issue называется так - "Can bypass PodSecurityContext.SupplementalGroups by custom container image although PSP(or other policy engines) enforces the field". Название говорящее и сразу становится ясно, что речь идет только о SupplementalGroups. Наиболее критично это для multi-tenant Kubernetes cluster так как "can get access to some private directory in the hostPath volume.". И для самого обхода требуется собрать image специальным образом.

Более детально о данной проблеме и как ее воспроизвести (PoC) можно почитать в данном исследовании автора - "strict-supplementalgroups-container-runtime".

На глаза попалась статья с интересным названием “Abusing ETCD to Inject Resources and Bypass RBAC and Admission Controller Restrictions”.

Внутри разбираетcя что такое ETCD и как оно работает, как взаимодействовать с ним напрямую, а также как забрать и положить значение из key-value хранилища, так чтобы ничего не сломалось. В примере демонстрируется как можно записать значение Pod и какие ошибки при этом могут возникнуть (ну и как их пофиксить).

Громкое название, автор оправдывает в конце, напоминая, что любые ресурсы, которые деплоятся в кластер, проходят через kube-api server и соответственно подвергаются как валидации RBAC, так и Admission Controller, например в лице Policy Engine. Помещая ресурсы напрямую в ETCD, эти проверки можно обойти.

Как по мне, статья будет полезна тем, кто хочет понять как работать с ETCD, и тем, кто проводит пентест, при этом обложен различными средствами безопасности внутри кластера, но в тоже время обнаруживает Unauthenticated Access в ETCD :)

Совсем скоро (а именно Feb 1–2, 2023) состоится CloudNativeSecurityCon North America. На первый взгляд кажется что тут такого премичательного?! Ведь он уже и раньше проводился:
- Cloud Native SecurityCon North America (Oct 24–25, 2022)
- Cloud Native SecurityCon Europe (May 16–17, 2022)

Но по факту это первое такое самостоятельное мероприятие. То есть оно не проходит в рамках Kubecon и CloudNativeCon! В итоге, имеем целых 2 дня со множеством докладов по безопасности =)

Совсем недавно был пост про ChatGPT и как его можно использовать для troubleshooting в Kubernetes. Но энтузиасты пошли дальше и показали как можно запустить Кубер внутри ChatGPT. Да-да, вы не ослышались :) Стоит отметить, что этот эксперимент был вдохновлён другим экспериментом – Building A Virtual Machine inside ChatGPT.

Автор показывает как можно раскатать кластер через kubeadm прямо внутри чата (не без ошибок ChatGPT конечно, но всё же). Более того, лёгким движением руки версии Nodes обновляются с 1.20.1 до 1.21, в Pods стартуют контейнеры, и даже запущенный nginx внутри контейнера отдаёт ответ. Звучит как магия, не иначе.

Всем хороших выходных и удачных экспериментов =)

Как я уже писал, в конце прошлого года вышел Kubernetes 1.26 и там появилась такая фича как ValidatingAdmissionPolicy, позволяющая с помощью Common Expression Language выражений писать собственные политики.

Я, конечно, сомневаюсь, что уже кто-то активно использует 1.26 и включил данную alpha фичу, но все же смотреть на ее возможности - что, как и где она может конкурировать с Policy Engines уже точно можно. И лучше всего это делать на хорошо известных примерах!

Так, вот одни ребята взяли так и сделали - создали проект Kubescape Validating Admission Policy library в котором есть чуть более 20 готовых политик, типа:
- Forbidden Container Registries
- Resources memory limit and request
- Allow privilege escalation
- Immutable container filesystem
- Privileged container
- Sudo in container entrypoint
- и т.д.

Рекомендую посмотреть и сравнить с такими же политиками в Kyverno на YAML и в OPA Gatekeeper на Rego.

Top 15 Kubectl plugins for security engineers

Отличная подборка krew security плагинов для работы с Kubernetes. Мне приходилось иметь дело со следующими: RBAC-tool, Access-matrix, Rolesum, np-viewer, ksniff, Inspektor-Gadget.

На текущий момент, насчитывается более 200 плагинов krew в официальном репозитории. Но стоит не забывать, что вместе с удобством при их использовании, они также привносят security implications, такие как:

- Plugin vulnerabilities
- Insecure plugin installation
- Privilege escalation
- Data leakage

Чтобы избежать этих рисков, важно устаналивать плагины только из доверенных источников и регулярно обновлять их.

В официальном блоге Kubernetes вышла крутая статья "Consider All Microservices Vulnerable — And Monitor Their Behavior", посвящённая Security-Behavior Analysis!

Основной смысл: Наблюдайте и контролируйте поведение микросервисов и это уберет security gap между вами и атакующим, где он на шаг впереди.

Золотая цитата: "However, the year-by-year growth in cyber investments does not result in a parallel reduction in cyber incidents. Instead, the number of cyber incidents continues to grow annually. Evidently, organizations are doomed to fail in this struggle - no matter how much effort is made to detect and remove cyber weaknesses from deployed services, it seems offenders always have the upper hand."

Я несказанно рад, что такие же мысли и взгляды как у меня есть и у других людей в индустрии =)

Просто MUST READ для всех кто занимается безопасностью микросервисов и хочет этот делать качественно и правильно с учетом окружения!

P.S. Это именно то что мы с командой заложили в наш Luntry в модуль Runtime Security

Сегодня хочется поделиться ресурсом –“Container Security Site”. Сайт реально является кладезью полезной информации о container security.

На канале уже не раз упоминалось о подобных ресурсах, например тут (он кстати переехал сюда) и тут. Более того, о данном ресурсе вскользь упоминалось в этом посте, в контексте подборки Container CVE List.

В источнике затрагиваются все возможные полезные темы:

- General information
- Information for Attackers
- information for Defenders
- Security research

Ресурс будет крайне полезен как для Blue, так и для Red Team.

По мне очень смешное напоминание о том, что безопасность это комплексный процесс. И относительно безопасности контейнеров, Kubernetes стоит помнить и о: RBAC, Runtime Security, Audit Log, Network Policy и политиках PolicyEngine.

Всем хороших выходных!

На канале не раз упоминалось о важности сбора и анализа SBOM (1,2,3). Более того, этот функционал есть и в нашем Luntry. При сборе SBOM, довольно трудно понять насколько полноценную информацию удаётся собрать.

Сегодня хочу поделиться инструментом, который поможет количественно оценить сгенерированный SBOM. В sbom-scorecard довольно большая система метрик, по которым выносится конечная оценка SBOM (она еще развивается и дополняется):

- Spec compliant
- Generation Info
- IDs
- Versions
- Licenses

Тулзу можно попробовать и без установки. Для этого достаточно перейти на сайт и загрузить SBOM.