Данный канал о (не)безопасности Kubernetes и все что с ним связано. Мы будем рассматривать различные новости, выступления, исследования, уязвимости, инструменты по данной теме, так или иначе связанные с информационной безопасностью. Также, время от времени будут публиковаться авторские мысли (субъективные), наработки, идеи и т.д.

Буквально вчера в официальной рассылке Kubernetes сообщили о двух закрытых уязвимостях:
- CVE-2020-8552: apiserver DoS (oom) - уровень Medium
- CVE-2020-8551: Kubelet DoS via API - уровень Medium

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

Уязвимости исправлены в версиях:
- v1.17.3
- v1.16.7
- v1.15.10

Это первые запатченные уязвимости, которым присвоили CVE, в Kubernetes в 2020 году. В соответствии с Kubernetes Issue Tracker за 2019 год в нем (сторонние компоненты не рассматриваются) было закрыто 14 уязвимостей.

В открытых источника очень мало историй о том как атакующим удавалось проникнуть в продакшен Kubernetes окружения.
Прекрасным примером такого для ознакомления может служить репорт на hackerone под названием "SSRF in Exchange leads to ROOT access in all instances" от 24 мая 2018 года. Исследователем безопасности была найдена SSRF (Server-Side Request Forgery) уязвимость в приложении (в функциональности по созданию скриншотов) известного магазина Shopify за что он был вознагражден $25,000.
Атака состояла из трех этапов:
1) Получение доступа к Google Cloud Metadata через SSRF
2) Дамп kube-env (получение ca.crt, client.crt, client.pem)
3) Выполнение произвольных команд с помощью kubectl
Полезно посмотреть, что и как делал исследователь и как на это отреагировала служба безопасности.

Важной вехой в плане безопасности Kubernetes можно считать появление BugBounty программы на платформе Hackerone в январе 2020 года. Теперь еще больше специалистов по безопасности возможно обратит свое внимание на Kubernetes с целью подзаработать. На текущий момент вознаграждения варьируются от 50$ до 10.000$ в зависимости от критичности найденной уязвимости.

Помимо уязвимостей в самом коде Kubernetes принимаются и уязвимости найденные на определенных сайтах проекта: https://prow.k8s.io, https://kubernetes.io, k8s.io, kubernetes-csi.github.io .

Вознаграждения разделены на 3 уровня по их местонахождению:
1) Основные и Beta фичи core компонентов и ключевых зависимостей Kubernetes. А также способность не авторизовано менять исходный код и DoS'ить ряд сервисов.
2) Основные и Beta фичи не core компонентов Kubernetes
3) Kubernetes инфраструктура и Alpha фичи core компонентов Kubernetes

В разделе Scope можно увидеть, какого типа уязвимости и проблемы рассматриваются для вознаграждения. Они разбиты на 3 класса:
- Атаки на кластер
- Нарушение Supply Chain (без социальной инженерии)
- Проблемы компонент

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

P.S. На текущий момент выплачено 9.950$, закрыто 3 репорта – технических деталей нет.

Сегодня вышел Kubernetes 1.18.0

И сейчас мы кратенько пройдемся по изменениям, что касаются security и наиболее интересны на мой взгляд.

- Появление команды kubectl debug (стадия Alpha) - данная команда позволяет создать ephemeral containers, который запуститься в нужном Pod и позволит интерактивно разобраться с проблемой. Это позволит разработчикам не тянуть на продакшен Pod'ы всякие отладочные инструменты "на всякий случай", спокойно использовать distroless контейнер образы. В свою очередь это уменьшит шансы атакующему встретить на контейнерах кучу отладочных (потенциально полезных) ему инструментов для дальнейшей атаки. Нужно держать в голове, что если атакующий сможет выполнять команду debug, то он значительно расширит attack surface для побега из контейнера.

- `ServiceAccountIssuerDiscovery` (стадия Alpha) - позволяет сервисам вне кластера использовать KSA (Kubernetes service accounts) токены (JSON Web Tokens или JWT) в качестве общего метода аутентификации, не перегружая API сервер (и, конечно, не высовывая его наружу!). Для этого API сервер предоставляет механизм обнаружения OpenID Connect (OIDC), который содержит, помимо прочих данных, открытые ключи токена. Таким образом аутентификаторы OIDC могут использовать эти ключи для проверки токенов KSA на своей стороне.

- `CertificateSigningRequest API` (стадия Beta) - каждый Kubernetes кластер имеет root certificate authority (CA), который используется для защиты соединений между основными компонентами Kubernetes (обрабатывается с помощью Certificates API). Далее это начали использовать и другие компоненты системы и ПО. Теперь для использования этого API необходимы соответствующие разрешения и кто попало в системе не сможет это использовать (тем более представляться другим сервисом для данного запроса).

Пентест, Kubernetes. У многих отсутствует представление о том, как это вообще выглядит. Хотя это очень полезно и пентестерам (для них это становится актуальнее с каждым днем), и людям, обеспечивающим работоспособность и безопасность Kubernetes кластера. Для получения этого представления я могу порекомендовать совсем свежее выступление “Command and KubeCTL: Real-World Kubernetes Security for Pentesters” . В данном выступление автор рассматривает и сразу демонстрирует различные тактики, техники и инструменты для получения доступа и эксплотации 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

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 вредоносного файла можно взять тут.

Небольшая памятка по основным портам в Kubernetes. Может пригодится при пентесте.

Компания Microsoft опубликовала матрицу Adversarial Tactics, Techniques & Common Knowledge (ATT&CK) для Kubernetes. Данная матрица описывает и каталогизирует поведения атакующего на всех его стадиях от проникновения, до нанесения ущерба.
Взялись они это делать для своего 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 файл, и компрометация которых может привести и к компрометации кластера. Постепенно на канале будем покрыть все данные направления.