Пентест, Kubernetes. У многих отсутствует представление о том, как это вообще выглядит. Хотя это очень полезно и пентестерам (для них это становится актуальнее с каждым днем), и людям, обеспечивающим работоспособность и безопасность Kubernetes кластера. Для получения этого представления я могу порекомендовать совсем свежее выступление “Command and KubeCTL: Real-World Kubernetes Security for Pentesters” . В данном выступление автор рассматривает и сразу демонстрирует различные тактики, техники и инструменты для получения доступа и эксплотации Kubernetes кластера.
Все live demo идет на примере 3 компаний - трех различных инфраструктур: on-prem, multu-cloud и сервис со множеством, географически разнесенных групп разработчиков. То есть это разное использование Kubernetes и как следствие разная модель угроз.
Отдельно стоит отметить Attack Chain (на скриншоте), которая описывает все что будет делать пентестер/злоумышленник, пытающийся взломать Kubernetes кластер. Каждый этап демонстрируется шаг за шагом.
Все live demo идет на примере 3 компаний - трех различных инфраструктур: on-prem, multu-cloud и сервис со множеством, географически разнесенных групп разработчиков. То есть это разное использование Kubernetes и как следствие разная модель угроз.
Отдельно стоит отметить Attack Chain (на скриншоте), которая описывает все что будет делать пентестер/злоумышленник, пытающийся взломать Kubernetes кластер. Каждый этап демонстрируется шаг за шагом.
Где можно попрактиковаться, поупражняться с k8s?
Совсем недавно на BSidesSF 2020 был "Using Built-in Kubernetes Controls to Secure Your Applications" воркшоп. Целью, которого было показать, как можно атаковать приложения в Kubernetes и эксплотировать его небезопасные конфигурации. Всего 11 упражнения, построенных практически по идентичной схеме: Установка/Настройка -> Успешная атака -> Разбор причин -> Исправление/улучшение -> Не успешная атака. Все это доступно по адресу https://securek8s.dev/exercise/
Для этого даются слайды, весь исходный код и возможность поиграться с этим на бесплатном Google Cloud Shell.
Внутри упражнений:
- Уязвимый Apache Struts фреймворк c CVE-2017-5638
- Сценарий как BugBounty отчете в Shopify
- Read-only root FS и host mounts, сетевые политики, настройка RBAC, разделение namespaces, использование non-root user, отказ от privileged mode, установка resource limits
Совсем недавно на BSidesSF 2020 был "Using Built-in Kubernetes Controls to Secure Your Applications" воркшоп. Целью, которого было показать, как можно атаковать приложения в Kubernetes и эксплотировать его небезопасные конфигурации. Всего 11 упражнения, построенных практически по идентичной схеме: Установка/Настройка -> Успешная атака -> Разбор причин -> Исправление/улучшение -> Не успешная атака. Все это доступно по адресу https://securek8s.dev/exercise/
Для этого даются слайды, весь исходный код и возможность поиграться с этим на бесплатном Google Cloud Shell.
Внутри упражнений:
- Уязвимый Apache Struts фреймворк c CVE-2017-5638
- Сценарий как BugBounty отчете в Shopify
- Read-only root FS и host mounts, сетевые политики, настройка RBAC, разделение namespaces, использование non-root user, отказ от privileged mode, установка resource limits
Kubernetes Product Security Team опубликовала информацию о еще одной закрытой уязвимости:
- CVE-2019-11254 (https://github.com/kubernetes/kubernetes/issues/89535): kube-apiserver DoS - уровень Medium
Уязвимость в kube-apiserver, приводит к отказу в обслуживании при обработке специально подготовленного YAML файла отправленного пользователем авторизованным в системе.
Уязвимости исправлены в версиях:
- v1.17.3
- v1.16.7
- v1.15.10
Уязвимость исправлена в тех же версиях, что и CVE-2020-8552 и CVE-2020-8551 - непонятно почему эта уязвимость анонсируется отдельно.
Из примечательно можно отметить, что уязвимость была найдена благодаря проекту OSS-Fuzz от ребят из Google. Проект Kubernetes добавлен туда и фазится с помощью go-fuzz и libfuzzer - детальнее можно посмотреть по ссылке. PoC вредоносного файла можно взять тут.
- CVE-2019-11254 (https://github.com/kubernetes/kubernetes/issues/89535): kube-apiserver DoS - уровень Medium
Уязвимость в kube-apiserver, приводит к отказу в обслуживании при обработке специально подготовленного YAML файла отправленного пользователем авторизованным в системе.
Уязвимости исправлены в версиях:
- v1.17.3
- v1.16.7
- v1.15.10
Уязвимость исправлена в тех же версиях, что и CVE-2020-8552 и CVE-2020-8551 - непонятно почему эта уязвимость анонсируется отдельно.
Из примечательно можно отметить, что уязвимость была найдена благодаря проекту OSS-Fuzz от ребят из Google. Проект Kubernetes добавлен туда и фазится с помощью go-fuzz и libfuzzer - детальнее можно посмотреть по ссылке. PoC вредоносного файла можно взять тут.
GitHub
CVE-2019-11254: kube-apiserver Denial of Service vulnerability from malicious YAML payloads · Issue #89535 · kubernetes/kubernetes
CVE-2019-11254 is a denial of service vulnerability in the kube-apiserver, allowing authorized users sending malicious YAML payloads to cause kube-apiserver to consume excessive CPU cycles while pa...
Компания Microsoft опубликовала матрицу Adversarial Tactics, Techniques & Common Knowledge (ATT&CK) для Kubernetes. Данная матрица описывает и каталогизирует поведения атакующего на всех его стадиях от проникновения, до нанесения ущерба.
Взялись они это делать для своего Azure и пришли к выводу что есть большое сходство с матрицами для Windows и Linux. Так что большинство тактик такие же (9 штук), но есть и различия - отсутствует Collection, Command and Control и Exfiltration. Техник пока у них набралось 40 штук и каждая имеет небольшое описание с которым рекомендую ознакомится по ссылке.
Взялись они это делать для своего Azure и пришли к выводу что есть большое сходство с матрицами для Windows и Linux. Так что большинство тактик такие же (9 штук), но есть и различия - отсутствует Collection, Command and Control и Exfiltration. Техник пока у них набралось 40 штук и каждая имеет небольшое описание с которым рекомендую ознакомится по ссылке.
Часто говорят, что Kubernetes это YAML и API. Это не совсем правда и не далеко от правды =). В YAML описывается желаемое состояние, а по API (упрощенно) делается все, чтобы это текущее и желаемое состояние сходились + различные сопутствующие действия. В итоге, для голого Kubernetes (который вы только что поставили) вся базовая безопасность сводится ровно к одной вещи: в YAML ресурсах прописать требуемые свойства безопасности! Через эти же YAML ресурсы будет настроен и API: кто, как, что может и не может делать. Декларативная сущность Kubernetes позволяет четко заявлять, что хочется иметь в результате, что очень важно для безопасности в том числе. Но голый Kubernetes никто не использует и тут картина кардинально меняется. Можно выделить следующие направления безопасности реального, боевого Kubernetes кластера:
- Image security
- Container runtime security
- Host security
- Network security
- k8s security
- Application security
За скобками оставим (но не будем про нее забывать) безопасность клиентских машин, на которых могут быть креды для доступа в облако или kubeconfig файл, и компрометация которых может привести и к компрометации кластера. Постепенно на канале будем покрыть все данные направления.
- Image security
- Container runtime security
- Host security
- Network security
- k8s security
- Application security
За скобками оставим (но не будем про нее забывать) безопасность клиентских машин, на которых могут быть креды для доступа в облако или kubeconfig файл, и компрометация которых может привести и к компрометации кластера. Постепенно на канале будем покрыть все данные направления.
Kubernetes
Objects In Kubernetes
Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Learn about the Kubernetes object model and how to work with these objects.
По заказу Kubernetes Security Working Group в середине 2019 года ряд сторонних компаний делали аудит безопасности Kubernetes. Целью был актуальный на тот момент Kubernetes 1.13.4.
Ориентир работ был на:
- Networking
- Cryptography
- Authentication & Authorization (including Role Based Access Controls)
- Secrets management
- Multi-tenancy isolation: Specifically soft (non-hostile co-tenants)
На все про все было 8 недель и результатом работы стало 4 документа:
- Kubernetes Security Review
- Attacking and Defending Kubernetes Installations
- Whitepaper
- Threat Model
Несмотря на то, что данные документы в некоторых моментах устарели (текущая стабильная версия уже 1.18) — это определенно лучший старт для технического погружения в безопасность Kubernetes, нового исследования в данной теме или участия в BugBounty Kubernetes.
Подробнее о каждом из документов, пройдемся в отдельных постах.
Ориентир работ был на:
- Networking
- Cryptography
- Authentication & Authorization (including Role Based Access Controls)
- Secrets management
- Multi-tenancy isolation: Specifically soft (non-hostile co-tenants)
На все про все было 8 недель и результатом работы стало 4 документа:
- Kubernetes Security Review
- Attacking and Defending Kubernetes Installations
- Whitepaper
- Threat Model
Несмотря на то, что данные документы в некоторых моментах устарели (текущая стабильная версия уже 1.18) — это определенно лучший старт для технического погружения в безопасность Kubernetes, нового исследования в данной теме или участия в BugBounty Kubernetes.
Подробнее о каждом из документов, пройдемся в отдельных постах.
Kubernetes не безопасен по умолчанию или правильнее будет сказать не использует механизмы безопасности по умолчанию. И это понятно, потому что любые ограничения затрудняют внедрение или перенос приложения. Поэтому по умолчанию все отключено и сделано для того, чтобы первый опыт запуска/переноса своего приложения был простым и приятным. Никто не хочет мигрировать в новое окружение и иметь непонятные проблемы, из-за которых уже работающее приложение не работает. Это относится не только к Kubernetes но и к другими системам тоже. Так что после того, как вы запустили свое приложение в Kubernetes имейте это в виду. Kubernetes имеет/умеет практически все что нужно: RBAC, NetworkPolicy, PodSecurityPolicy (включая seccomp, AppArmor, SeLinux) и т.д.
Отличный writeup, демонстрирующий как уязвимость/проблема в ПО в кластере может привести к компрометации внутренней инфраструктуры кластера, на примере уязвимости Slack TURN сервере. Сама уязвимость/проблема напоминает SSRF (server-side request forgery), но не ограничивается HTTP протоколом. В итоге, Slack TURN сервер выглядит как обычная прокся во внутреннюю инфраструктуру. Тоесть можно:
- Подключаться к AWS meta-data сервису на http://169.254.169.254 и получать IAM temporary credentials
- Подключаться к открытым портам на localhost, которые не доступны из сети интернет (на пример, node exporter): 22, 25, 53, 443, 515, 5666, 8500, 8888, 9090 и 9100
- Сканирование портов в Slack AWS инфраструктуре 10.41.0.0/16 и т.д.
При этом данная проблема с TURN известна авторам с 2017 года (по их словам) и данное поведение TURN сервера является не багой, а фичей и решается на конфигурационном уровне.
- Подключаться к AWS meta-data сервису на http://169.254.169.254 и получать IAM temporary credentials
- Подключаться к открытым портам на localhost, которые не доступны из сети интернет (на пример, node exporter): 22, 25, 53, 443, 515, 5666, 8500, 8888, 9090 и 9100
- Сканирование портов в Slack AWS инфраструктуре 10.41.0.0/16 и т.д.
При этом данная проблема с TURN известна авторам с 2017 года (по их словам) и данное поведение TURN сервера является не багой, а фичей и решается на конфигурационном уровне.
Kubernetes Threat Model
Мне известно по крайней мере 2 ее реализации (обе они разные и дополняют друг друга):
1) Как результат Kubernetes Third Party Security Audit от сторонних ИБ компаний. Документ содержит dataflow, Threat Actors, описание компонентов, Trust Zones и взаимодействие компонентов, контроли безопасности, реализуемые в них, рекомендации по их улучшению.
2) От CNCF Financial Services User Group. Документ содержит K8s Attack Tree.
При договоре с заказчиком всегда обсуждается какие модели угроз и модели нарушителя аудитор будет применять/проверять в процессе аудита - так что это очень полезные доки, чтобы разговаривать на одном языке аудиторам и k8s владельцам.
Не забывайте, что система развивается и Attack Surface и Threat Model могут изменяться.
Мне известно по крайней мере 2 ее реализации (обе они разные и дополняют друг друга):
1) Как результат Kubernetes Third Party Security Audit от сторонних ИБ компаний. Документ содержит dataflow, Threat Actors, описание компонентов, Trust Zones и взаимодействие компонентов, контроли безопасности, реализуемые в них, рекомендации по их улучшению.
2) От CNCF Financial Services User Group. Документ содержит K8s Attack Tree.
При договоре с заказчиком всегда обсуждается какие модели угроз и модели нарушителя аудитор будет применять/проверять в процессе аудита - так что это очень полезные доки, чтобы разговаривать на одном языке аудиторам и k8s владельцам.
Не забывайте, что система развивается и Attack Surface и Threat Model могут изменяться.
Кратко рассмотрим результат Kubernetes Third Party Security Audit из документа Kubernetes Threat Model. На скриншоте вы видите насколько оценили аудиторы уровень реализации контролей для того или иного компонента. Все эти компоненты (8 штук) были проанализированы и в них выделено 17 проблем – от информационного до среднего уровня:
- kube-apiserver – 2 проблемы
- etcd – 2 проблемы
- kube-scheduler – 2 проблемы
- kube-controller-manager и cloud-controller-manager – 2 проблемы
- kubelet – 2 проблемы
- kube-proxy – 1 проблема
- Container Runtime – 1 проблема
И еще 6 общесистемных проблем.
При этом есть проблемы, которые актуальны и по сей день для Kubernetes! Напомню, что отчет был на основе Kubernetes 1.13.4.
- kube-apiserver – 2 проблемы
- etcd – 2 проблемы
- kube-scheduler – 2 проблемы
- kube-controller-manager и cloud-controller-manager – 2 проблемы
- kubelet – 2 проблемы
- kube-proxy – 1 проблема
- Container Runtime – 1 проблема
И еще 6 общесистемных проблем.
При этом есть проблемы, которые актуальны и по сей день для Kubernetes! Напомню, что отчет был на основе Kubernetes 1.13.4.
Если вам нечем заняться на самоизоляции или просто на выходных, то есть прекрасная возможность и время интересно провести и с Kubernetes поиграться на Mini Kubernetes Easter CTF (базируется на AWS EKS). Образы контейнеров доступны на DockerHub. Для участия просто вводите команды в поле “Command” на сайте, так что берете и вбиваете
kubectl и понеслась!На днях в свободном доступе появилась книжка "Building Secure & Reliable Systems" от SRE инженеров Google.
Слово Kubernetes встречается 21 раз (Cloud - 95, GCP - 3, AWS - 4, Azure - 0). Книга не о Kubernetes, а о построение систем в целом. Но в ряде моментов есть не двусмысленные намеки (примеры) на то, что если хотите secure и reliable, то все что нужно для достижения этого заложено в концепцию Kubernetes.
Слово Kubernetes встречается 21 раз (Cloud - 95, GCP - 3, AWS - 4, Azure - 0). Книга не о Kubernetes, а о построение систем в целом. Но в ряде моментов есть не двусмысленные намеки (примеры) на то, что если хотите secure и reliable, то все что нужно для достижения этого заложено в концепцию Kubernetes.
Каждая инфраструктура с Kubernetes уникальна -> Attack Surface, Threat model соответственно. Значит подход к вопросам обеспечения ее безопасности и ее стороннего аудита будет в каждом отдельном случае иметь свою специфику.
Начинаем с Kubernetes интерфейсов: Container Runtime Interface (CRI), Container Networking Interface (CNI) и Container Storage Interface (CSI). Продолжаем кучей проектов, без которых очень сложно обойтись в реальной (не тестовой) инфраструктуре - список можно посмотреть на портале CNCF Cloud Native Interactive Landscape (также надо будет позаботится и о безопасности данных сущностей). Заканчивая разными Custom Resource Definitions (CRD), кастомными операторами и контроллерами - точек встраивания и изменения в Kubernetes предостаточно. И, конечно, все это приправляем различными версиями этих сущностей, версиями API и т.д.
Сложность системы повышается и возможностей ошибиться тоже. Но сам Kubernetes дает и много возможностей это контролировать и не нужно это оставлять без внимания.
Начинаем с Kubernetes интерфейсов: Container Runtime Interface (CRI), Container Networking Interface (CNI) и Container Storage Interface (CSI). Продолжаем кучей проектов, без которых очень сложно обойтись в реальной (не тестовой) инфраструктуре - список можно посмотреть на портале CNCF Cloud Native Interactive Landscape (также надо будет позаботится и о безопасности данных сущностей). Заканчивая разными Custom Resource Definitions (CRD), кастомными операторами и контроллерами - точек встраивания и изменения в Kubernetes предостаточно. И, конечно, все это приправляем различными версиями этих сущностей, версиями API и т.д.
Сложность системы повышается и возможностей ошибиться тоже. Но сам Kubernetes дает и много возможностей это контролировать и не нужно это оставлять без внимания.
Если вы абсолютно не знаете, как подступится к безопасности своего приложению на базе микро сервисов, то можно начать с «OWASP Сheat Sheet Series. Microservices-based security architecture documentation» и для этого будет достаточно взять листок бумаги с ручкой или excel табличку + пообщаться с вашей командой разработки. Данный Сheat Sheet естественно подходит и при использовании Kubernetes. Основная суть/соль — это инвентаризация, описание, выстраивание связей и поддержка актуальности ваших знаний о системе. Можно об этом посмотреть и в видео.
YouTube
Александр Барабанов,OWASP Сheat Sheet Series.Microservices-based security architecture documentation
Как в мире микросервисов иметь актуальную информацию о каждом из них с точки зрения безопасности? Попробуем найти решение этой проблемы и презентуем новую памятку в рамках проекта "OWASP Сheat Sheet Series"
Безопасность Helm v2.
Основные моменты по обеспечению безопасности Helm v2:
- включение RBAC, использование специализированного service-account
- использование namespaces'ов для Tiller multi-tenancy
- использование secrets вместо ConfigMaps для стораджа
- использование HTTPS для репозитариев
- использование подписи для Chart'ов и их проверка
- включение TLS на gRPC для Tiller сервиса
Послушать об этом можно в выступлении "Безопасность Helm", что базируется на документации проекта. Helm v3 претерпел значительные изменения - там отказались от Tiller (что значительно уменьшило AttackSurface) и используют более нативную интеграцию с помощью CRD. О безопасности Helm v3 в следующий раз.
Основные моменты по обеспечению безопасности Helm v2:
- включение RBAC, использование специализированного service-account
- использование namespaces'ов для Tiller multi-tenancy
- использование secrets вместо ConfigMaps для стораджа
- использование HTTPS для репозитариев
- использование подписи для Chart'ов и их проверка
- включение TLS на gRPC для Tiller сервиса
Послушать об этом можно в выступлении "Безопасность Helm", что базируется на документации проекта. Helm v3 претерпел значительные изменения - там отказались от Tiller (что значительно уменьшило AttackSurface) и используют более нативную интеграцию с помощью CRD. О безопасности Helm v3 в следующий раз.