k8s (in)security

Поговорим о такой возможности/проверке/контроле как блокировать деплоймент на основании какой-то информации об известных уязвимостях. Это прямо мечта многих безопасников) НО реальная жизнь показывает, что с этим может быть множество проблем вплоть до падения прода. В общем, это классно в теории, а на практике до тех пор, пока вы не уроните прод.

И так, что же может пойти нет?!
1) Допустим, пройдя все проверки, выкатывается образ и у него 0 уязвимостей (фантастика, но пускай).
2) Далее происходит обновление feed об уязвимостях и с его учетом у нас в том же самом образе, где минуту назад было 0, появились какие-то уязвимости (critical, high, medium, low)!
3) (Чисто как факт - в проде уже работает уязвимое приложение, через которое можно скомпрометировать систему)
4) ReplicaSets controller решает, что нужны еще Pod с тем самым образом. Это может быть по многим причинам: сработал HPA, какие-то Pods аварийное завершились по OOM, упала Node и утащила за собой эти Pods, Pods переезжают с Node на Node по какой-то причине, происходит обновление Secrets/ConfigMap/... и нужно рестартануть Pods, обновили сам YAML для Deployment и т.д. То есть опять запускается процесс выкатки приложение на том же образе ;)
5) Этот контроль видит этот образ с его critical, high, medium, low уязвимостями и блокирует деплоймент ...
6) Тут можете уже самим придумать как ваша система не справляется, деградирует, складывается как карточный домик. И соответственно бизнес и ИТ совсем не рады такому ... (Встанет вопрос кто принес ущерба больше CVE или контроль)

На бумаге существует множество красивых security подходов, НО которые совсем не учитывают operations специфику системы.

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

100 Methods for Container Attacks (RTC0010) – сборник команд и утилит, которые будут полезны при пентесте Kubernetes. В центре внимания утилиты kube-hunter и trivy, о которых мы не раз говорили в канале.

Что интересно, помимо привычных техник, затрагиваются и такие как Data Destruction и Resource Hijacking. Судя по всему авторы плотно прошлись по всей матрице MITRE ATT&CK.

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

Совсем скоро мы расскажем о своём образе для проведения аудита Kubernetes кластеров. Доклад уже принят на конференцию и как только появится официальный анонс мы обязательно об этом сообщим ;)

Изучили с командой две последние вредоносные находки/атаки/малвари нацеленные на облачные окружения (и не только):
1) "HeadCrab: A Novel State-of-the-Art Redis Malware in a Global Campaign" - вектор банален: Redis без аутентификации, смотрящий в интернет. Во вредоносной логике тоже нет как по мне никакого State-of-the-Art. Есть только забавный момент, что если код понимает, что он в контейнере, то он не пытается там даже закрепиться)
2) "PyLoose: Python-based fileless malware targets cloud workloads to deliver cryptominer" - точка входа это торчащий наружу Jupyter Notebook сервис.

Так оба вредоносного кода для реализации fileless техники используют memfd. При этом как вы понимаете все равно есть та часть, которая сначала грузиться в тот же контейнер, что-то делает, подготавливает и затем уже скачивает эту вот fileless часть. У вас или у вашего SOC вопросы должны уже появляться на 1 шаге, не говоря уже о том, что при наличии NetworkPolicy можно вообще сделать так что это вообще не состояться.

Начинаем эту неделю с атакующей тематики, а именно со статьи The CoreDNS Cache Poisoning Conjecture. Автор проходится по исходному коду CoreDNS и расказывает как он может быть подвережен атаке cache poisoning. Кроме того, из статьи вы узнаете как митигровать риски от такой атаки.

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

Материалов по сетевым атакам в Kubernetes довольно мало, однако этот интересный вектор не стоит упускать, ведь он вполне имеет место быть.

На протяжении всей моей карьеры мне всегда нравилось быть на стыке практической и академической безопасности и брать лучшее из этих двух миров. Тут на глаза попался академический пейпер "Secrets Revealed in Container Images: An Internet-wide Study on Occurrence and Impact" в котором исследователи очень интересно и системно подошли к анализу наличия секретов в образах контейнеров. Они проанализировали:
- 337,171 образов c Docker Hub и 8,076 с private registries
- 1,647,300 слоев суммарно

Результаты можете видеть на скриншотах. Отмечу что вся методология расписаны и даже даны все regexp по которым они искали. В конце авторы также дают свои рекомендации как правильно работать с образами и секретами. Мне очень понравилось 2 момента:
- Как и сколько авторы нашли private registries и что там можно было все скачать и даже залить/отравить вредоносный образ
- Как авторы даже проверили часть найденный секретов и они были рабочими ;)

Не поленитесь и почитайте работу полностью)

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

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

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

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

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

Копаясь в недрах 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 и стартуют до основных контейнеров и не мешают их завершению!

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

Начнем эту неделю с одного занимательно, малоизвестного факта о 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. Отдельно отмечу, что в этом сам Kubernetes не виноват, он сам выступает же, по сути, как среда выполнения. Но его слабый контроль и настройка приводят уже к вещам о которых напишем далее.

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

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

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

k8s (in)security pinned a photo

Интересная статья с официального блога под названием "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 is a cloud operating system" проводит параллели Kubernetes c операционными системами. Это как просто интересно, так и может быть полезно тем кто только погружается в данную тему.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тут внутри нашей команды открыли для себя новую конференцию 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. Все видео можно посмотреть тут.

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

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

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

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

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

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

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