12-14 марта буду на DevOpsConf 2023 в Москве. Как всегда буду рад лично познакомится и пообщаться на тему безопасности контейнеров и Kubernetes! Найти меня будет очень просто по вот этой худи ;)

Не перестаю удивляться правилам Falco ... По крайней мере тем что идут из коробки (ПОМНИ 1,2,3). И вообще редко доводилось встречать чтобы их кто-то полноценно проверял (представляете их еще и проверять надо!!!) и тюнил под себя - обычно максимум сокращают набор этих правил, чтобы он ел меньше ресурсов)

И так, мы тут нашей R&D командой в рамках внутреннего исследования (подготовки для K8s pentest и параллельно улучшения собственной runtime защиты) взяли скачали последнюю версию Falco c последним набором правил. И на системе с ним запустили наш Luntry, уязвимый контейнер и в нем через ряд команд запустили нашего вчерашнего героя traitor - ничего не меняя в нем!

По итогу, мы на генерировали много аномалий по активности данного средства, а Falco создал 2 предупреждения уровня Error и Notice - при этом при желании можно и их обойти так как они не являются первыми стадиями атаки. Операции с доставкой, организацией запуска вообще не были обнаружены и мы для этого ничего не делали!

Очень сильно удивившись этому - мы полезли смотреть почему же так?! Оказалось что в последней версии из 76 правил около 20 выключены и требуют доп. настройки, ну а также очень глупые сигнатуры, которые мы невольно сразу смогли обойти (честно говоря в этом месте написать что-то толковое очень тяжело...). Но раскрывать всех карт не будем и может расскажем это в рамках какого-нибудь доклада ;)

В общем, классика проблем сигнатурных подходов в полный рост.

Пару дней назад, в блоге Kubernetes вышла статья – Forensic container analysis, которая по сути является продолжением статьи Forensic container checkpointing in Kubernetes, о которой мы писали ранее. В ней автор детально показывает как с помощью таких инструментов как checkpointctl, tar, crit и gdb, работать с checkpoint.

После создания снэпшота формируется tar-архив. Для получения высокоуровневой информации, достаточно тулзы checkpointctl, но если вы хотите полезть глубже, нужно распаковать архив. Внутри будет следующее:

- bind.mounts – содержит информацию о всех смонтированных директориях и файлах
- checkpoint/ – сам checkpoint, созданный CRIU
- config.dump и spec.dump – содержат необходимые метаданные для восстановления контейнера
- dump.log – содержит логи CRIU, записанные при создании checkpoint
- stats-dump – статистика дампа
- rootfs-diff.tar – файловая система контейнера

Данная статья будет полезна как forensic специалистам, так и тем кто хочет глубже погрузиться в тему контейнерного DFIR.

Помимо выполнения успешной атаки, целью любого злоумышленника является скрытие следов своего присутствия. В том числе скрытие активных сетевых подключений, например к пулу майнеров или C2 серверу.

В основном, инструменты, которые помогают это сделать используют хак с редактированием LD_PRELOAD библиотеки, при этом быстро и легко обнаруживаются. Команда Sysdig TRT заметила новый приём злоумышленников для избежания детекта сетевого взаимодействия.

Злоумышленники используют тулзу graphtcp, которая отличается от аналогичных инструментов тем, что позволяет перенаправлять трафик только от определённого процесса, маршрутизируя его через локальный прокси и используя при этом системные вызовы fork() и ptrace().

Инструменты злоумышленников постоянно развиваются и становятся все более и более изощренными. Поэтому полагаться только на сигнатуры для определения вредоносного поведения опасно и ненадежно.

Вышла статья "Container security fundamentals part 2: Isolation & namespaces" из цикла о котором я писал ранее. Опять же тут про базу - без которой никуда ... И на этот раз она посвящена всем имеющимся на текущий момент Namespaces и какую они роль играют в вопросе изоляции.

21 марта в Москве в онлайн и офлайн форматах пройдет VK Kubernetes Conf!

Как обычно среди докладов там будем много интересного как про сам Kubernetes, так и про его безопасность.

Я там также поучаствую в рамках кругло стола, где мы пообсуждаем «Тренды в разработке и безопасности». Скорее всего зароним там темы eBPF и WebAssembly как альтернативу docker контейнерам.

Ссылка на регистрацию тут.

P.S. Мое выступление с VK Kubernetes Conf 2021 можно посмотреть тут.

Top 10 most used policies for Kyverno – подборка самых популярных и часто используемых политик Kyverno. Несмотря на то, что Kyverno является маленьким кусочком в большом пазле (фреймворке) под названием Kubernetes, и в зависимости от окружения политики могут быть разными, вот некоторые из наиболее распространненных политик, которые часто используются в коммьюнити:

– Resource limits
– Namespace isolation
– Security context
– Image policies
– Network policies
– Labeling
– Pod affinity/anti-affinity
– Secrets management
– RBAC policies
– Compliance

Если вы хотели подробней узнать о Kubernetes SeriviceAccount Token, то эта статья для вас. В ней рассматриваются следующие аспекты:

– ServiceAccountToken это всего лишь JWT
– ServiceAccount Token Process Flow – как токен назначается и монтируется внутрь Pod
– Headers, Content и Signature – из чего состоит токен

Важно отметить, что начиная с версии Kubernetes 1.24 токены для Service Account не генерируются автоматически. Для их создания нужно использовать TokenRequest API.

О том, что может делать атакующий с правами на создание TokenRequest мы рассказывали ранее.

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

Всю прошлую неделю гремел кейс Dero Cryptojacking связанный с Kubernetes [1]. Как по мне там чего-то такого особо интересного нет - много где можно с этим ознакомиться...

НО извлечь урок и понять (еще раз) угрозу анонимного доступа (anonymous access к Kubernetes API) (через который атака и прошла) можно. Именно этому и посвящена статья "Let's talk about anonymous access to Kubernetes". А именно:
1) Принцип работы и назначение
2) Отключение данного доступа

Несколько дней назад было опубликовано три уязвимости в CNI Cilium:

1. Cilium-agent container can access the host via `hostPath` mount – если у атакующего существует возможность изменять используемые images в Workloads, подменив image в cilium-agent, он может получить доступ к директории /opt/cni/bin на Node через hostPath.

2. Cilium eBPF filters may be temporarily removed during agent restart – во время рестарта агента Cilium есть небольшой промежуток времени, когда eBPF функционал недоступен. В этот момент злоумышленник, например, обойти Network Policy.

3. Potential network policy bypass when routing IPv6 traffic – при определенных условиях Cilium может ошибочно присвоить source IP-адрес кластеру, идентифицируя внешний трафик как исходящий от хоста, на котором работает Cilium. Как следствие, это может привести к обходу Network Policy.

Уязвимости затграгивают разные версии, необходимые патчи уже выпущены. Самое время обновиться.

Наконец-то мои руки дошли до новых сетевых фишек/реализациях в Kubernetes, а если быть более конкретным то до двух проектов: Cilium Service Mesh и Istio Ambient Mesh. При этом хотелось с ними познакомиться параллельно, чтобы можно было производить сравнение их фич и подходов.

Начнем прям с очень верхнеуровнево сравнения:
- L4 в первом реализуется на eBPF, второй в компоненте ztunnel (есть также планы переноса в eBPF) - все катиться как DaemonSet
- L7 в первом реализуется в envoy из того-же DaemonSet, второй при необходимости может создать Waypoint proxy (под капотом envoy) на service account или на namespace

Видим что sidecar пропали. Но разработчики Istio говорят что sidecar-реализация продолжит развиваться и поддерживаться и совместима (насколько я понял) с новой реализацией - тоесть одновременно можно как использовать sidecar, так и нет.

Offensive инструментов для Kubernetes выходит не так много, так что как только я заметил его – не сразу решился рассказать о нём, а для начала попробовать его в деле. Сегодня речь пойдет о KubeDagger.

Сама тулза основана на ebpfkit – руткит, написанный на eBPF и предоставляющий огромные возможности для атакующего: obfuscation techniques, container breakouts, persistent access, command and control, pivoting, network scanning, Runtime Application Self-Protection (RASP) bypass. Более подробно о том как это работает авторы рассказали в своем докладе.

Но на самом деле не всё так радужно. Так и не понятно как его позиционируют сами авторы. Для работы большинства функционала нужен ряд capabilities – CAP_SYS_ADMIN, CAP_SYS_RESOURCE, CAP_NET_ADMIN и shared network namespace.

Часто такое встречаете в контейнере? Лично я нет.

Наш канал k8s (in)security сегодня отмечает День Рождение - 3 года !!!

Уже 3 года мы стараемся каждый будний день (хотя бы раз в день) Вас радовать/информировать/просвещать в вопросах информационной безопасности контейнеров, Kubernetes, DevSecOps. И просто делиться опытом и знанием нашей команды Luntry в этой области: как в разработке, защите, так и атаке!

Если вы хотите поздравить нас, то просто расскажите о нашем канале своим друзьям, коллегам и просто не равнодушным, и заинтересованным в данной теме в каком-нибудь своем чате или канале. Нам будет приятно, если больше людей будет заниматься данной темой и расти профессионально в данной теме. Чем будет больше увлеченных профессионалов в области, тем будет более продвинутой наша индустрия ;)

P.S. А у меня так вообще двойной праздник в этот день - также 2 года исполняется моему сынишке с чем я его и поздравляю =)

Эту неделю начинаем со статьи – Enhancing Kubernetes Security with Kyverno, RuntimeClass, and Kata Containers. В ней автор показывает как с помощью связки Kyverno[1], Kata containers[2] и RuntimeClass[3] можно повысить безопасность кластера Kubernetes.

Ещё по отдельности эти технологии обладают довольно мощным функционалом для security, но объединив их всех вместе можно получить ещё больше профита:

– Enhanced Security
– Greater Flexibility
– Developer and User Productivity

В конце статьи, в качестве примера приводятся две политики для Kyverno. Первая – mutate политика, принудительно проставляет kata RuntimeClass всем Pods запущенным в namespace test. Вторая – проверяет что все Pods с privileged или runAsRoot securityContext, используемые в namespace kube-system деплоятся через kata RuntimeClass.

Продолжаем тему сравнения Cilium Service Mesh и Istio Ambient Mesh.

Если обратить внимание на функциональные возможности, то они практически идентичные. Уверен, есть какие-нибудь нюансы, но и по структуре того где на каком уровне (L7,L4) что реализуется даже сходится. При этом оба на L7 используют Envoy как мы с вами знаем. Скорее отличия будут на L4.

Если вы уже эту тему копали вглубь, то делитесь в комментариях!

Kubernetes Network Policies Viewer – небольшой онлайн-инструмент, который может пригодиться во время ручного написания Network Policy для Kubernetes.

Да, инструмент сильно похож на Cilium Editor (о котором мы уже рассказывали), но и свои отличительные особенности у него есть. Тулза выдаёт наглядное представление о том, как будет работать описанная Network Policy. Бывает очень полезной, когда нужно проверить правильность работы множества сетевых политик.

Из минусов – поддержа только Native Network Policy и отсутствие возможности генерировать сетевые политики простым накликиванием (как это сделано в Cilium Editor).

В эту пятницу 31 марта выступлю на конференции True Tech Day (offlinе + online) от компании МТС в секции Cybersecurity с докладом "Безопасность контейнеров и Kubernetes".

Всегда очень приятно когда такие большие компании приглашают нашу команду Luntry выступить и поделиться нашей уникальной экспертизой в области безопасности контейнеров и Kubernetes.

Преза будет небольшой, но я там наконец визуализировал одну важную вещь по безопасности образов контейнеров, которой прям не терпится поделиться!

В рамках изучения Cilium Service Mesh и Istio Ambient Mesh (прошлые посты 1,2) я наткнулся на занимательную статью "Exploring Cilium Layer 7 Capabilities Compared to Istio". Там сравниваются не Service Mesh реализации, а L7 возможности стандартного CNI Cilium (v1.12) и sidecar реализации Istio. И из этой статьи можно узнать много всего интересного о деталях реализации CNI Cilium и Istio, а именно:
- L7 фильтрация в ресурсе CiliumNetworkPolicy реализована как расширение/фильтр (Cilium.L7Policy) для Envoy proxy
- Как выглядит/хранится L7 правило внутри CNI Cilium
- CNI Cilium использует для этого Envoy filter, а Istio использует RBAC filters из апстрима Envoy
- чем является identity в Cilium, как он вычисляется (база это IP, labels) и хранится (это никакой не криптографический приметив, а просто целое число). А в Istio для этого служит service account token - там вообще все сроиться вокруг сертификатов, что как вы понимаете надежнее

Также там поднимается вопрос/проблема, что при модели Envoy per Node ресурсов потребляется меньше, но в случае его отказа страдают сразу все микросервисы на Node. Есть и еще одна интересная проблема с Network cache-based identity, что как я написал выше используется в Cilium, но это заслуживает отдельной заметки ;)

На канале мы уже затрагивали [1,2] тему Kubernetes Validating Admission Policies, но сегодня появился еще один повод. В официальном блоге Kubernetes вышла статья – Kubernetes Validating Admission Policies: A Practical Example.

Несомненным плюсом данного механизма является то, что для валидации данные не отправляются на admissions webhook (как например это реализовано в OPA или Kyverno, или в любом другом Policy Engine), а сразу обрабатываются, под капотом Kubernetes. Ну и конечно же CEL, в качестве языка описания выражений для проверки будет сильно проще в понимании и освоении, чем Rego (тот, что используется в OPA Gatekeeper).

Для более детального погружения в тему советую ознакомиться с видео – Kubernetes Validating Admission Policy Changes The Game. В нём автор показывает практические примеры использования данной технологии, а также рассматривает её недостатки и преимущества.

В статьей "Could network cache-based identity be mistaken?" авторы демонстрируют проблему network cache-based идентификаторов, на примере, идентификатора который используется CNI Cilium и применяется для контроля NetworkPolicy. По итогу у них получается сделать так что NetworkPolicy применяется к микросервису не правильно и обходится!

Весь исходный код данной демонстрации доступен и можно повторить самостоятельно. Или посмотреть видео.

Все это может быть из-за не актуального состояния кэша, которое может быть связано с сетевыми проблемами:
- Network outage
- Cilium pod was down, during an upgrade
- Resource constraints that cause the agent to be slow
- Resource constraints that cause API server to be slow in sending pod events to Cilium pod
- Programming bug that cause the agent to crash
- и т.д.

P.S. Я думаю это открывает достаточно интересный простор для исследования =)