Первая конференция БЕКОН близится к завершению. И очень круто видеть на последнем докладе в 17 часу полный зал)

Спасибо всем что пришли, задавали классные вопросы!

Вчера на БЕКОНе было много разговоров и обсуждений про container specific OS, ввиду двух докладов про Flatcar и Talos. Так что в продолжение вчерашнего ажиотажа и интереса к контейнерным ОС хотим поделиться записью докладов с TalosCon 2023.

Managed Kubernetes Auditing Toolkit (MKAT) – проект для обнаружения проблем безопасности в managed Kubernetes окружении. В настоящее время работает с Amazon EKS, но в дальнейшем планируется поддержка и других managed Kubernetes.

Фичи:

- Умеет определять взаимотношения между IAM Roles и Service Accounts и строить по ним графы
- Может находить захардкоженные AWS credentials в K8S ресурсах
- Есть возможность проверять имеет ли Pod доступ к AWS Instance Metadata Service (IMDS)

На самом деле довольно крутое решение, учитывая, что инструменты для аудита managed Kubernetes выходят не так часто. Кстати говоря, на пентестах и аудитах мы используем свой, заранее приготовленный образ – когда нибудь и о нём расскажем =)

Всем, привет!
Дайте пожалуйста свой feedback о прошедшем БЕКОНе!
Нам очень важна обратная связь, чтобы сделать конференцию еще лучше =)

P.S. Тут можно скачать архив со всеми презентациями.

Совсем недавно на конференции BSides Dublin 2023 всем хорошо известный Rory McCune выступил с докладом "CONTAINERS FOR PENTESTERS". Достаточно простые и лаконичные слайды для абсолютных новичков. Если вам хочется еще такого подобного, то напомню о докладе от нашей команды под названием “Pentesting Kubernetes: From Zero to Hero” ;)

Сегодня наша команда будет принимать участие в мероприятии «Безопасная разработка программного обеспечения: зачем нужен DevSecOps» в Екатеринбурге. Мы выступим с докладом “PolicyEngine в Kubernetes – что, как, зачем?”, в котором разберём для чего нужен PolicyEngine и как им пользоваться в Kubernetes. В конце будет небольшой блок с практикой на платформе Kyverno Playground, о которой мы писали ранее.

Участие бесплатное, требуется предварительная регистрация. Участие возможно в формате онлайн или оффлайн.

Зарегистрироваться на мероприятие можно тут.

На прошедшем недавно PHDays 2023 мы вместе с нашим хорошим товарищем Виктором Бобыльковым из Райффайзенбанк представляли доклад "SCAзка о SCAнерах" (видео, слайды в комментариях к посту). Кстати в истории Luntry, это первое совместное выступление с другой компанией (можно сказать исторический момент). Но точно не последнее, так как уже запланировано еще парочка совместных выселений с нашими друзьями и клиентами (конечно, же по теме безопасности контейнеров и Kubernetes).

Относительно "SCAзка о SCAнерах", то это попытка развеять некоторые мифы и показать суровую, не радужную реальность при работе со SCA. И все это показано через разные уровни зрелости процессов при работе с ними.

Самая важная мысль, что если вы себе в pipeline вставили какой-то анализатор, то вы сделали всего лишь 15-20% работы, а не внедрили лучшие практики SSDL, DevSecOps, ShiftLeftSecurity =)

Заканчиваем эту неделю с тремя новыми уязвимостями в Kubernetes:

1) CVE-2023-2431: Bypass of seccomp profile enforcement. Если у вас есть Pods, которые используют localhost type для seccomp, но сам по себе профиль пустой, это позволяет запускать Pod в unconfined режиме. Затрагивает версии:

- v1.27.0 - v1.27.1
- v1.26.0 - v1.26.4
- v1.25.0 - v1.25.9
- <= v1.24.13

2) CVE-2023-2727: Bypassing policies imposed by the ImagePolicyWebhook admission plugin. Благодаря этой уязвимости можно обойти ImagePolicyWebhook, используя ephemeralContainers. Но, если используете PolicyEngine – ничего не получится.
Затрагивает версии:

- kube-apiserver v1.27.0 - v1.27.2
- kube-apiserver v1.26.0 - v1.26.5
- kube-apiserver v1.25.0 - v1.25.10
- kube-apiserver <= v1.24.14

3) CVE-2023-2728: Bypassing enforce mountable secrets policy imposed by the ServiceAccount admission plugin. Позволяет обойти монтирование ServiceAccount token внутрь ephemeralContainers. Однако для этого нужно, чтобы в кластере был включен ServiceAccount admission plugin, у ServiceAccount была проставлена аннотация kubernetes.io/enforce-mountable-secrets (она не стоит по дефолту) и впринципе в Pod должен использоваться ephemeral container.
Затрагивает версии:

- kube-apiserver v1.27.0 - v1.27.2
- kube-apiserver v1.26.0 - v1.26.5
- kube-apiserver v1.25.0 - v1.25.10
- kube-apiserver <= v1.24.14

20 июня 2023 года в 17:00 совместно с коллегами из VK Cloud наша команда Luntry примет участие в вебинаре «Безопасность K8s на практике: возможности и инструменты».

Рассмотрим возможности и ограничения Kubernetes as a Service и K8s Addons, управление доступами и ролями с помощью SSO, а также потенциал инструментов мониторинга и шифрования трафика: Grafana, Istio и Kiali. Во второй части вебинара мы поговорим о продвинутых способах обеспечения безопасности: управлении уязвимостями в образах, контроле активности внутри контейнеров, NetworkPolicy и других.

Вебинар будет полезен разработчикам, специалистам по DevOps, DevSecOps и информационной безопасности, а также тимлидам и руководителям разработки. После вебинара вы поймете, какие возможности предоставляет Managed Kubernetes и как обеспечить безопасность работающих в нем микросервисов.

Зарегистрироваться можно тут.

P.S. Будет минимум слайдов и максимум live demo ;)

В блоге Google вышла занимательная заметка "Learnings from kCTF VRP's 42 Linux kernel exploits submissions", базирующая на их статистике относительно полученных репортов в рамках kCTF (про который мы не однократно писали 1,2,3,4,5). Если вы не знаете, то это специальная программа вознаграждений за найденный уязвимости в GKE (их managed Kubernetes) и нижележащем ядре.

Самый занимательный факт: "60% of the submissions exploited the io_uring component of the Linux kernel (we paid out around 1 million USD for io_uring alone). Furthermore, io_uring vulnerabilities were used in all the submissions which bypassed our mitigations."

В итоге, Google пришел к тому чтобы отключать или ограничивать доступ к io_uring в стоих продуктах =)

Также, все эксплоиты в рамках этой активности они описали в своей "Kernel Exploits Recipes Notebook"! Нам с командой отдельно понравилось, что там четко описываются какие capabilities необходимы для проведения успешной атаки!

А все это уже привело Google к запуску kernelCTF.

Наши хорошие друзья из СЛЁРМ позвали нас поучаствовать в третьем выпуске ШКОЛЫ МОНИТОРИНГА, что пройдет 20-21 июня.

И в рамках этой активноcсти 21 июня в 14:10 команда Luntry расскажет тему "Мониторинг безопасности в Kubernetes". И там за 20мин мы:
- Узнаем какая связь между мониторингом, observability и безопасностью
- Разберемся на что стоит обращать внимание при мониторинге безопасности Kubernetes
- Посмотрим на ряд механизмом и инструментов, которые могут помочь повысить уровень безопасности в Kubernetes

Мероприятие бесплатно, требуется регистрация.

Сегодня продолжим атакующую тему. Executing Arbitrary Code & Executables in Read-Only FileSystems – статья, в которой рассказывается о том, как можно выполнять произвольный код в readOnly FS. Самое крутое, что тут всё описывается в контексте в Kubernetes.

Автор статьи разбирает три способа:

1) Если в контейнере есть /bin/bash, с использованием тулзы DDexec (о ней мы рассказывали в одном из предущих постов)
2) Через /dev/tcp
3) С помощью специально приготовленного бинарника

Отдельно отмечаются директории, куда можно писать и исполняться – даже при выставленной readOnly FS в контейнере: /dev/shm и /dev/termination-log. По нашему опыту аудитов контейнерных сред – это очень сильно помогает, когда контейнер слишком захарденен, а запустить свои инструменты внутри контейнера очень нужно.

Чтобы предотвратить такие кейсы, можно использовать SELinux, ограничив доступ к /proc/[pid]/mem или execmem.

Наша команда Luntry продолжает расти и мы будем рады видеть у нас увлеченных, классных специалистов, которые хотят создавать новое, не банальное, полезное, высоконагруженное! Сейчас у нас открыта вакансия:
- Middle/Senior Go Developer

При этом мы нормально смотрим если у вас основной опыт на Python и вы не против перейти на Go. Такой опыт у нас тоже уже есть - главное чтобы голова была на плечах и работала как надо)

Также если вам просто интересен наш проект и вы знаете где бы вы могли принести пользу, то тоже можете написать (@Qu3b3c) - вместе подумаем и поищем варианты ;)

И будем признательны если вы скинете это сообщения вашим друзьям, знакомым, которым это может быть интересно!

P.S. Сегодня тут в 17:00 можно будет как раз посмотреть над чем мы работаем.

В рамках "Cloud Native Security Whitepaper" второй версии есть новый раздел "Security Principles", состоящий из 8 принципов:
1) Make security a design requirement
2) Applying secure configuration has the best user experience
3) Selecting insecure configuration is a conscious decision
4) Transition from insecure to secure state is possible
5) Secure defaults are inherited
6) Exception lists have first class support
7) Secure defaults protect against pervasive vulnerability exploits
8) Security limitations of a system are explainable

Оказывается более подробно о каждом из принципов можно узнать из отдельного файла "Secure Defaults: Cloud Native 8"! Каждый пункт расписан с точки зрения:
- назначения и причины его появления в данном списке
- как можно реализовать
- примера

Стал доступен фотоотчет с нашего первого БЕКОН!

Attacking and securing cloud identities in managed Kubernetes part 1: Amazon EKS – первая статья из цикла про атаку и защиту managed Kubernetes (Amazon EKS).

Автор довольно подробно разбирает, то как работает аутентификация и авторизация в EKS кластере, а потом на примере уязвимового веб-приложения демонстрирует как можно застилить Node credentials через IMDS, а также показывает pivoting технику для продвижения по AWS облаку. Безусловно, без ряда оговорок с неправильной конфигурацией самого кластера ничего бы не вышло.

В конце упоминается тулза MKAT (о которой мы рассказывали ранее), она будет полезной если вы хотите проверить защищенность вашего EKS кластера.

Если говорить о remedations, то это в первую очередь:

1) Использование сетевых политик, для ограничения доступа Pod к IMDS
2) Выставление http_put_response_hop_limit = 1
3) Использование IAM ролей для ServiceAccount с целью аутентификации рабочих нагрузок Kubernetes в AWS.

Закончим эту неделю достаточно низкоуровневой темой базирующейся на устройстве Linux и ее связью с Kubernetes. А навеяно это все заметкой "Access Kubernetes Objects Data From /Proc Directory". Там рассказывают и показывают:
1) Какую роль играет /proc в Linux
2) Как через /proc можно дотянуться до данных в etcd
3) Как через /proc можно дотянуться до переменных окружений процессов, работающих в контейнерах, в Pods

Как вы понимаете это все верно только для классических контейнеров, которые по сути представляет из себя linux процессы с определенными свойствами (namespaces, cgroups и т.д.).

А что это может дать злоумышленнику? Злоумышленник попавший на Node для доступа к информации контейнеров может не порождать интерактивный shell или выполнять команды в них, а методично пройтись и узнать все необходимое через /proc.

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

На следующей неделе - 26-27 июня в Санкт-Петербурге во время белых ночей пройдет Saint HighLoad++ 2023. Наша команда там будет, можно встретиться, поговорить про безопасность контейнеров и Kubernetes! Также это прекрасная возможность заполучить наш стикер пак c БЕКОН ;)

На недавно прошедшей конференции fwd:cloudsec 2023 был довольно интересный доклад, напрямую затрагивающий безопасность Kubernetes – Swimming with the Sharks. IR Kubed.

Спикер рассказывает о реагировании на инциденты в Kubernetes с сетевой точки зрения. Весь доклад крутится вокруг инструмента kubeshark, который позволяет мониторить и захватывать трафик в Kubernetes в режиме реального времени. По сути тулза выполняет функционал TCPDump и Wireshark, но в контексте Кубера.

Наша команда около года назад уже рассказывала про особенности DFIR в Kubernetes – в докладе Специфика расследования инцидентов в контейнерах. Будет в тему, советуем ознакомиться.

На недавно прошедшей конференции BSides NYC 2023 был представлен доклад "Analyzing volatile memory on a Google Kubernetes Engine node" (статья, видео, репа) от ребят из Spotify. В принципе из названия понятно, что речь идет об анализе памяти снятой во время инцидента для последующего расследования. Для этого они делают следующее:
1) Создание kernel memory dump (работа с /proc/kcore)
2) Получение символов для данного ядра (причуды COS и не документированное API)
3) Анализ kernel memory dump

Это они показывают на примере 3 open-source инструментов: AVML, dwarf2json, Volatility 3. Не всегда и везде это, конечно, получиться провернуть, но как вариант почему бы и нет.

У себя в Luntry мы уже реализовали подобное с рядом особенностей, обходящих ограничений такого подхода. На пример, нет смысла снимать дамп для всей Node, когда экономичнее все сделать для конкретного контейнера и все.

Одно из интересных свойств container registries заключается в том, что они по сути являются большими хранилищами файлов.

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

Например, с помощью crane:

crane export raesene/alpine-containertools - | tar -Oxf - usr/local/bin/kubectl > kubectl

Узнать про другие возможности crane можно тут.

Если вы хотите изучить файловую систему контейнера на разных слоях это можно сделать с помощью dive или онлайн ресурса https://explore.ggcr.dev/

К слову, registries можно также использовать при пентесте для эксфильтрации данных.