Взаимодействуя с разными компаниями и организациями мы видим как растет число 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 - успейте поучаствовать и выиграть призы ;)

На прошедшем DEFCON в рамках CloudVillage был представлен доклад "CNAPPGoat - A multicloud vulnerable-by-design infrastructure deployment tool". Как не сложно догадаться благодаря инструменту CNAPPgoat можно развернуть различные уязвимые сценарии в различных публичных облаках для тестирования своих detection и prevention возможностей, так и просто для тренировки red и blue team.

Из интересных моментов:
- Написан с помощи Pulumi на Go (Впервые встречаю использования Pulumi в security проекте, а если вы не знаете что это, то если кратко, то: Infrastructure as code in any programming language)
- Содержит приличную базу сценариев (лежат отдельно тут)
- Поддерживает AWS, Azure и GCP

Также обратите ваше внимание на раздел "Similar projects" в конце репозитария, где представлен список подобных проектов.

15 августа вышла версия Kubernetes 1.28 под кодовым названием Planeternetes! Если говорить о security изменениях, то это в первую очередь:

- CEL-based admission policies webhook match conditions. Использование CEL-выражений для определения области применения admission webhook.
- CRD Validation Expression Language. Для проверки CRD теперь можно использовать CEL.
- CEL for Admission Control. Новый способ контроля через CEL, без необходимости задействовать вебхуки.
- Reduction of secret-based service account tokens. Отмена автоматической генерации секретов для служебных SA.
- Support User Namespaces in Pods. Ограничение привилегированного процесса в Pod.
- KMS v2 improvements. Улучшение сервиса, который используется для шифрования данных etcd.
- Auth API to Get Self-User Attributes. Новая команда kubectl auth who-a-mi позволяет увидеть текущего пользователя после завершения процесса аутентификации.

Со всеми изменениями, которые пришли в версию 1.28 можно ознакомиться тут.

CNCF опубликовало текст документа "Security Zero Trust using Cloud Native Platforms". Очень достойный документ, который в очередной раз заставляется задуматься о "пользе" постоянных сканирований, использования сигнатур и т.д. В итоге понять какие действительно меры рабочие в текущих реалиях.

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

Security Tool Ranking – довольно забавный рейтинг популярности security тулзов. Рейтинг расчитывается по трем критериям: stars, pull requests и issues.

Интересно, что из 50 позиций около 20 так или иначе относятся к направлению Kubernetes security. Это, в свою очередь, говорит о популярности самого Kubernetes в целом.

Однако, слепо верить и доверять таким рейтингам при выборе инструмента не стоит ;)

Ребята из команды GitHub выпустили заметку "mTLS: When certificate authentication is done wrong" на базе своих исследований представленный на конференциях Black Hat USA и DEF CON. В рамках ее они рассматривают:
1) Что такое mutual TLS
2) Атаки на mutual TLS

Рассматриваются как известные атаки, так и новые на базе уязвимостей:
- CVE-2023-2422 improper certificate validation in KeyCloak
- CVE-2023-33201 LDAP injection in Bouncy Castle
- CVE-2023-28857 credentials leak in Apereo CAS

По нашим клиентам знаем, что периодически компании для организации mutual TLS между сервисами используют не какие-то готовые решения (типа ServiceMesh), а пишут полностью свои. И вот это исследование будет полезно как первым так и вторым ;)