Продолжим тему Confidential Computing (CC) в Kubernetes и остановимся на одном из основных проектов в этой теме.

Confidential Containers (CoCo) - это CNCF sandbox project, который позволяет изолировать Kubernetes pods внутри confidential virtual machines. Цель данного проекта установить стандарт для Confidential Computing (CC) на уровне Kubernetes pod. С точки зрения реализации сам проект представляет из себя kubernetes operator с рядом служебных сервисов ( guest-components, Key Broker Service, Attestation Service) и специальный runtimeClassName (под капотам там модифицированная kata), который нужно указать для Pod.

Всего есть 3 режима работы на базе:
1) VM-based TEEs на local hypervisor (на картинке)
2) VM-based TEEs на remote hypervisor
3) Process-based TEE

Про проект можно подробнее почитать в документации или из статьи "Confidential Containers in Kubernetes".

Наша исследовательская команда нашла довольно интересный репозиторий с исследованием "Container image with malware and crypto miner for testing". В нем автор решил проверить как различные сканеры образов могут обнаружить вредоносный код в образах контейнеров. Для этого он в легитимный образ залил (без обфускации и т.д.) солидную выборку хорошо известных malware, ransomware, crypto miner и т.д.

Что можно сказать про результаты? А то что даже те кто активно заявляют эту функциональность и вроде как даже на этом специализируются - сели в лужу (статический анализ мы уже обсуждали) ... И это еще на том что есть на VirusTotal и т.д. Хотя под это, конечно, можно достаточно просто подгонять результат ...

По своему опыту обхода антивирусов могу сказать, что когда я руководил исследовательским центром и к нам приходили наши пентестеры и просили помочь им обойти серьезные корпоративные антивирусы и EDR для запуска Mimikatz и подобного, то это занимало от нескольких часов до 2-3 дней. В контейнерных окружениях это сделать еще проще, тем более когда атакующий сам готовит весь образ ;)

Еще разница в том, что если на пользовательских тачках много ресурсов и они могут простаивать, то на Nodes в Kubernetes отдавать под это немалые вычислительные ресурсы это большая роскошь ...

P.S. Как-то мы уже делали даже опрос по данной теме.
P.S.S. NetworkPolicy - must have!

Некоторое время назад, изучая замечательную документацию GKE, наткнулись на интересный пункт "Restrict the ability for workloads to self-modify" в разделе "Harden your cluster's security".

Предыстория, тут следующая: некоторые рабочие нагрузки (особенно системные) могут менять для тех или иных задач свой же шаблон (на пример, для вертикального авто скейлинга) - то есть заниматься самомодификацией. При этом атакующий на Node, может изменить рабочую нагрузку на Node, чтобы она выполнялась от более привилегированного ServiceAccount, который существует в том же Namespace. Замысловатый вектор, но имеет право на жизнь.

В качестве защитных мер от подобного предлагается:
1) Не давать рабочим нагрузкам права на модификацию себя.
2) Если пункт 1 невозможен, то ограничить то, что может меняться. На пример, содержимое поля serviceAccountName.

Пункт 2 можно реализовать с помощью PolicyEngine. В GKE используется OPA Gatekeeper и они приводят пример такой политики на нем - NoUpdateServiceAccount (хотя это можно сделать и на Kyverno). Рекомендуем взять такую политику на вооружение или хотя бы просто ее изучить. В этой политике есть прекрасный пример того, как можно обрабатывать запросы на основе определённых пользователей или групп и добавлять их в исключения (чаще всего это делают сразу на целый Namespace).

Также хочется порекомендовать такую хорошую практику как запуск системных рабочих нагрузок на отдельных Nodes и не мешать их с обычными бизнес-сервисами ;)

Abusing Amazon VPC CNI plugin for Kubernetes – довольно интересная статья, из которой вы узнаете, что встроенный CNI плагин в Amazon не такой уж и безопасный.

Рассматривая возможности атаки на Amazon EKS, авторы статьи исследовали плагин Amazon VPC CNI для Kubernetes и выявили способы злоупотребления этим плагином для манипулирования сетями в своих интересах. Это позволяет злоумышленнику, закрепившемуся в кластере EKS, создавать и потенциально эксплуатировать сервисы в других VPC, не связанных с кластером.

В качестве возможных remedations отмечаются:

- IAM Roles for ServiceAccounts
- Blocking instance metadata service (IMDS)
- AWS IAM policy hardening

На этой неделе – 4-5 августа наша команда Luntry будет принимать участие в конференции Ural Digital Weekend 2023 в Перми. Мы выступим с докладом “Создание Network Policy в Kubernetes: ключевые аспекты и рекомендации для разработчиков”, и вместе с тем затронем вопросы того, почему разработчикам необходимо понимать и уметь в Network Policy в Kubernetes.

Купить билет можно тут, а указав наш промокод LUNTRY894, вы получите скидку 10% на всё.

Взаимодействуя с разными компаниями и организациями мы видим как растет число Kubernetes кластеров в них и потребность в контроле и управлении этим множеством кластеров.

Это же наблюдает и сообщество Kubernetes, которое уже создало для решения данной задачи Multicluster Special Interest Group. За их успехами можно наблюдать тут (пример одной из новых инициатив Cluster Inventory API).

В рамках KEP-1645: Multi-Cluster Services API они работают над Multicluster Services API (MCS API) (на картинке). Это должно позволить упросить общение микросервисов из разных кластеров. Если вам интересны реализации, то их можно посмотреть тут.

GUAC: Graph for Understanding Artifact Composition – интересная тулза, которая поможет вам определить и красиво отобразить взаимотношения между зависимостями в приложении.

На вход инструмент может принимать следующие форматы данных:

- CycloneDX
- Dead Simple Signing Envelope
- Deps.dev API
- In-toto ITE6
- OpenSSF Scorecard
- OSV
- SLSA
- SPDX

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

Концептуально, GUAC, представляет слой "Aggregation and synthesis" в логической модели software supply chain transparency. Вместе с тем, инструмент также закрывает proactive, preventive & reactive вопросы безопасности.

Наши хорошие товарищи 24–25 августа в Москве организовывают конференцию OFFZONE 2023. От нашей команды Luntry в секции AppSec выступит Сергей Канибор с докладом "Kubernetes Pentest All-in-one: The Ultimate Toolkit".

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

При этом мы хотим разыграть 1 проходку на конференцию! В комментариях к данному посту напишите случай из вашей (или не вашей практики), когда приходилось обходить какие-то security контроли связанные с контейнерами или Kubernetes =)

Наиболее интересный случай по нашему мнению получит проходку. Варианты принимаем до Пн (7.08).

Статья "GameOver(lay): Easy-to-exploit local privilege escalation vulnerabilities in Ubuntu Linux affect 40% of Ubuntu cloud workloads" рассказывает о двух уязвимостях CVE-2023-2640, CVE-2023-32629 в модуле OverlayFS в ОС `Ubuntu.

Наше внимание это привлекло по следующим причинам:
1) Ubuntu можно часто встретить в контейнерных окружениях.
2) OverlayFS часто используется контейнерами
3) Для эксплуатации нужны манипуляции с user namespace и это очень популярно в рамках того же kCTF (часто доступно в контейнерах)
4) Эти уязвимости это реинкарнации CVE-2021-3493 из 2020. Из-за того у Ubuntu была своя доп. логика.
5) Сверх стабильный эксплоит, так как нет никаких манипуляций с памятью.

Получается так что user namespace создавали во благо, но сейчас он часто используется совсем в противоположную сторону. Думаю что он заслуживает особого внимания и возможно на следующем БЕКОН мы покроем эту тему ;)

P.S. Вы не поверите. но работа над программой следующего БЕКОН уже идет.

На нашем канале и в наших докладах мы с командой не раз уже поднимали тему, что исправление уязвимостей в сторонних библиотеках (а современные микросервисы на 60-80% состоят из сторонних библиотек) это не простая задача как ее многие описывают (нужно только просканировать и поднять версию зависимости до нужной и все). И тут наткнулись на интересный молодой проект, который призван как помочь в этом не легком деле, так и просто пояснить какие вообще есть сложности (на примерах, того, когда они сами полезны).

Seal Security Patches — это централизованный репозитарий самодостаточных исправлений безопасности для open source библиотек. Вот такие сценарии рассматриваются, когда разработчику может быть обновиться на последнюю версию библиотеки невозможно, очень долго или не практично:
- Ломающие изменение или deprecated фичи в новой версии библиотеки
- Уязвима транзитивная зависимость
- Уязвима не поддерживаемая библиотека
- Legacy код
- Mission-critical приложение
- Уязвим сторонний Container/VM образ
- Large Language Models (LLM) код

Очень хорошие кейсы и точно все команды разработки с этим сталкивались (ну кроме последнего конечно =) ). И тут еще перечислены только технические аспекты данной проблемы, а прибавьте к этому разные процессные и сроки обновления у многих улетаю в совсем не приличное сроки. Сейчас в проекте уже доступен ряд патчей для разных npm (29), rpm (8), pypi (7) библиотек - можно зайти и посмотреть, как это организовано и применяется.

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

P.S. Мне это также напомнило решение ребят из 0patch, но только там для бинарных приложений.

Сегодня в 14:30 по Мск можно online посмотреть выступление "Создание Network Policy в Kubernetes: ключевые аспекты и рекомендации для разработчиков" от нашего коллеги Сергея Канибора (Luntry, Security Researcher) с конференции Ural Digital Weekend 2023.

Ссылка на трансляцию.

Container security fundamentals part 5: AppArmor and SELinux – пятая статья из цикла статей [1,2,3,4] про безопасность контейнеров от Rory McCune.

Автор рассказывает как можно использовать такие механизмы как AppArmor и SELinux в контейнерном окружении. Сама по себе статья небольшая и в ней отражены только основные моменты по работе с этими механизмами.

Если вы хотите более глубже погрузиться в AppArmor в контексте Kubernetes, то рекомендуем к изучению доклад от нашей команды с БЕКОНа – AppArmor и Kubernetes: настройка проактивной защиты для безопасности приложений (видео, слайды).

P.S. В качестве домашнего задания: ответьте на вопрос, чем в Kubernetes механизм AppArmor лучше чем любой другой навесной prevention механизм для контейнеров (включая тех что написаны на eBPF)?

P.S.S. На самом деле благодаря этому моменту мы и реализовали автоматическую генерацию AppArmor в нашем Luntry.

Сегодня запускаем еще один конкурс и на этот раз с нашими друзьями из DevOops!

Ребята продумывают крутой стикер пак для своей конференции и хотят чтобы он нравился абсолютно всем! И в этом можно и нужно поучаствовать. Предлагайте свои варианты стикеров на тему DevOps, DevSecOps, контейнеров, Kubernetes! Самые прикольные стикеры будут включены в стикер пак и раздаваться на мероприятии. За лучший стикер приз билет на конференцию (есть и приятный сюрприз и для всех участников)!

Варианты стикеров принимаются до 15 августа! Варианты прикрепляйте к комментариям к данному посту.

Наша команда Luntry также примет активное участие в программной части конференции и в ее круглых столах!

P.S. Сегодня последний день чтобы поучаствовать в конкурсе за билет на конференцию OFFZONE!

"Fun with privileged container breakout" и "The Route to Root: Container Escape Using Kernel Exploitation" это две хорошие статьи, посвящённый одной теме - побегу из привилегированного контейнера (или при наличии CAP_SYS_MODULE) с помощью подгрузки своего модуля ядра. Про такой же сценарий наша команда Luntry рассказывали пару лет назад в докладе “Container escapes: Kubernetes edition”.

Метод, конечно, шумный, требует серьезные привилегии, но при этом стабильный и имеет большое покрытие при использовании. Как минимум знать и помнить о нем нужно)

Kubefuzz – фаззер для Kubernetes Admission controller chains. Будет полезен для тестирования и выявления неожиданного поведения, там где конфигурация Admission controllers довольно сложная.

Сами правила для генерации и мутации, описываются в отдельном ресурсе – Constraint. Всё это работает по принципу белого списка. Может работать в трех режимах: Generation – для генерации данных, Mutation – для их мутации, и Fuzzing – по сути комбинация первых двух режимов.

Что интересно – сама тулза была представлена на недавно прошедшей конференции Troopers23. Ознакомиться со слайдами можно тут.

Когда наша команда проводит аудит безопасности Kubernetes в более продвинутых компаниях сейчас для всех их политик (для Policy Engine) они как правило пишут и ряд тестовых ресурсов для проверки как с положительным результатом, так и с отрицательным.

В рамках KubeCon + CloudNativeCon Europe 2022 был представлен доклад "Komrade: an Open-Source Security Chaos Engineering (SCE) Tool for K8s" (слайды, видео), а с ним и выложен инструмент Kirvis.

Те, кто был на моем тренинге, знают, что за темой Security Chaos Engineerin я активно наблюдаю и люблю обсудить) И тут как раз на эту тему попался доклад!

Изучая данные слайды, было очень приятно видеть те же самые мысли, идеи, что мы активно освещаем как в наших выступлениях (с 2021), так и фичах нашего решения. На пример:
1) "Our systems have evolved beyond our human ability to mentally model their behavior"
2) "Software ONLY Increases in Complexity"
3) "Our systems have become more complex and messy than we remember"
4) "Cyber Security is Context Dependent"
5) "How do I know if my Security Really Works???"
6) "Understand your system and its security gaps before an adversary does"
7) "Hope is Not an Effective Strategy"

В этом есть много объяснений почему мы решили делать security observability и упор на поведенческий анализ.

Kirvis (после публикации ни разу не обновленный) по своей сути меняет настройки в небезопасное состояние, а потом возвращает в исходное. Ваши инструменты ИБ должны это конечно обнаружить! Еще там упоминается такой инструмент по этой теме как ChaoSlingr (тоже заброшен) (слайды о нем и с ними мы также рекомендуем ознакомиться).

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

One-Time Pass Codes for Kyverno...With Quotas! – продолжение статьи (первая часть), в которой рассказывается как можно использовать Kyverno в качестве OTP системы. На этот раз автор представляет вторую, улучшенную версию.

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

Всё что для этого нужно – несколько политик Kyverno: одна для валидации данных, другая для генерации кодов и третья для регулирования квот.

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

На прошлой неделе состоялись две крупнейшие ИБ конференции в Мире - это BlackHat USA Las Vegas и DEFCON USA. Я знаю о чем говорю, так как на первой мне довелось выступать (включая BlackHat UAE Abu Dhabi), а на второй присутствовать. И вот там было представлено море всего интересного, так что ближайшее время то что касается контейнеров и Kubernetes мы постараемся осветить на нашем канале.

Начнем с темы, которой достаточно редко покрывается на нашем канале — это Windows containers [1,2,3,4]. Доклад называется "Contain Yourself: Staying Undetected Using the Windows Containers Isolation Framework". Здесь вообще нет ничего общего с Linux containers, но нам мой взгляд будет полезно знать что, как и на сколько отличается в реализациях. Ну и как следует из названия доклада потом данная технология используется для того чтобы организовать:
- Ransomware/Wiper protection bypass
- DLP/Secured folders write bypass
- ETW-based correlations bypass

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

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

Речь идёт про konstellation, авторы представили его в рамках BlackHat Arsenal. Тулза умеет делать несколько вещей:

- Собирать данные с Kubernetes cluster (используемые ресурсы, RBAC)
- Показывать BadPods и опасные Role & ClusterRole
- Находить relationships между ресурсами K8S, например RoleBinding → Role
- Визуализировать полученные связи в виде графов в Neo4j

И всё бы ничего, только возникает большой вопрос – а зачем это? Есть ряд других open source инструментов, которые позволяют это делать + удобно отображают результаты. А тут еще ко всему прочему нужно тащить neo4j. Лично мы не увидели никакого преимущества у данного инструмента по сравнению с другими в этой области.

Решили провести вебинар - «Patch management не поможет, фиксики не спасут». В рамках которого хочется раскрыть мысль, которая в наших выступлениях уже звучала, но то это было частью другой темы, то на доклад было 10-15 мин, то доклад был на закрытом мероприятии. А очень хочется это полностью раскрыть (со всеми проблемами) и чтобы все могли посмотреть на проблемы patch management в реальных (не эфемерных) условиях, где есть и атакующие, и другие департаменты, и корпоративные процессы, и разные регуляторы и все это с примерами и т.д. Знаем что многих этот вопрос волнует.

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

Вебинар пройдет 29 августа в 11:00. Зарегистрироваться можно тут.

P.S. К завершению подходит конкурс от конференции DevOops - успейте поучаствовать и выиграть призы ;)