Замечательная исследовательская статья "Abusing Registries For Exfil And Droppers", которая показывает, как пентестеры и злоумышленники могут использовать image registry для:

1) Arbitrary Blob Storage - использовать как секретное место хранения для чего-либо.
2) Exfiltration channel - использовать как канал коммуникации между различными средами и извлечения информации из инфраструктуры.

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

Для проведение данных манипуляций можно использовать инструменты dxf и scopeo.

В заключении статьи без внимания не остается и вопрос защиты с помощью Garbage Collection и Logging действий.

Продолжим атакующую тематику.

Если вы задавались вопрос что такое в Threat matrix for Kubernetes в тактике Persistence означает техника Malicious Admission Controller, то статья "Creating Malicious Admission Controllers" даст вам короткой и простой ответ, да еще с примером кода на Go ;)

Да, это уже post-exploitation фаза и атакующему вообще не всегда требуется закрепляться в чужой инфраструктуре, но это возможно и делается не сложно. При этом если мне не изменяет память, то ни одно средство защиты для Kubernetes на текущий момент вообще не смотрит за наличием/появлением MutatingAdmissionWebhook. И это по идее не удивительно - сигнатуру на это не напишешь, а по умолчанию это ничего плохого не означает - те же Istio, Linkerd, Kyverno используют данный механизм.

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

sk8s game !!!

Не бойтесь ничего нового, учитесь, развивайтесь и все вам будет по плечу ;)

Всем хорошей пятницы и выходных!

CVE-2021-25742: Ingress-nginx custom snippets allows retrieval of ingress-nginx serviceaccount token and secrets across all namespaces

Уровень: High (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L)

Пользователь в Kubernetes с правами на создание Ingress ресурсов, может создать его со специально заданным custom snippet и получить доступ к serviceaccount token от ingress-nginx, а далее с его помощью уже получить доступ ко всем секретам во всех namespaces (при условии дефолтного RBAC у ingress-nginx). Ну естественно можно и другие вещи творить с этим serviceaccount token.

Оказывается (я лично не знал) в аннотациях custom snippet пользователь может задать произвольный код, который будет выполнен Nginx через Lua!

Это наиболее критично для multitenant окружений, где non-admin пользователи имеют права на создание Ingress ресурсов.

Для защиты надо:
1) обновить ingress-nginx до версии >= v0.49.1 или >= v1.0.1
2) выставить allow-snippet-annotations в ConfigMap в значении false

На счет эксплуатации пишут, что она: "Exploitation isn't that difficult, just takes a little fiddling."

Пентестерам (на самом деле и не только) на заметку статья "Как открыть TCP-/UDP-сокет средствами командной оболочки bash". Может быть полезно, когда попали в контейнер и нужно поработать с сетью, а любимых netcat, curl и wget нет и поставить нельзя ...

На помощь идут файловые устройства /dev/tcp и /dev/udp ;)

А если вы хотите не оставлять такую лазейку в своих контейнерах с bash внутри, то надо собрать его без флага --enable-net-redirections.

Интересно, а многие еще собирают образы в Kubernetes через проброс docker.sock unix socket внутрь контейнера или все уже перешли на Kaniko?)

А если вас удивляет сама постановка такого вопроса и что в этом плохого, то рекомендую почитать статью "Building Docker Images in Kubernetes Using Kaniko".

P.S. Или вам ближе buildah, BuildKit, BuildPacks, Img, PouchContainer?

P.S.S. Удобный скрипт kubectl-build

Если вы планировали провести эти выходные с пользой, то как раз для вас CNCF выложил записи докладов с недавно прошедших своих сессий KubeCon + CloudNativeCon North America 2021:

- KubeCon + CloudNativeCon North America 2021
- Cloud Native Security Conference North America 2021
- EnvoyCon North America 2021
- SupplyChainSecurityCon hosted by CNCF + CDF 2021
- Production Identity Day: SPIFFE + SPIRE North America 2021
- Cloud Native eBPF Day North America 2021
- GitOpsCon North America 2021
- Cloud Native DevX Day North America 2021
- ServiceMeshCon North America 2021
- Kubernetes AI Day North America 2021
- Cloud Native Wasm Day North America 2021
- FluentCon North America 2021

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


P.S. Такой же playlist с KubeCon + CloudNativeCon Europe 2021

Так как я занимаюсь не только темой security, но и observability, которая позволяет и ту же security строить от себя (а не от возможностей атакующих) и повышать realibility, и упрощать troubleshooting - тема организации приложений (applications) в Kubernetes кластере мне очень интересна.

Разработчик пишет код, который далее упаковывается в контейнер и обворачивается в Kubernetes ресурс. Для разработчика может быть workload минимальной единицей приложения и его зоной ответственности. Когда для SRE это может быть набор workloads с определенными метками.

Две статьи на эту тему “The Guide to Kubernetes Labels” и “Recommended Labels”.

При этом, общаясь с разными компаниями, я вижу очень разные картины (двух одинаковых компаний не встретить). У кого-то для выделения приложений используются отдельные namespaces, у кого-то это специальная annotations или labels.

Как вы у себя выделяете и управляете приложениями?

Неожиданно для себя обнаружил, что 4 дня назад закончилась поддержка Kubernetes 1.19 (как летит время) и сейчас поддерживаются только 1.20, 1.21 и 1.22.

Чтобы это не было неожиданностью, можно использовать проект endoflife.date, который отслеживает актуальность версий более 60 проектов, включая Kubernetes.

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

Все чаще сталкиваюсь с вопросом у клиентов: "Как сделать Kubernetes кластер, чтобы он соответствовал PCI DSS?"

Я уже эту тему немного поднимал [1,2,3], но со временем понял, что лучше всего это знают большие компании с большим количеством клиентов, а следовательно, и опытом в этой области. А кто под это подходят? Конечно, облачные провайдеры с managed Kubernetes! По сути, можно не ломать голову и не придумывать ничего с нуля, а подсмотреть как они к этому подходят и перенять к себе.

Так вы можете с этим ознакомится в их мануалах и документах:
- "PCI DSS compliance on GKE"
- "Architecting Amazon EKS for PCI DSS Compliance"
- "Introduction of an AKS regulated cluster for PCI-DSS 3.2.1"

P.S. И не забываем также о классном проекте Compliance Operator ;)

Коротенькая блоговая запись с говорящим названием "Fun with CRDs - Overwriting core types".

Вы, наверное, уже поняли автор задался вопросом что будет если создать с помощью CRD тип ресурса из Core API. В качестве пример автор берет ресурс NetworkPolicy из networking.k8s.io.

Как по мне хорошая и легкая тема для этой пятницы ;)

P.S. Спойлер: Core API нашего любимого Kubernetes вы не сломаете, но вот часть инструментов, работающих с ним вывести из строя можно =) Так что следите за тем кому вы даете в RBAC возможность создавать CRD.

Нашел очень достойную подборку разных техник побега из контейнера с примерами и описанием, среди которых:
- CVE (уязвимости container runtime и linux kernel)
- Exposed Docker Socket
- Excessive Capabilities
- Host Networking Driver
- Sensitive Mounts

Это актуально и для Kubernetes. Для пентестеров будет полезно знать, как можно нарушить изоляцию контейнеров, а для security team, что надо харденить.

Совсем недавно пришлось немного поработать с таким Container Runtime для Kubernetes как kata-containers. Если кто не слышал о таком, то его отличительной чертой является то, что вместо классического Linux контейнера, он запускает microVM и базируется на Kernel-based Virtual Machine (KVM).

Что важно о нем знать:
1) На выбор он предлагает аж 4 hypervisor: ACRN, Cloud Hypervisor, Firecracker и QEMU.
2) Если хотите с этим работать в VM (касается сразу всех managed Kubernetes), то должна быть активирована nested virtualization. И этого я не нашел ни у кого в managed k8s услугах.

Как можно поиграться с этим дома на VM или на bare metal в AWS или GCP можно посмотреть в статье "Setting up a Development Environment for Firecracker".

Так что будьте внимательны если засматриваетесь на данный Container Runtime и помните что можно работать сразу с несколькими рантаймами.

P.S. Напомню про пост про побег из Kata ;)

Это прошло как-то мимо меня, но у Falco появился конкурент в лице инструмента Tracee, который также базируется на eBPF и на правилах. Правила только пишутся на языке Rego (тот же что используется и в OPA).

О запуске в Kubernetes можно почитать в серии статей [1,2]. Правил пока немного и по мне они пока более простые, но при этом смапленные на "MITRE ATT&CK".

Хотя правила такие же бестолковые и требуют хорошей ручной доработки (которую все равно можно легко обойти). На пример, правило про K8S Service Account Token, требует, чтобы вы прописали все имена процессов, которым это разрешено. Для обхода достаточно залить свой файл с именем kube-proxy или coredns =) Есть правила которые почти как под копирку взяты из Falco - на пример про shell [1,2].

Также есть собственная утилита для алертинга Postee, аналог Falcosidekick. При этом можно сообщения слать сразу на второй, что может упростить использование этих двух решений одновременно, если кто-то так захочет.

На просторах GitHub нашел наиинтереснейший проект с Jupyter notebooks для Kubernetes Security trainings!

Описание самого тренинга можно посмотреть в этом файле и состоит он из трех частей:
- Introduction
- Networks
- Hardening Kubernetes

Все происходит в Jupyter notebooks (это бомба) и крутиться на minikube. Несколько сценариев можно посмотреть в вебинаре автора "Kubernetes Security: Hacking Containers". Там он, на пример, показывает (достаточно своеобразно) как можно обойти ограничения Istio Egress Control, через переопределение iptables (как тут).

В общем, если хотите дома просто попрактиковаться в безопасности Kubernetes это хороший старт!