Начинаем эту неделю с атакующей тематики, а именно со статьи The CoreDNS Cache Poisoning Conjecture. Автор проходится по исходному коду CoreDNS и расказывает как он может быть подвережен атаке cache poisoning. Кроме того, из статьи вы узнаете как митигровать риски от такой атаки.

Для проведения такой атаки достаточно NET_RAW capability, которая по умолчанию есть в контейнере. Поэтому не забывайте дропать все capability и добавлять только те, которые действительно необходимы.

Материалов по сетевым атакам в Kubernetes довольно мало, однако этот интересный вектор не стоит упускать, ведь он вполне имеет место быть.

Изучили с командой две последние вредоносные находки/атаки/малвари нацеленные на облачные окружения (и не только):
1) "HeadCrab: A Novel State-of-the-Art Redis Malware in a Global Campaign" - вектор банален: Redis без аутентификации, смотрящий в интернет. Во вредоносной логике тоже нет как по мне никакого State-of-the-Art. Есть только забавный момент, что если код понимает, что он в контейнере, то он не пытается там даже закрепиться)
2) "PyLoose: Python-based fileless malware targets cloud workloads to deliver cryptominer" - точка входа это торчащий наружу Jupyter Notebook сервис.

Так оба вредоносного кода для реализации fileless техники используют memfd. При этом как вы понимаете все равно есть та часть, которая сначала грузиться в тот же контейнер, что-то делает, подготавливает и затем уже скачивает эту вот fileless часть. У вас или у вашего SOC вопросы должны уже появляться на 1 шаге, не говоря уже о том, что при наличии NetworkPolicy можно вообще сделать так что это вообще не состояться.

100 Methods for Container Attacks (RTC0010) – сборник команд и утилит, которые будут полезны при пентесте Kubernetes. В центре внимания утилиты kube-hunter и trivy, о которых мы не раз говорили в канале.

Что интересно, помимо привычных техник, затрагиваются и такие как Data Destruction и Resource Hijacking. Судя по всему авторы плотно прошлись по всей матрице MITRE ATT&CK.

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

Совсем скоро мы расскажем о своём образе для проведения аудита Kubernetes кластеров. Доклад уже принят на конференцию и как только появится официальный анонс мы обязательно об этом сообщим ;)

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

И так, что же может пойти нет?!
1) Допустим, пройдя все проверки, выкатывается образ и у него 0 уязвимостей (фантастика, но пускай).
2) Далее происходит обновление feed об уязвимостях и с его учетом у нас в том же самом образе, где минуту назад было 0, появились какие-то уязвимости (critical, high, medium, low)!
3) (Чисто как факт - в проде уже работает уязвимое приложение, через которое можно скомпрометировать систему)
4) ReplicaSets controller решает, что нужны еще Pod с тем самым образом. Это может быть по многим причинам: сработал HPA, какие-то Pods аварийное завершились по OOM, упала Node и утащила за собой эти Pods, Pods переезжают с Node на Node по какой-то причине, происходит обновление Secrets/ConfigMap/... и нужно рестартануть Pods, обновили сам YAML для Deployment и т.д. То есть опять запускается процесс выкатки приложение на том же образе ;)
5) Этот контроль видит этот образ с его critical, high, medium, low уязвимостями и блокирует деплоймент ...
6) Тут можете уже самим придумать как ваша система не справляется, деградирует, складывается как карточный домик. И соответственно бизнес и ИТ совсем не рады такому ... (Встанет вопрос кто принес ущерба больше CVE или контроль)

На бумаге существует множество красивых security подходов, НО которые совсем не учитывают operations специфику системы.

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

Создатели Policy Engine Kyverno решили составить конкуренцию не только OPA Gatekeeper (с этим они уже отлично справляются), но и OPA! А именно проверять не только ресурсы Kubernetes, но и в принципе любые JSON =)

В статье "Experimental Generic JSON Validation with Kyverno" они показывают, как этого можно сейчас добиться (все это пока очень экспериментально). Подробнее можно еще посмотреть выложенный проект json-validator. Так сам Kyverno по-прежнему должен запускаться внутри Kubernetes, но при этом доступен из вне, чтобы можно было к нему обратиться на прямую. Так же как и ранее это можно проворачивать в pipeline с помощью Kyverno CLI.

Как основной use case авторы заявляют, что так можно проверять конфигурации и настройки сервисов, что располагаются рядом с Kubernetes и связаны с ним.

На прошедшем Steelcon 2023 Rory McCune и Iain Smart провели свой 4-х часовой воркшоп – Container Security and Hacking with Docker and Kubernetes. Наверное, это один из самых больших сборников по безопасности контейнеров и Kubernetes. Воркшоп включает в себя следующие темы:

- Container Basics
- Docker Security
- Kubernetes Fundamentals
- Kubernetes Security
- Kubernetes Networking
- Kubernetes Distributions
- Container Secirty Problems/Challenges

К сожалению, инфраструктура, поднятая для воркшопа, больше не работает, но есть ссылка на презентацию. Однозначно рекомендуем материал для новичков и всех тех, кто хочет погрузиться в тему container security.

И продолжим тему обучений.

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

Приятно видеть такое публичное упоминание! К сожалению, большинство благодарностей от банков, платежных систем, экосистем, интернет сервисов, облачных провайдеров, онлайн кинотеатров, маркетплейсов носят закрытый характер ;)

В официальном блоге Kubernetes вышла занимательная статья "Confidential Kubernetes: Use Confidential Virtual Machines and Enclaves to improve your cluster security", посвящённая теме концепции Confidential Computing (CC). По сути, это защита от облачного/инфраструктурного уровня - более конкретнее от работников дата-центров, привилегированных облачных админов и атакующих имеющих доступ к инфраструктуре, где работает ваше приложение/контейнер/кластер.

Это базируется на идее Trusted Execution Environments (TEEs) и в данном случае могут служить технологии AMD SEV, Intel SGX и Intel TDX (работает с кодом и данными идет в специальном режиме куда никто по сути больше не имеет доступ). Учтите, что Intel выпиливает SGX и на смену ему идет TDX.

Понятно дело, что это еще все имеет раннюю степень адаптации, но направление очень интересное и за его развитием нужно следить!

P.S. В следующих постах рассмотрим конкретные примеры проектов.

Продолжим тему Confidential Computing (CC) в Kubernetes и остановимся на одном из основных проектов в этой теме.

Confidential Containers (CoCo) - это CNCF sandbox project, который позволяет изолировать Kubernetes pods внутри confidential virtual machines. Цель данного проекта установить стандарт для Confidential Computing (CC) на уровне Kubernetes pod. С точки зрения реализации сам проект представляет из себя kubernetes operator с рядом служебных сервисов ( guest-components, Key Broker Service, Attestation Service) и специальный runtimeClassName (под капотам там модифицированная kata), который нужно указать для Pod.

Всего есть 3 режима работы на базе:
1) VM-based TEEs на local hypervisor (на картинке)
2) VM-based TEEs на remote hypervisor
3) Process-based TEE

Про проект можно подробнее почитать в документации или из статьи "Confidential Containers in Kubernetes".

Наша исследовательская команда нашла довольно интересный репозиторий с исследованием "Container image with malware and crypto miner for testing". В нем автор решил проверить как различные сканеры образов могут обнаружить вредоносный код в образах контейнеров. Для этого он в легитимный образ залил (без обфускации и т.д.) солидную выборку хорошо известных malware, ransomware, crypto miner и т.д.

Что можно сказать про результаты? А то что даже те кто активно заявляют эту функциональность и вроде как даже на этом специализируются - сели в лужу (статический анализ мы уже обсуждали) ... И это еще на том что есть на VirusTotal и т.д. Хотя под это, конечно, можно достаточно просто подгонять результат ...

По своему опыту обхода антивирусов могу сказать, что когда я руководил исследовательским центром и к нам приходили наши пентестеры и просили помочь им обойти серьезные корпоративные антивирусы и EDR для запуска Mimikatz и подобного, то это занимало от нескольких часов до 2-3 дней. В контейнерных окружениях это сделать еще проще, тем более когда атакующий сам готовит весь образ ;)

Еще разница в том, что если на пользовательских тачках много ресурсов и они могут простаивать, то на Nodes в Kubernetes отдавать под это немалые вычислительные ресурсы это большая роскошь ...

P.S. Как-то мы уже делали даже опрос по данной теме.
P.S.S. NetworkPolicy - must have!

Некоторое время назад, изучая замечательную документацию GKE, наткнулись на интересный пункт "Restrict the ability for workloads to self-modify" в разделе "Harden your cluster's security".

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

В качестве защитных мер от подобного предлагается:
1) Не давать рабочим нагрузкам права на модификацию себя.
2) Если пункт 1 невозможен, то ограничить то, что может меняться. На пример, содержимое поля serviceAccountName.

Пункт 2 можно реализовать с помощью PolicyEngine. В GKE используется OPA Gatekeeper и они приводят пример такой политики на нем - NoUpdateServiceAccount (хотя это можно сделать и на Kyverno). Рекомендуем взять такую политику на вооружение или хотя бы просто ее изучить. В этой политике есть прекрасный пример того, как можно обрабатывать запросы на основе определённых пользователей или групп и добавлять их в исключения (чаще всего это делают сразу на целый Namespace).

Также хочется порекомендовать такую хорошую практику как запуск системных рабочих нагрузок на отдельных Nodes и не мешать их с обычными бизнес-сервисами ;)

Abusing Amazon VPC CNI plugin for Kubernetes – довольно интересная статья, из которой вы узнаете, что встроенный CNI плагин в Amazon не такой уж и безопасный.

Рассматривая возможности атаки на Amazon EKS, авторы статьи исследовали плагин Amazon VPC CNI для Kubernetes и выявили способы злоупотребления этим плагином для манипулирования сетями в своих интересах. Это позволяет злоумышленнику, закрепившемуся в кластере EKS, создавать и потенциально эксплуатировать сервисы в других VPC, не связанных с кластером.

В качестве возможных remedations отмечаются:

- IAM Roles for ServiceAccounts
- Blocking instance metadata service (IMDS)
- AWS IAM policy hardening

На этой неделе – 4-5 августа наша команда Luntry будет принимать участие в конференции Ural Digital Weekend 2023 в Перми. Мы выступим с докладом “Создание Network Policy в Kubernetes: ключевые аспекты и рекомендации для разработчиков”, и вместе с тем затронем вопросы того, почему разработчикам необходимо понимать и уметь в Network Policy в Kubernetes.

Купить билет можно тут, а указав наш промокод LUNTRY894, вы получите скидку 10% на всё.

Взаимодействуя с разными компаниями и организациями мы видим как растет число Kubernetes кластеров в них и потребность в контроле и управлении этим множеством кластеров.

Это же наблюдает и сообщество Kubernetes, которое уже создало для решения данной задачи Multicluster Special Interest Group. За их успехами можно наблюдать тут (пример одной из новых инициатив Cluster Inventory API).

В рамках KEP-1645: Multi-Cluster Services API они работают над Multicluster Services API (MCS API) (на картинке). Это должно позволить упросить общение микросервисов из разных кластеров. Если вам интересны реализации, то их можно посмотреть тут.

GUAC: Graph for Understanding Artifact Composition – интересная тулза, которая поможет вам определить и красиво отобразить взаимотношения между зависимостями в приложении.

На вход инструмент может принимать следующие форматы данных:

- CycloneDX
- Dead Simple Signing Envelope
- Deps.dev API
- In-toto ITE6
- OpenSSF Scorecard
- OSV
- SLSA
- SPDX

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

Концептуально, GUAC, представляет слой "Aggregation and synthesis" в логической модели software supply chain transparency. Вместе с тем, инструмент также закрывает proactive, preventive & reactive вопросы безопасности.

Наши хорошие товарищи 24–25 августа в Москве организовывают конференцию OFFZONE 2023. От нашей команды Luntry в секции AppSec выступит Сергей Канибор с докладом "Kubernetes Pentest All-in-one: The Ultimate Toolkit".

Суть доклада следующая: Когда вы проводите пентест Kubernetes кластера, несомненно вы используете различные инструменты, чтобы автоматизировать и ускорить свою работу. Но что делать, если вы находитесь в защищенном, после харденинга окружении?! В докладе мы представим наш специальный образ, которой позволит обойти разные контроли безопасности и успешно провести свои действия (обход сигнатурных движков и т.д.)

При этом мы хотим разыграть 1 проходку на конференцию! В комментариях к данному посту напишите случай из вашей (или не вашей практики), когда приходилось обходить какие-то security контроли связанные с контейнерами или Kubernetes =)

Наиболее интересный случай по нашему мнению получит проходку. Варианты принимаем до Пн (7.08).

Статья "GameOver(lay): Easy-to-exploit local privilege escalation vulnerabilities in Ubuntu Linux affect 40% of Ubuntu cloud workloads" рассказывает о двух уязвимостях CVE-2023-2640, CVE-2023-32629 в модуле OverlayFS в ОС `Ubuntu.

Наше внимание это привлекло по следующим причинам:
1) Ubuntu можно часто встретить в контейнерных окружениях.
2) OverlayFS часто используется контейнерами
3) Для эксплуатации нужны манипуляции с user namespace и это очень популярно в рамках того же kCTF (часто доступно в контейнерах)
4) Эти уязвимости это реинкарнации CVE-2021-3493 из 2020. Из-за того у Ubuntu была своя доп. логика.
5) Сверх стабильный эксплоит, так как нет никаких манипуляций с памятью.

Получается так что user namespace создавали во благо, но сейчас он часто используется совсем в противоположную сторону. Думаю что он заслуживает особого внимания и возможно на следующем БЕКОН мы покроем эту тему ;)

P.S. Вы не поверите. но работа над программой следующего БЕКОН уже идет.

На нашем канале и в наших докладах мы с командой не раз уже поднимали тему, что исправление уязвимостей в сторонних библиотеках (а современные микросервисы на 60-80% состоят из сторонних библиотек) это не простая задача как ее многие описывают (нужно только просканировать и поднять версию зависимости до нужной и все). И тут наткнулись на интересный молодой проект, который призван как помочь в этом не легком деле, так и просто пояснить какие вообще есть сложности (на примерах, того, когда они сами полезны).

Seal Security Patches — это централизованный репозитарий самодостаточных исправлений безопасности для open source библиотек. Вот такие сценарии рассматриваются, когда разработчику может быть обновиться на последнюю версию библиотеки невозможно, очень долго или не практично:
- Ломающие изменение или deprecated фичи в новой версии библиотеки
- Уязвима транзитивная зависимость
- Уязвима не поддерживаемая библиотека
- Legacy код
- Mission-critical приложение
- Уязвим сторонний Container/VM образ
- Large Language Models (LLM) код

Очень хорошие кейсы и точно все команды разработки с этим сталкивались (ну кроме последнего конечно =) ). И тут еще перечислены только технические аспекты данной проблемы, а прибавьте к этому разные процессные и сроки обновления у многих улетаю в совсем не приличное сроки. Сейчас в проекте уже доступен ряд патчей для разных npm (29), rpm (8), pypi (7) библиотек - можно зайти и посмотреть, как это организовано и применяется.

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

P.S. Мне это также напомнило решение ребят из 0patch, но только там для бинарных приложений.

Сегодня в 14:30 по Мск можно online посмотреть выступление "Создание Network Policy в Kubernetes: ключевые аспекты и рекомендации для разработчиков" от нашего коллеги Сергея Канибора (Luntry, Security Researcher) с конференции Ural Digital Weekend 2023.

Ссылка на трансляцию.

Container security fundamentals part 5: AppArmor and SELinux – пятая статья из цикла статей [1,2,3,4] про безопасность контейнеров от Rory McCune.

Автор рассказывает как можно использовать такие механизмы как AppArmor и SELinux в контейнерном окружении. Сама по себе статья небольшая и в ней отражены только основные моменты по работе с этими механизмами.

Если вы хотите более глубже погрузиться в AppArmor в контексте Kubernetes, то рекомендуем к изучению доклад от нашей команды с БЕКОНа – AppArmor и Kubernetes: настройка проактивной защиты для безопасности приложений (видео, слайды).

P.S. В качестве домашнего задания: ответьте на вопрос, чем в Kubernetes механизм AppArmor лучше чем любой другой навесной prevention механизм для контейнеров (включая тех что написаны на eBPF)?

P.S.S. На самом деле благодаря этому моменту мы и реализовали автоматическую генерацию AppArmor в нашем Luntry.