Стал доступен фотоотчет с нашего первого БЕКОН!

Attacking and securing cloud identities in managed Kubernetes part 1: Amazon EKS – первая статья из цикла про атаку и защиту managed Kubernetes (Amazon EKS).

Автор довольно подробно разбирает, то как работает аутентификация и авторизация в EKS кластере, а потом на примере уязвимового веб-приложения демонстрирует как можно застилить Node credentials через IMDS, а также показывает pivoting технику для продвижения по AWS облаку. Безусловно, без ряда оговорок с неправильной конфигурацией самого кластера ничего бы не вышло.

В конце упоминается тулза MKAT (о которой мы рассказывали ранее), она будет полезной если вы хотите проверить защищенность вашего EKS кластера.

Если говорить о remedations, то это в первую очередь:

1) Использование сетевых политик, для ограничения доступа Pod к IMDS
2) Выставление http_put_response_hop_limit = 1
3) Использование IAM ролей для ServiceAccount с целью аутентификации рабочих нагрузок Kubernetes в AWS.

Закончим эту неделю достаточно низкоуровневой темой базирующейся на устройстве Linux и ее связью с Kubernetes. А навеяно это все заметкой "Access Kubernetes Objects Data From /Proc Directory". Там рассказывают и показывают:
1) Какую роль играет /proc в Linux
2) Как через /proc можно дотянуться до данных в etcd
3) Как через /proc можно дотянуться до переменных окружений процессов, работающих в контейнерах, в Pods

Как вы понимаете это все верно только для классических контейнеров, которые по сути представляет из себя linux процессы с определенными свойствами (namespaces, cgroups и т.д.).

А что это может дать злоумышленнику? Злоумышленник попавший на Node для доступа к информации контейнеров может не порождать интерактивный shell или выполнять команды в них, а методично пройтись и узнать все необходимое через /proc.

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

На следующей неделе - 26-27 июня в Санкт-Петербурге во время белых ночей пройдет Saint HighLoad++ 2023. Наша команда там будет, можно встретиться, поговорить про безопасность контейнеров и Kubernetes! Также это прекрасная возможность заполучить наш стикер пак c БЕКОН ;)

На недавно прошедшей конференции fwd:cloudsec 2023 был довольно интересный доклад, напрямую затрагивающий безопасность Kubernetes – Swimming with the Sharks. IR Kubed.

Спикер рассказывает о реагировании на инциденты в Kubernetes с сетевой точки зрения. Весь доклад крутится вокруг инструмента kubeshark, который позволяет мониторить и захватывать трафик в Kubernetes в режиме реального времени. По сути тулза выполняет функционал TCPDump и Wireshark, но в контексте Кубера.

Наша команда около года назад уже рассказывала про особенности DFIR в Kubernetes – в докладе Специфика расследования инцидентов в контейнерах. Будет в тему, советуем ознакомиться.

На недавно прошедшей конференции BSides NYC 2023 был представлен доклад "Analyzing volatile memory on a Google Kubernetes Engine node" (статья, видео, репа) от ребят из Spotify. В принципе из названия понятно, что речь идет об анализе памяти снятой во время инцидента для последующего расследования. Для этого они делают следующее:
1) Создание kernel memory dump (работа с /proc/kcore)
2) Получение символов для данного ядра (причуды COS и не документированное API)
3) Анализ kernel memory dump

Это они показывают на примере 3 open-source инструментов: AVML, dwarf2json, Volatility 3. Не всегда и везде это, конечно, получиться провернуть, но как вариант почему бы и нет.

У себя в Luntry мы уже реализовали подобное с рядом особенностей, обходящих ограничений такого подхода. На пример, нет смысла снимать дамп для всей Node, когда экономичнее все сделать для конкретного контейнера и все.

Одно из интересных свойств container registries заключается в том, что они по сути являются большими хранилищами файлов.

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

Например, с помощью crane:

crane export raesene/alpine-containertools - | tar -Oxf - usr/local/bin/kubectl > kubectl

Узнать про другие возможности crane можно тут.

Если вы хотите изучить файловую систему контейнера на разных слоях это можно сделать с помощью dive или онлайн ресурса https://explore.ggcr.dev/

К слову, registries можно также использовать при пентесте для эксфильтрации данных.

Тут внутри нашей команды открыли для себя новую конференцию DevSecCon24 и как вы понимаете, там не обошлось без тем про Kubernetes и около него:
- "Kubernetes Goat Interactive Kubernetes Security Learning Playground"
- "Container Security Strengthening the Heart of Your Operations"
- "Zero trust authorization with Open Policy Agent"

Также, там много всего интересного про AI в pipelines, AI в DevSecOps, OWASP Top 10, Incident Response, Supply Chain, GitOps. Все видео можно посмотреть тут.

Недавно друзья прислали забавную статью "Лучшие тренеры по ИБ и ИТ. Кто они?". Там перечислено 6 человек, среди которых удалось попасть и мне, что, конечно, очень приятно)

При этом важно отметить, что тренинг бы не был так хорош и нравился людям, если бы не вся наша команда Luntry! Без крутой команды невозможно поддерживать материал в актуальном состоянии для такой большой области как Cloud Native security и Kubernetes security. Нам постоянно приходиться что пробовать, с чем-то экспериментировать, тестировать на большой выборке разных конфигураций и т.д.

One-Time Pass Codes for Kyverno – статья о нетривальном использовании Kyverno. Автор предлагает довольно интересный подход для использования исключений в правилах. Если говорить о том, какие варианты в целом можно использовать для исключений, то это:

1) Определение исключений в правиле
2) Использование custom resources PolicyException
3) Через ConfigMap

Автор пошёл дальше и показал как с помощью Kyverno можно организовать работу OTP для исключений в политиках. Вкратце, это делается так:

При деплое ресурса пользователю выдается ошибка с OTP, который он может использовать при следующем деплое и пройти проверку. А сам список OTP кодов обновляется и управляется с помощью ещё одной политики.

Конечно, это всё сделано ради забавы и найти применение этому в реальной жизни не представляется возможным. Однако этот кейс в очередной раз показывает насколько гибко можно использовать Kyverno.

Начнём эту первую неделю июля с образовательного ресурса, а именно Chainguard Academy.

Сами они позиционируют свой ресурс так: "Learn how to make your software supply chain secure by default". Там собрано много всего интересного и полезного:
- Глоссарий по теме supply chain security
- Полезный open source (Wolfi, Apko, Melange, Sigstore и д.р.) по данной теме (и не мало важно что в некоторых смыслах очень уникальный)
- Различные советы, в духе как правильно выбрать базовый образ, как уменьшить поверхность атаки у образов и т.д.

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

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

Таким образом сейчас уже доступны все материалы с мероприятия:
- Видео
- Презентации
- Фотоотчет

P.S. Теперь уже можно смело готовиться к следующему БЕКОНу ;)

Маленькая заметка "Kubernetes is a cloud operating system" проводит параллели Kubernetes c операционными системами. Это как просто интересно, так и может быть полезно тем кто только погружается в данную тему.

В одном из своих докладов ("Kubernetes Resource Model (KRM): Everything-as-Code") я также уже поднимал мысль, что Kubernetes это ядро Linux 21 века.

В общем, такие обсуждения/сравнения периодически поднимаются в индустрии. Одним из самых оригинальных в своих разговорах (при этом с хорошей аргументацией) я помню это сравнение Kubernetes c распределённой БД)

Интересная статья с официального блога под названием "Verifying Container Image Signatures Within CRI Runtimes".

Там рассказывается о новых фичах, связанных с проверкой подписи образов, в CRI-O и Kubernetes. А именно:
1) Container Runtime CRI-O с версии 1.28 может самостоятельно проверять подписи образов.
2) В Kubernetes версии 1.28 появилась новая image pull ошибка с кодом SignatureValidationFailed

Таким образом:
- Подписи образов контейнеров можно проверять не только на деплое с помощью Policy Engines или policy-controller, но и прям на Node возможностями Container Runtime

Про аналогичную возможность на стороне containerd пока ничего неизвестно.

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

Если поискать по открытым источникам, то, конечно, найдете такие случаи, но это совсем не отражает реальной картины. Так как наша команда Luntry со многими компаниями взаимодействует по безопасности контейнеров и контейнерных сред, то мы видим абсолютно другую картину. Если без деталей, то там по итогу от запуска майнеров и атаки на CI\CD подсистему до проникновения в корпоративную сеть, заражения сотрудников и удаления части инфраструктуры компании. При этом оставим за скобками те инциденты, в которых так и непонятно каким образом пришел атакующий, так как следы исчезают, где-то на границе контейнерных и классических сред.

Я думаю, по понятным всем причинам компании открыто не делятся такими историями и складывается не корректная картина о угрозах и возможностях, атакующих ...

P.S. А если мы к этому еще прибавим результаты наших аудитов/пентестов Kubernetes, то такого могло быть потенциальнее куда больше.

Начнем эту неделю с одного занимательно, малоизвестного факта о Kubernetes.

Знаете ли вы что в Kubernetes есть так называемые "unpublished" API ?!

Тоесть по сути YAML ресурс есть, но вот поработать с ним как с другими YAML ресурсами по RESTful нельзя ...

Самым известным и одним из важных для задач ИБ подобных ресурсов является Audit Policy из группы audit.k8s.io/v1 API, в котором описывается политика аудита! Как вы наверняка помните это YAML ресурс передается в ключах запуска для Kubernetes API server и все. Динамически ее отправить, поправить нельзя, нужен перезапуск Kubernetes API server.

P.S. Такими моментами, конечно, `k8s` расстраивает нашу команду, да и вообще всех разработчиков решений под `k8s`.

Копаясь в недрах Kubernetes на GitHub, наша команда наткнулась на очень интересный PR (он кстати уже даже смерджен и будет в v1.28) и называется он "Add SidecarContainers feature"!

Из его описания можно узнать:"This feature introduces sidecar containers, a new type of init container that starts before other containers but remains running for the full duration of the pod's lifecycle and will not block pod termination."

Более детальнее об этом написано в KEP-753: Sidecar containers.

По сути это initContainers только с полем restartPolicy и стартуют до основных контейнеров и не мешают их завершению!

Это должно упростить ряд задач и повысить стабильность системы.

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

Значит собрались мы вчера расширенным составом нашей команды (Dev, Sec, DevOps), чтобы посмотреть на проработку одной новой фичи по безопасности образов с разных сторон, разными взглядами и по итогу пришли к очень неутешительным выводам. А именно: "Все подходы, анализы на базе статического анализа позволяют защититься только лишь от легитимного пользователя, но не являются никакой помехой для вредоносного". Под легитимным пользователем мы понимаем пользователя, который никаким образом не пытается обмануть, обойти систему, а вредоносный соответственно готов на это идти. И он это может делать даже не столько ради того чтобы взломать/заразить/... что-то, столько ради того чтобы меньше иметь проблем с выкаткой, с безопасностью и другими compliance вещами в компании.

Из-за чего так? By design в docker много моментов не дальновидных, не очень хороших (часть таких моментов уже обсуждалось на канале и в комментариях не раз) + все недостатки статического анализа. Это определенно заслуживает отдельного доклада, где наша команда Luntry с деталями и примерами всем этим поделиться.

xeol - простенький сканер образов контейнеров, SBOM и файловых систем на проверку пакетов на end-of-life (EOL). Поддерживает ввод Syft, SPDX и CycloneDX SBOM форматы. Саму базу знаний о end-of-life инструмент берет с https://endoflife.date/ (не раз уже писали об этом ресурсе).

Полезно чтобы понять, что по пакетам у которых жизненный цикл поддержки закончился, обновлений, фиксов, патчей уже можно даже не ждать и сканеры все равно будут показывать, что та или иная CVE - Not fixed.