k8s (in)security

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

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

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

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

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

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

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

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

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

Эту неделю начинаем со статьи – 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.

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

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

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

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

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.

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

Наконец-то мои руки дошли до новых сетевых фишек/реализациях в 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, так и нет.

Несколько дней назад было опубликовано три уязвимости в 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пару дней назад, в блоге 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.

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

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

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

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

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

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

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

- gtfobins
- pwnkit
- dirty pipe
- +w docker.sock

Удобно, что при запуске с параметром -a, находятся все возможные мисконфиги и эксплуатируется каждый из них, пока не будет получен шелл. Использование данного инструмента может быть полезно и при нахождении в контейнере.

И тут я понял что еще не все темы по безопасности контейнеров осветил на канале .... Хотя думаю что это что-то про это будет =)


Спасибо читателю каналу за наводку)

P.S. Опечатка или крутой маркетинговый ход?)

Один из постоянных читателей данного канала написал и поделился своей заметкой под названием "Certified Kubernetes Security Specialist — мой опыт сдачи экзамена". Не сложно догадаться что там он делиться своим свежим опытом (февраль этого года) получения сертификата CKS.

Думаю для тех кто думал о таком это полезно + есть возможность какие-то моменты если что уточнить у автора в комментариях =)

P.S. Если вы пишите, создаете что-то по теме безопасности контейнеров, безопасности Kubernetes - присылайте!