На конференции BlackHat USA 2020 было представлено исследование "Escaping Virtualized Containers".

В рамках данной работы исследователи проводили анализ Kata Containers (о котором я говорил в прошлом посте). По результатам их работы удалось совершить Container-to-Host Code Execution (побег) благодаря цепочки из 3-х уязвимостей:

- CVE-2020-2023 (Container-to-Guest)
- CVE-2020-2025 (CLH commits to VM image)
- CVE-2020-2026 (Mount Redirection)

Были найдены и другие уязвимости типа DoS. При этом авторы отмечают, что многое зависит от настроек runtime и то какими capability обладает контейнер. Есть ли там еще подобные уязвимости - точно да! Авторы говорят: "Shared Directory is a Big Attack Surface". MicroVM это не какая-то магия, а только ограничение attack surface через уязвимости ядра хостовой ОС. Есть и другие способы побега ;)

На мой взгляд с учетом изменений в версии 1.22 и грамотного подхода к capability и классические контейнеры дадут высокий уровень безопасности. При этом они также дадут и прекрасный уровень observability, того, что происходит внутри контейнера (когда MicroVM это blackbox). Выход из контейнера не самоцель для атакующего, он также может атаковать и другие сервисы оттуда (или майнить) и от этого MicroVM не защитит, а скорее затруднит обнаружение.

В индустрии ИБ сейчас многие ставят Detection и Response важнее, чем Prevention.

Крутая картинка со систематизацией Kubernetes Privilege Escalation! (Автор не известен.)

И Red team и Blue team это все очень полезно знать.

P.S. Сегодня на ZeroNights - буду рад пообщаться лично, пообсуждать Kubernetes ;)

Небольшой, но очень технический доклад "Cracking the kernel adventures with kernel exploits in Kubernetes" с большим количеством примеров и демо. MUST SEE!

Картинка: "Open source dependency feelings".

Вы уже наверняка сталкивались с таким выбором или просто не задумывались о втором варианте и всегда выбирали один из них =)

Не зря время это один из самых (если не самый) важных ресурсов, а еще с учетом высокой скорости жизни. В индустрии разработки это ощущается еще больше: Agile, time-to-market и т.д. Тут самое место вспомнить и про Supply Chain атаки (готовые библиотеки, образы, YAML ресурсы, HELM чарты,). На самом деле проверить все полностью невозможно. И как я уже не однократно писал в постах в индустрии на первое место выходят Detection и Response, обгоняя Prevention.

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

P.S. Планировал юмористический пост, а получился не очень ...
P.S.S. На следующем KubeCon + CloudNativeCon North будет уже отдельная секция SupplyChainSecurityCon! Рассписание и доклады уже опубликованы.

Cloud Native Security Map is LIVE!

Данный проект создан он на основе документа Cloud Native Security Whitepaper от SIG-Security. О данном документе я уже писал пару раз [1,2]. По сути, это маппинг разных популярных security инструментов на разделы данного документа. В оригинальном документе описываются только сами принципы, а примеры инструментов отсутствуют. Очевидно, что данный проект многим будут очень полезен.

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

P.S. Насколько я понимаю это первая публичная версия и авторы очень ждут feedback.

Сегодня хотелось бы всех познакомить с проектом Gatekeeper Policy Manager (GPM). Это UI для просмотра OPA Gatekeeper политик с их статусами, предупреждениями и т.д. По сути, со всеми Custom Resources, что привносит данный оператор.

Подобный проект для другого policy engine - Kyverno я рассматривал несколько дней назад здесь.

Определённо данные и подобные проекты многим позволят упростить использование policy engine в своих инфраструктурах и привлечь больше команд (Dev, Ops, Sec - зависит от того с чей стороны исходит инициатива) в своих проектах, что значительно большой плюс для построения надежного и безопасного Kubernetes кластера.

За последнее время появилось много статей про опцию SeccompDefault, появившуюся в версии 1.22. Данная опция меняет дефолтный seccomp профиль с Unconfined на RuntimeDefault.

На мой взгляд самыми полезными статьями являются:
1) "Enable seccomp for all workloads with a new v1.22 alpha feature" от специалиста из Red Hat с официального блога Kubernetes
2) "How to enable Kubernetes container RuntimeDefault seccomp profile for all workloads" от специалиста из Azure

В первой статье, упор больше идет на то, как это правильно включить и постепенно активировать во всем кластере без вреда вашим приложениям. Конечно, тут упоминается и Security Profiles Operator. Во второй статье, автор больше отвечает на вопрос: что такое этот RuntimeDefaults профиль и что он дает.

Интересные моменты:
- У каждого Container Runtime есть свой RuntimeDefaults профиль, и они отличаются
- Включать данную опцию можно постепенно или только на определенных узлах, а не на всем кластере
- Приложение на заблокированный syscall получит ответ EPERM хотя обсуждения есть и про ENOSYS

И замечательная цитата: "Developers, site reliability engineers and infrastructure administrators have to work hand in hand to create, distribute and maintain the profiles over the applications life-cycle."

P.S. Не забываем и про то что можно сделать и указать свой кастомный еще более строгий seccomp профиль

Неделю назад на сайте Service Mesh Istio вышла новая Security Bulletin под названием "Multiple CVEs related to AuthorizationPolicy, EnvoyFilter and Envoy". Речь в ней идет аж о 6 CVE и все они связаны с Envoy (который является частью sidecar):

1) CVE-2021-39156 (CVE-2021-32779) - bypass Istio’s URI path-based authorization policies
2) CVE-2021-39155 - potentially bypass an Istio authorization policy
3) CVE-2021-32777 - incomplete authorization policy check
4) CVE-2021-32778 - excessive CPU consumption
5) CVE-2021-32780 - Envoy to terminate abnormally
6) CVE-2021-32781 - Envoy accessing deallocated memory and terminating abnormally

То, что в Istio/Envoy есть уязвимости не удивительно и ни чего страшного - они есть у всех. Но осознавая, то, что для обновления требуется перезапустить все Pod'ы внутри которых есть sidecar, невольно задумываешься о простоте и удобстве ремонтопригодности той или иной технологии ...

P.S. А если еще задуматься где вообще Envoy применяется, то ...

Картинка смешная, а ресеч "Real Life Story of the 1st Mainframe Container Breakout" с конференции DEF CON 29 по мотивам данной картинки классный! Лично мне нравится, когда люди так креативно подходят к исследованиям.

Ситуация у них была следующая: "IBM zCX is a Docker environment running on a custom Linux hypervisor built atop z/OS - IBM’s mainframe operating system.", а итог побег (escape) на zCX хост.
Самое интересное (само исследование) начинается на 13:40. Основной рывок им дала возможность обращаться к Docker API по сокету /var/run/docker.sock из контейнера =)
Матрешка: Container -> Linux Docker Engine -> Linux kernel -> zCX - > z/OS. Как видно они добрались до предпоследнего уровня, но в планах дойти и до последнего - z/OS.

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

Недавно вышел достаточно увесистый отчет "Kubernetes Control Plane Vulnerability Assessment", в рамках которого аудиторы рассматривают, что и как может атакующий, получивший доступ к Node (на пример, через побег из контейнера).

Весь анализ происходит на K8s версии 1.21.0 и идет в разрезе темы multi-tenancy и безопасности Control Plane. Правда по факту тут они касаются только node-based multi-tenancy, а других подходов, что рассматривает сейчас рабочая группа не затрагивают.

По отчету есть небольшая запись в блоге "Looking at the Kubernetes Control Plane for Multi-Tenancy". Но по мне она совсем не передает сути работы и лучше читать оригинал - там много классных, тонких моментов для ценителей ;)

Ключевые слова по отчету это: Taints & Tolerations, Node Authorizer, NodeRestriction. Не знаете, что это и зачем нужно в security - читайте отчет и со всем разберетесь!

Вишенкой на торте является раздел "Threat Model".

Распределенная трассировка (Distributed Tracing) у многих ассоциируется только с сетевым взаимодействием собственных сервисов, за которыми идет наблюдение, ну и, конечно, с решениями Jaeger, Zipkin, OpenTelemetry.

Но со временем все больше интересных возможных применений находят трассировке. И сегодня хочется рассказать о ряде таких:
1) В Kubernetes v1.22 в alpha стадии добавили API Server Tracing, который позволяет замерять и смотреть как выполняется та или иная активность на API Server.
2) Проект kspan, позволяющий представлять Kubernetes Events в виде spans и также наблюдать за работой Kubernetes.
3) Работы в духе "Detecting Cyber Security Attacks against a Microservices Application using Distributed Tracing" для обнаружения аномалий связанных с нарушением безопасности.

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

В продолжение моего недавнего поста про безопасность при node-based multi-tenancy - в официальном блоге Kubernetes вышла статья "Advanced Kubernetes pod to node scheduling"

В ней очень просто, понятно с примерами рассматриваются такие Use Cases для Pod-to-Node Scheduling, как :
- Running pods on nodes with dedicated hardware
- Pods colocation and codependency
- Data Locality
- High Availability and Fault Tolerance

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

В статье рассматриваются следующие механизмы и стратегии:
- nodeSelector
- Node Affinity
- Inter-Pod Affinity
- Taints and Tolerations
- Pod Anti-Affinity

Вообще за последнее время вышло много статей по данной теме и можно сказать, что это какой-то тренд или нет ;)

И еще раз продолжая тему распределения рабочих нагрузок (Pod) по Nodes, рассмотрим ситуацию когда нужно чтобы нагрузка выполнялась на Nodes с определенными устройствами. На пример, таких как FPGA, GPU, high-performance NICs, InfiniBand adapters, что очень актуально при текущем развитии и распространённости машинного обучения (ML). Но не все хорошо сейчас в этом направлении (там каждый кто во что горазд) ...

И вот, рабочая группа Container Orchestrated Device (COD) сейчас работает над Container Device Interface (CDI), которая является спецификацией для container runtimes, для поддержки разных сторонних устройств через общепринятую, понятную всем систему плагинов. По сути, это продолжение линейки: CRI, CNI, CSI, SMI, CPI.

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

Легкий пятничный пост.

Те, кто занимаются пентестами и имеют дело с Linux и Windows окружениями определённо должны знать о таких проектах как:
- GTFOBin для Linux
- LOLBAS для Windows (есть даже drivers)

Это набор/список/перечень легитимных исполняемых файлов, библиотек, скриптов, которые можно использовать для атакующих целей: что-то скачать и выгрузить, выключить, обойти, спрятать, поднять привилегии и т.д. При этом как вы понимаете сигнатуру/правило на это написать, конечно, можно, но нужно будет часто фильтровать от нормального использования ;)

Так вот пользователь twitter подметил, что всеми нами любимый kubectl с флагом --raw отлично подходит для замены тех же curl и/или wget, если их нет под рукой, и отлично подходит для пополнения данных проектов!

Месяц назад гремела новость про "Kubernetes Hardening Guidance" от NSA (и я об этом писал), затем все писали про инструмент Kubescape для проверки по данному гайду (я об то не писал).

И пока совсем без внимания остается статья "NSA & CISA Kubernetes Security Guidance – A Critical Review" от известной security компании. Статья состоит из 3-х частей: что хорошего, что плохого и что забыто в данном гайде.

На том что там хорошего - останавливаться не будем, лишь процитирую авторов по этому поводу: "Each of these points relate back to the generic guidance for almost any platform, regardless of the technology in use"

Про плохое (страдает точность, актуальность и полнота):
- PSP Deprecation - про данный факт ни слова.
- Admission Controllers - практически не упоминаются, хотя это мощнейший инструмент k8s.
- Inconsistencies/Incorrect Information - опечатки/неточности про порты.
- Authentication Issues - ошибка что в k8s нет аутентификации по умолчанию.

Последнюю часть характеризует цитата: "With a project as complicated as Kubernetes, it is not possible to cover every option and every edge case in a single document, so trying to write a piece of one size fits all guidance won’t be possible. "). То есть там авторы говорят о том, что вообще не было рассмотрено в документе:
- Levels of Audit Data
- Sidecar Resource Requirements
- External Dependencies are essential
- RBAC is hard
- Patching Everything is hard

Много шума наделал статья "Finding Azurescape – Cross-Account Container Takeover in Azure Container Instances"

Кратко:
- Используя данную проблему вредоносный пользователь может выйти из своего окружений и попасть в соседние окружения других клиентов облака
- Дело касается Azure Container Instances (ACI) это CaaS/serverless от Microsoft
- У Microsoft реализация ACI есть на Kubernetes и Service Fabric Clusters, проблему удалось проверить только в первом случае
- В реализации на Kubernetes для размещения клиентов использовался node-based multi-tenancy подход
- Azure Kubernetes Service (AKS) мог пострадать только в том случае, если он интегрирован с ACI
- Атака: 1) Побег из контейнера через 1-day уязвимость CVE-2019-5736 в runC 2) получение доступа к privileged Kubernetes service account token 3) выполнение команд на Kubernetes api-server
- На первом шаге использовали контейнер WhoC, который позволяет прочитать и отправить исполняющий его container runtime
- На втором шаге исследователи поняли, что им доступен service account token, который имеет права на pods/exec в любом namespace, включая kube-system
- На третьем шаге исследовали просто получили shell в контейнере Kubernetes api-server - Game Over!
- Также исследователи нашли возможность получить shell в контейнере Kubernetes api-server через SSRF ;)

После прочтения я большое всего в шоке от того что в этой части облака (непонятно как в других) использовался runC 2016 года и Kubernetes от ноября 2017 - октября 2018 ...

На YouTube стали доступны видеозаписи с Cloud Village 2021 с конференции DEFCON 29. Про Kubernetes там есть:
- Kubernetes Goat - Kubernetes Security Learning
- Kubernetes Security 101: Best Practices to Secure your Cluster

Ну и, конечно, много всего про AWS, GCP и Azure =)

Также обратите свое внимание на доклады с Blue Team Village 2021 с той же конференции. Там также есть про облака и про их защиту. Мой взгляд там зацепился за доклады:
- A SERVERLESS SIEM: DETECTING ALL BADDIES ON A BUDGET
- I know who has access to my cloud, do you?

CVE-2021-25741: Symlink Exchange Can Allow Host Filesystem Access

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

Пользователь может создать контейнер с subpath volume смонтированным с доступом к файлам и директориям за пределами volume, в том числе к хостовой (Node) файловой системе. По сути, это приводит к container escape.

Эксплуатация позволяет hostPath-like доступ, без доступа/использования к hostPath фичи, тем самым обойти данное ограничение если оно используется в вашем окружении.

Уязвимость находиться в kubelet и не зависит от container runtime.

Нужно обновится до соответствующих версий, а если это у вас невозможно, то можно отключить VolumeSubpath feature gate на kubelet и kube-apiserver, и удалить все существующие Pods созданные с использованием данной фичи. А также admission control (policy engine) для предотвращения создания таких Pods, а также их backgroud scan для обнаружения.

Уязвимые версии:
- v1.22.0 - v1.22.1
- v1.21.0 - v1.21.4
- v1.20.0 - v1.20.10
- <= v1.19.14

Более подробных деталей по эксплуатации данной CVE пока отсутствуют. Но судя по описанию, атакующий должен контролировать содержимое образа и соответствующим образом через symlink добиваться доступа за пределы volume.

Backups in Kubernetes.

Наверняка вы знаете или по крайне мере слышали о таких бесплатных решениях как Velero и K8up (Kubernetes Backup Operator) нацеленных на Kubernetes cluster resources и persistent volumes.

Если такие темы как:
- Disaster recovery
- Backup and restore
- Local high availability

Я еще как-то могу понять, то защита от ransomware атак (шифрование данных с целью получения выкупа за них) в Kubernetes мне уже кажется полностью тут притянута за уши определёнными вендорами коммерческих решений.

Интересно узнать, а как вы смотрите на тему backups в Kubernetes?

Threat Hunting with Kubernetes Audit Logs

Серия из двух частей "Analyzing Kubernetes audit logs to look for potential threats" и "Using the MITRE ATT&CK® Framework to hunt for attackers".

В первой статье идет база:
- What is threat hunting?
- What are Kubernetes audit logs?
- Why are audit logs important?
- What does an audit log look like?
- Let’s Hunt! (на что и как стоит обращать внимание - по сути как правильно интерпретировать лог)

Во второй статье рассматривают как на каждой стадии MITRE ATT&CK® Framework можно строить гипотезы и проверять их - в принципе полезная вещь.

Странно что в статье совсем не упомянут трюк с детектом обращения к ресурсам/API SelfSubjectAccessReview и SelfSubjectRulesReview, что является результатом работы команды kubectl auth can-i. Атакующий же не знает, что может захваченный им token ;)

Очень часто в статьях про K8s каждый механизм ИБ рассматривается в отрыве от остальных (а их в K8s очень много) и может сложиться не верная картина по работе с безопасностью в k8s (а она отличается от классических систем сильно). Я люблю рассматривать это все комплексно, а с учетом того, что Kubernetes Audit Logs вообще мало кто активирует, из-за увеличения нагрузки на API server, это еще более актуально.

Чтобы с минимизировать нагрузку я рекомендую использовать:
- GitOps operator
- PolicyEngine
- Минималистичную AuditPolicy

P.S. Кто-нибудь проводил замеры на сколько увеличивается нагрузка на API Server при работе Audit Logs или видел соответствующие работы на эту тему?

На недавно прошедшей конференции fwd:cloudsec 2021 было 2 доклада, напрямую затрагивающих безопасность Kubernetes:
1) Kubernetes Security: PSP deprecation is an opportunity for a new security model
2) Least-Privilege Kubernetes Authorization with OPA

Первый доклад совсем базовый и как по мне ничем не примечательный, а вот второй очень интересный и представляют собой рассказ о том как ребята в своей компании с помощью policy engine и собственных кастомных ресурсов (YAML) закручивали гайки и реализовывали принцип наименьших привилегий при авторизации. При этом они выходят за рамки стандартной RBAC и могут базироваться на произвольных метаданных (на пример, labels). Таким образом они могут давать доступ, основываясь, например, на отделах/командах сотрудников, типах/классах сервисов и т.д.