Закончить неделю хотелось бы некоторыми своими размышлениями (не очень радостными), навеянными собственным опытом и общениями с коллегами по индустрии. Речь пойдет про инциденты безопасности в 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.

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

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

Материалов по сетевым атакам в 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 можно вообще сделать так что это вообще не состояться.

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

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

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

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

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

И так, что же может пойти нет?!
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 уязвимостей (это даже не реально), а в том чтобы обеспечить непрерывность работы бизнеса и не возможность атакующим реализовать бизнес угроз.

Создатели Policy Engine Kyverno решили составить конкуренцию не только OPA Gatekeeper (с этим они уже отлично справляются), но и OPA! А именно проверять не только ресурсы Kubernetes, но и в принципе любые JSON =)

В статье "Experimental Generic JSON Validation with Kyverno" они показывают, как этого можно сейчас добиться (все это пока очень экспериментально). Подробнее можно еще посмотреть выложенный проект json-validator. Так сам Kyverno по-прежнему должен запускаться внутри Kubernetes, но при этом доступен из вне, чтобы можно было к нему обратиться на прямую. Так же как и ранее это можно проворачивать в pipeline с помощью Kyverno CLI.

Как основной use case авторы заявляют, что так можно проверять конфигурации и настройки сервисов, что располагаются рядом с Kubernetes и связаны с ним.

На прошедшем Steelcon 2023 Rory McCune и Iain Smart провели свой 4-х часовой воркшоп – Container Security and Hacking with Docker and Kubernetes. Наверное, это один из самых больших сборников по безопасности контейнеров и Kubernetes. Воркшоп включает в себя следующие темы:

- Container Basics
- Docker Security
- Kubernetes Fundamentals
- Kubernetes Security
- Kubernetes Networking
- Kubernetes Distributions
- Container Secirty Problems/Challenges

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

И продолжим тему обучений.

Недавно проводили обучение архитекторов (специально модифицированное под их задачи) одной из команд "Ростелеком-Солар" и они по результатам как нашего тренинга, так и вообще подготовки своих специалистов написали статью "Погружаемся в тему защиты контейнеризации, или как обучить тому, чему нигде не учат".

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

В официальном блоге Kubernetes вышла занимательная статья "Confidential Kubernetes: Use Confidential Virtual Machines and Enclaves to improve your cluster security", посвящённая теме концепции Confidential Computing (CC). По сути, это защита от облачного/инфраструктурного уровня - более конкретнее от работников дата-центров, привилегированных облачных админов и атакующих имеющих доступ к инфраструктуре, где работает ваше приложение/контейнер/кластер.

Это базируется на идее Trusted Execution Environments (TEEs) и в данном случае могут служить технологии AMD SEV, Intel SGX и Intel TDX (работает с кодом и данными идет в специальном режиме куда никто по сути больше не имеет доступ). Учтите, что Intel выпиливает SGX и на смену ему идет TDX.

Понятно дело, что это еще все имеет раннюю степень адаптации, но направление очень интересное и за его развитием нужно следить!

P.S. В следующих постах рассмотрим конкретные примеры проектов.

Продолжим тему 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) (на картинке). Это должно позволить упросить общение микросервисов из разных кластеров. Если вам интересны реализации, то их можно посмотреть тут.