"Container security fundamentals part 6: seccomp" – шестая статья из цикла статей [1,2,3,4,5] про безопасность контейнеров от Rory McCune.

В ней рассматривается как с помощью seccomp фильтров (они кстати написаны на BPF) можно ограничить какие системные вызовы (syscalls) можно вызывать из контейнера, а какие нет. Тоесть этот механизм у нас больше не про изоляцию одних процессов на хосте от других, а про изоляцию контейнерных процессов от хоста. Это на пример поможет позволить не совершить легкий побег из контейнера! На скрине пример с unshare, о котором мы уже не однократно рассказывали.

Вчера прошла онлайн конференция eBPF Summit 2023. Программа конференции достаточно обширная, но если говорить про security доклады, то это:

- Minifying Containers with SlimToolkit and eBPF Leveraging Tetragon's File System Activity Tracing
- Detecting and Preventing Stack Pivots in Linux Userland Programs Using eBPF
- How to use eBPF as a solution to Observe and optimize applications for endpoint security

Вместе с тем, на eBPF Summit 2023 проходит CTF. Если вы хотите порешать таски, можно поднять их локально у себя отсюда.

Сами доклады уже доступны, запись трансляции можно посмотреть здесь.

В нашем решении компонент сенсора (у нас собственная разработка, а не какой-то OpenSource проект) использует данную технологию и наша команда с большим интересом следит за данным мероприятием!

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

Встречайте MagicHappens Kubernetes Operator!

Его идея до безобразия просто и беспощадна: в CustomeResource (тоесть в YAML) в текстовом поле описываем человеческими словами какие Kubernetes ресурсы мы хотим получить и все. Далее это попадает OpenAI (под капотом еще есть проект Kopf) и результат уже в Kubernetes API.

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

P.S. "Создай Deployment для образа registry.corp.ru полностью соответствующий требованиям Pod Security Standard и с установленным default seccomp profile" - как-то так джун DevOps будет работать в будущем!

P.S.S. Мидл DevOps результат полученный на предыдущем шаге отправит на проверку другой AI системе ;)

На прошедшей в августе конференции OFFZONE был доклад, который мы не могли оставить без внимания – Как скрыть свои действия, когда отслеживается каждый шаг (Иван Гаврилов, Innostage).

В своем докладе Иван рассмотрел сильные и слабые стороны технологии eBPF для задач безопасности, а также возможные методы сокрытия своих действий на примере существующих eBPF‑based-инструментов безопасности для Kubernetes – Tetragon и KubeArmor.

Как итог – автору удалось обойти обнаружение всех видов событий (процессы, файловые и сетевые) при определенных условиях:

- передача в качестве аргумента utf-8 символа
- запуск бинарника с большим путём
- запуск процесса с большим количеством аргументов

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

21 сентября на онлайн-конференции про IT-инфраструктуру для бизнеса Selectel Tech Day наша команда в лице Дмитрия Евдокимова представит доклад “ZeroTrust в Kubernetes: Не пустые слова”. Там рассмотрим насколько сложно или не сложно построить ZeroTrust в Kubernetes c примерами атак и защиты.

Регистрация на мероприятие бесплатная.

Kubernetes может быть не только в контексте серверных приложений, но и безопасности рабочих мест пользователей!

Проект kVDI это Virtual Desktop Infrastructure запущенная на Kubernetes. Возможности:
- Контейнерезированный пользовательский "desktops" без требований к виртуализации
- Шифрование трафика между конечным пользователем и "desktop" контейнером
- Возможность персистентности пользовательских данных
- Поддержка воспроизведения аудио, микрофона
- Передача файлов с/на "desktop" сессию
- RBAC система для мапинга пользовательского доступа
- Поддержка MFA
- Использование локальной аутентификации, LDAP или OpenID
- UI для управления системой

Получаем эфемерное рабочее место, которое в любой момент времени можно развернуть, убить и создать с чистого листа! Отдаленно напоминает идею Google ChromeOS с ее множеством уровней изоляции и облачной идеологией.

P.S. И да, компании уже сейчас начали пилотировать такой подход у себя ;)

Недавно встретили такое требование в DevSecOps концепции одной компании, которое звучит примерно следующим образом: "Автоматический запрет развертывания образов с определенными CVE и секретами". И если про проблемы с первым мы уже не раз писали и рассказывали [данный пост и в вебинаре "Patch management не поможет, фиксики не спасут"], то второй момент это что-то новое, что мы ранее не встречали. Давайте разбираться - имеет ли это какой-то смысл.

Если в образ попал секрет и этот образ уже лежит в registry, то можно уже констатировать факт, что секрет утек. Ведь все сотрудники, что могут пулить образы могут забрать как весь образ так и его конкретный слой. А в последствии извлечь все необходимое. То есть организовать такой канал утечки данных (помните о registry staging). Контроль этого в моменте развертывания, это какой-то узкий кейс, не решающий основную проблему, и несущий угрозу только в том случае если в образ потом кто-то попадет из вне. Плюс все те же проблемы, что и с CVE, которые могут привести к падению системы.

По правильному еще в pipeline должна быть соответствующая проверка образа и в случае ее не прохождения pipeline должен падать и образ не попадать в registry. Последней стадией в этом pipeline, это подпись образа, если только он прошел все чеки. А уже в моменте развертывания только проверка этой подписи ;)

Microsoft обновила "Threat matrix for storage services". Первая версия вышла 2 года назад и обновление получило много изменений и заслуживает внимания.

Reflector - это Kubernetes operator, предназначенный для мониторинга изменений в ресурсах (Secrets и ConfigMaps) и отражения изменений на зеркальных ресурсах в том же или других namespaces.

Для того чтобы указать источник (откуда будут скопированы данные) нужно добавить аннотацию вида reflector.v1.k8s.emberstack.com/reflection-allowed: "true" и reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "<list>" к ConfigMaps или Secrets

Если источник удален, то удаляются и автоматические зеркала. Также если отражение или автоматическое зеркалирование отключены или namespace автоматического зеркала больше не соответствует разрешенным namespace, автоматическое зеркало удаляется.

Оператор будет полезен как минимум при решении двух задач:

- Для обеспечения TLS в динамических окружениях проектов необходимо выписывать сертификат для ветки main каждого проекта и копировать Secret во все остальные неймспейсы этого проекта
- Уметь автоматически синхронизировать Secret из централизованного хранилища во все нужные Kubernetes-кластеры и выбранные внутри них неймспейсы.

Закончим эту неделю смешным постом от организаторов конференции "Стачка", где выступал наш коллега Андрей Ганюшкин с докладом про безопасность контейнеров)

Классно, креативно =)

В начале новой недели с удовольствием поделимся с вами слайдами с выступления "ZeroTrust в Kubernetes:Не пустые слова" нашей команды Luntry с одного из последних мероприятий!

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

Всем хорошей недели!

m9sweeper – OpenSource Kubernetes security платформа (а по факту интерфейс над несколькими проектами).

На данный момент закрывает следующие потребности и выводит результаты и графики по:

- Image scan (trivy)
- K8s CIS benchmark (kube-behch)
- K8s templates best practice (kubesec)
- PolicyEngine (OPA Gatekeeper)
- K8s pentest (kube-hunter)
- Runtime (Falco)

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

Исследователи из компании Quarkslab запустили цикл статей реверс Windows контейнеров и выпустили первую часть "Reversing Windows Container, episode I: Silo". Скорее всего 98% читателей данного канала врятли это пригодится в работе ... Но на наш взгляд концепция контейнеров будет развиваться активно и в ОС Windows, тем более с учетом активного развития в ней Windows Subsystem for Linux (WSL) картинка будет получаться очень интересная. Скорее всего все придет в итоге к гибридным системам совмещающем в себе лучшее из двух миров.

Так что познакомиться с данным циклом статей будет как минимум полезно ради общего развития (реверсерам так обязательно, это будет использовать малварь для обхода антивирусов и EDR - о таком уже писали тут). С французами из Quarkslab доводилось общаться на конференциях - крутые и материалы делают такие же.

Вчера для CNI Cilium вышло три CVE:

1) CVE-2023-41332 (DoS via Kubernetes annotations in specific Cilium configuration)
2) CVE-2023-39347 (Kubernetes users may update Pod labels to bypass network policy)
3) CVE-2023-41333 (Bypass of namespace restrictions in CiliumNetworkPolicy)

Две из трёх уязвимости позволяют злоумышленнику при определённых условиях обойти ограничения NetworkPolicy – причем как нативной (которую реализует сам Cilium), так и кастомной от Cilium.

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

- 1.12.14
- 1.13.7
- 1.14.2

Из статьи "Making Sense Out of Native Sidecar Containers in Kubernetes" вы узнаете как прям по шагам изменяется возможность/последовательность запуска и завершения контейнеров в Pod с учетом появления нового "типа" контейнеров, как sidecar (по сути нативная поддержка такого паттерна на базе init), в Kubernetes 1.28.

P.S. Визуализация данного процесса это отдельный вид искусства - Иван молодец ;)

Как правило, для уменьшения поверхности атаки и в целом для уменьшения размера образа используют distroless image. В таких образах нет ничего лишнего – только полезная нагрузка.

Но если всё таки появилась необходимость проверить сетевое взаимодействие (health check probe) изнутри такого контейнера – LProbe будет очень кстати. Для этого в Dockerfile нужно добавить строчку вида:

COPY --from=ghcr.io/fivexl/lprobe:0.0.6 /lprobe /bin/lprobe

И в K8s манифесте добавить exec для readiness и liveness probes:

command: ["/bin/lprobe", "-port=8080", "-endpoint=/readiness”]

P.S – Мы уже как-то рассказывали про инструменты, которые могут пригодится при работе с distroless контейнерами – один из таких Dive.

"Escaping the Google kCTF Container with a Data-Only Exploit" - классная демонстрация Data-Only эксплоита (это очень не простой и достаточно редкий трюк) для побега из контейнера в рамках Google kCTF! В качестве подопытного взята бага в многострадальном io_ring )

Любителям хардкора премного рекомендуем =)

KubeHound – новый инструмент, который поможет определить вам возможные attack path в вашем Kubernetes кластере.

Принцип работы тулзы довольно прост: сначала KubeHound собирает всю необходимую информацию через Kube API, вычисляет attack paths (Bad Pods, RBAC) от container escape до возможного lateral movement и складывает результаты в графовую БД JanusGraph. Тулза может быть полезна как для Red так и для Blue team – на данный момент инструмент поддерживает около 25 запросов, однако авторы обещают добавлять новые.

Стоит отметить, что инструмент в своём большинстве закрывает только вопросы PodSecurityStandards, и никак не учитывает при построении attack path NetworkPolicy, AppArmor и прочие нюансы, которые могут влиять на конечный attack path.

Для более глубокого погружения рекомендуем ознакомиться со следующими источниками:

- заметка в блоге
- официальный сайт утилиты

На недавно прошедшей конференции по безопасности BalCCon2k23 был представлен доклад "Security in Cloud Kubernetes Services: Attacking and Defending Cloud" (видео) от Miguel Angel Hernandez Ruiz и Marios Kourtesis. Как пишут в описании доклада сами автора: "Our main goal with this presentation is to show some of the most common attack scenarios weaponised by cybercriminals which are affecting Cloud Kubernetes Services. We will also offer some possible controls to mitigate those risks."

По сути же там нет ничего нового и вся его ценности в 2х больших live demo в консоли, где демонстрируется:
1) Побег из контейнера на хост
2) Закрепление в скомпрометированном кластере через использование Static Pod

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

Сегодня мы хотим поделиться с вами записью и слайдами доклада нашей команды Luntry в лице Канибор Сергея "Kubernetes Pentest All‑in‑One: The Ultimate Toolkit" с конференции OFFZONE 2023.

В докладе мы рассказали про docker образ, который призван упростить жизнь при проведении Kubernetes пентеста. Сам образ появился в результате проведения аудитов и обкатан в боевых условиях. В тоже время мы не забыли упомянуть и то, с какими реальными проблемами и ограничениями можно столкнуться при проведении пентеста k8s, а также поделились тем, как эти проблемы можно решить.

Сам образ MTKPI можно посмотреть тут.

P.S – уже думаем над тем как можно прокачать MTKPI ;)

Делали недавно исследовательский проект для клиентов и в процессе него пришлось закопаться в реализацию Default seccomp profile (известно также как SeccompDefault и RuntimeDefault) (последние изменения о нем писали тут 1,2,3,4,5) в Kubernetes. Для этого пришлось почитать исходный код Container Runtime: containerd и cri-o. Соответствующий код можно посмотреть тут:
1) Для containerd
2) Для cri-o
3) Для docker (moby)

Все-таки насколько они по-разному к этому подходят...
Отдельное внимание заслуживает их реализация и отношение к системному (многострадальному) вызову unshare (атаки с его участием 1,2). Но в default его, конечно, там и там нет.

С началом новой недели и читайте исходный код ;)