k8s (in)security

В ближайшее время пройдет конференция DevOops 2023 и наша команда Luntry примет в этом мероприятии активное участие. А именно: Сергей Канибор представит 1 доклад, а Дмитрий Евдокимов поучаствует в 3 круглых столах!

Доклад:
1) 18 сентября "Network Policy для разработчиков: как, зачем и почему"

Круглые столы:
1) 5 сентября "Безопасность: консультативная vs запрещающая"
2) 5 сентября "Решит ли eBPF все проблемы?"
3) 18 сентября "Безопасность контейнеров в 2023 году. Тренд или необходимость?"

В общем, покроем все темы на которых наша команда специализируется: Kubernetes, безопасность, eBPF и контейнеры. 18 сентября будем рады пообщаться со всеми на площадке DevOops 2023 =)

В день знаний, завершающий эту неделю, поделимся с вами короткой, но очень технической заметкой под названием "Short Note About Container Escapes, Namespaces, and Filesystem Roots". Полезна она будет в первую очередь kernel exploit writers (на пример, участникам Google’s kernelCTF), которым эксплуатации баги ядра из контейнера нужно еще и преодолеть ограничения mount namespace. рассматривается два сценария:
1) Через вызов setns()
2) Через перезапись fs в структуре task_struct

Каждый из способов имеет как свои преимущества и недостатки, что зависят от ситуации, баги, условиях, которые есть при эксплуатации баги в ядре. Так при использовании ROP первый сценарий будет проще, а при наличии arbitrary write примитива второй сценарий будет более стабильным.

Всем хороших выходных!

В Kubernetes 1.28 появилась возможность ограничивать User Namespace у конкретного Pod. Сама по себе фича может довольно сильно уменьшить возможный attack surface. При попытке сбежать из контейнера такой процесс не сможет причинить значительного вреда хосту.

В pod.Spec добавляется булево поле hostUsers. Если его значение true или не задано, то используется пространство имен хоста (как и раньше). Если же false, то для пода создается новый userns.

Тем самым, даже если вы используете уязвимую версию ядра к CVE-2022-0492, можно использовать довольно лаконичную митигацию данного риска. Наглядное демо с тем как это работает можно посмотреть тут.

Мы уже на канале писали про инструмент Atomic Red Team и про его развитие Stratus Red Team. А теперь ребята из DataDog по сути сделали обертку над этим и назвали это Workload Security Evaluator, который позволяет симулировать runtime attacks. Вокруг этого можно в принципе сделать свой BAS (Breach and Attack Simulation).

Точно с такой же идей к нам подходили после нашего доклада "Kubernetes Pentest All-in-one: The Ultimate Toolkit" с OFFZONE 2023, где мы зарелизили наш инструмент MTKPI. То есть можно вокруг него разработать скрипты и получить BAS ;) Возможно что у нас это будет логичное продолжение развития проекта! Ну а также все вы можете принять в этом участие и присылать свои PR в данный Open Source проект.

Istio OutboundTrafficPolicy Egress Control Bypass – интересная статья про обход сетевого ограничения Istio.

Все кто сталкивался с Istio знают, что он для своей работы инжектит sidecar контейнер в довесок к основным, работающим в Pod. Этот sidecar контейнер редиректит трафик с Pod на Istio egress gateway c помощью правил iptables, которые как раз таки определяют возможности сетевого взаимодействия Pod. Но это ограничение можно обойти, если есть возможность получить UID 1337 внутри контейнера.

И это является довольно критичным моментом, ведь контейнеры внутри Pod имеют общее пространство имен. Так что если вы получили root в одном контейнере Pod это значит, что у вас есть root и в другом контейнере. Злоумышленнику, которому удалось попасть внутрь Pod, в котором работает Istio sidecar, достаточно выполнить setuid() и установить UID или GID равный 1337, чтобы подобрать правило iptables для Istio и обойти фильтрацию трафика.

Резюмируя: использование Istio для ограничения egress трафика не отменяет использование Network Policy.

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

P.P.S – хотим напомнить, что сегодня в 11:00 мы проведем вебинар Patch management не поможет, фиксики не спасут, в котором разберем проблемы patch management в реальных условиях.

На недавно прошедшем HITB Sec Conf 2023 в Phuket был представлен доклад "gVisor: Modern Linux Sandboxing Technology". Достаточно любопытное исследование, которое хорошо погружает в тему linux sandbox механизмов и решений. И после погружения в базу автор рассматривает написание собственного "идеального" решения под названием vmjail, который базируется на gVisor (внутреннее устройство, которого также рассматривается).

Самые важные моменты:
- vmjail находиться в разработке и кода не опубликовано
- Проект требует изменение в исходном коде gVisor (достаточно много доработок)
- Проект подразумевает два режима работы: enforce security policy (строго определяем политику) и analysis (мониторим поведение)
- Интересная идея привязки политик OCI spec

Так что, честно говоря, для большинства это исследование будет интересно чисто на уровне теории механизмов Linux ... Будет ли вообще опубликован проект (не говоря уже о его нормальной поддержке) - не известно.

P.S. Все слайды с конференции можно посмотреть тут.

Сегодня наша команда, в лице Сергея Канибора, выступит на конференции OFFZONE 2023 с докладом – Kubernetes Pentest All‑in‑One: The Ultimate Toolkit на AppSec.Zone в 14:00.

Доклад будет посвящён docker образу, который призван упростить жизнь при проведении Kubernetes пентеста. Сам образ появился в результате проведения аудитов и обкатан в боевых условиях. Мы расскажем с какими реальными проблемами и ограничениями можно столкнуться при проведении пентеста k8s, а также поделимся тем, как эти проблемы можно решить.

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

P.S – будем рады пообщаться на тему безопасности контейнеров и Kubernetes ;)

Проект Kuasar как говорят авторы это Efficient Multi-Sandbox Container Runtime. Давайте разберемся что это за зверь такой. Ребята выделяют 3 типа sandbox:
1) microVM
2) Application-kernel
3) WASM

При это они говорят, что нет единого container runtime, может работать со всеми этими sandbox одновременно ... И тут как раз их low-level container runtime написанный на Rust и должен решить эту проблему.

Следующий момент, это то что в недрах containerd, с 2022 идет работа над Sandbox API. И данный проект является по сути первым, который это реализовал/поддержал.

По сути Kuasar соединяет high-level container runtime c sandbox плагинами и sandbox API.

Так это все по сути очень сырое: Sandbox API еще не зафиксировано, containerd по хорошему нужен 2 версии, но он еще не выпущен, ...

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

Ни для кого не секрет, что Istio для своей работы инжектит sidecar контейнер в довесок к основным, работающим в Pod. Однако в Kubernetes 1.28 появилась нативная реализация sidecar контейнеров и статья Kubernetes Native Sidecars in Istio как раз про это!

Один из самых популярных кейсов в issue трекере – продолжение работы sidecar контейнера после завершения работы Job. Теперь у этой проблемы появилось решение. Начиная с версии Kubernetes 1.28 новое featureGate – SidecarContainers призвано решить этот кейс. Для того чтобы Kubernetes понял, что это действительно sidecar – нужно вынести контейнер в initContainers и выставить restartPolicy: Always.

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

Давненько не доводилось попадать в печатные журналы (чуть ли не с времен когда я был одним из редакторов журнала ХАКЕР). Но тут по приглашению друзей поучаствовал в очень интересном формате (offline круглый стол) на тему безопасной разработки. В этом круглом столе поучаствовало 19 организаций и каждая ответила на 7 вопросов. По мне это прекрасная возможность за короткий промежуток времени ознакомиться с различными точками зрения по одной теме. С самим эти круглым столом можно ознакомиться в журнале "Информационная безопасность" №3 (стр. 40-41) или online тут.

P.S. Не забываем о вебинаре «Patch management не поможет, фиксики не спасут», что пройдет 29 августа! А так в живую можно увидеться с нашей командой Luntry на конференции OFFZONE.

Ребята из команды GitHub выпустили заметку "mTLS: When certificate authentication is done wrong" на базе своих исследований представленный на конференциях Black Hat USA и DEF CON. В рамках ее они рассматривают:
1) Что такое mutual TLS
2) Атаки на mutual TLS

Рассматриваются как известные атаки, так и новые на базе уязвимостей:
- CVE-2023-2422 improper certificate validation in KeyCloak
- CVE-2023-33201 LDAP injection in Bouncy Castle
- CVE-2023-28857 credentials leak in Apereo CAS

По нашим клиентам знаем, что периодически компании для организации mutual TLS между сервисами используют не какие-то готовые решения (типа ServiceMesh), а пишут полностью свои. И вот это исследование будет полезно как первым так и вторым ;)

Security Tool Ranking – довольно забавный рейтинг популярности security тулзов. Рейтинг расчитывается по трем критериям: stars, pull requests и issues.

Интересно, что из 50 позиций около 20 так или иначе относятся к направлению Kubernetes security. Это, в свою очередь, говорит о популярности самого Kubernetes в целом.

Однако, слепо верить и доверять таким рейтингам при выборе инструмента не стоит ;)

CNCF опубликовало текст документа "Security Zero Trust using Cloud Native Platforms". Очень достойный документ, который в очередной раз заставляется задуматься о "пользе" постоянных сканирований, использования сигнатур и т.д. В итоге понять какие действительно меры рабочие в текущих реалиях.

P.S. Всем хороших выходных!

15 августа вышла версия Kubernetes 1.28 под кодовым названием Planeternetes! Если говорить о security изменениях, то это в первую очередь:

- CEL-based admission policies webhook match conditions. Использование CEL-выражений для определения области применения admission webhook.
- CRD Validation Expression Language. Для проверки CRD теперь можно использовать CEL.
- CEL for Admission Control. Новый способ контроля через CEL, без необходимости задействовать вебхуки.
- Reduction of secret-based service account tokens. Отмена автоматической генерации секретов для служебных SA.
- Support User Namespaces in Pods. Ограничение привилегированного процесса в Pod.
- KMS v2 improvements. Улучшение сервиса, который используется для шифрования данных etcd.
- Auth API to Get Self-User Attributes. Новая команда kubectl auth who-a-mi позволяет увидеть текущего пользователя после завершения процесса аутентификации.

Со всеми изменениями, которые пришли в версию 1.28 можно ознакомиться тут.

На прошедшем DEFCON в рамках CloudVillage был представлен доклад "CNAPPGoat - A multicloud vulnerable-by-design infrastructure deployment tool". Как не сложно догадаться благодаря инструменту CNAPPgoat можно развернуть различные уязвимые сценарии в различных публичных облаках для тестирования своих detection и prevention возможностей, так и просто для тренировки red и blue team.

Из интересных моментов:
- Написан с помощи Pulumi на Go (Впервые встречаю использования Pulumi в security проекте, а если вы не знаете что это, то если кратко, то: Infrastructure as code in any programming language)
- Содержит приличную базу сценариев (лежат отдельно тут)
- Поддерживает AWS, Azure и GCP

Также обратите ваше внимание на раздел "Similar projects" в конце репозитария, где представлен список подобных проектов.

k8s (in)security pinned a photo

Решили провести вебинар - «Patch management не поможет, фиксики не спасут». В рамках которого хочется раскрыть мысль, которая в наших выступлениях уже звучала, но то это было частью другой темы, то на доклад было 10-15 мин, то доклад был на закрытом мероприятии. А очень хочется это полностью раскрыть (со всеми проблемами) и чтобы все могли посмотреть на проблемы patch management в реальных (не эфемерных) условиях, где есть и атакующие, и другие департаменты, и корпоративные процессы, и разные регуляторы и все это с примерами и т.д. Знаем что многих этот вопрос волнует.

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

Вебинар пройдет 29 августа в 11:00. Зарегистрироваться можно тут.

P.S. К завершению подходит конкурс от конференции DevOops - успейте поучаствовать и выиграть призы ;)

Сегодня продолжаем раскрывать тему из крайнего поста, а именно рассмотрим инструмент, релиз которого произошел на крайнем BlackHat USA.

Речь идёт про konstellation, авторы представили его в рамках BlackHat Arsenal. Тулза умеет делать несколько вещей:

- Собирать данные с Kubernetes cluster (используемые ресурсы, RBAC)
- Показывать BadPods и опасные Role & ClusterRole
- Находить relationships между ресурсами K8S, например RoleBinding → Role
- Визуализировать полученные связи в виде графов в Neo4j

И всё бы ничего, только возникает большой вопрос – а зачем это? Есть ряд других open source инструментов, которые позволяют это делать + удобно отображают результаты. А тут еще ко всему прочему нужно тащить neo4j. Лично мы не увидели никакого преимущества у данного инструмента по сравнению с другими в этой области.

На прошлой неделе состоялись две крупнейшие ИБ конференции в Мире - это BlackHat USA Las Vegas и DEFCON USA. Я знаю о чем говорю, так как на первой мне довелось выступать (включая BlackHat UAE Abu Dhabi), а на второй присутствовать. И вот там было представлено море всего интересного, так что ближайшее время то что касается контейнеров и Kubernetes мы постараемся осветить на нашем канале.

Начнем с темы, которой достаточно редко покрывается на нашем канале — это Windows containers [1,2,3,4]. Доклад называется "Contain Yourself: Staying Undetected Using the Windows Containers Isolation Framework". Здесь вообще нет ничего общего с Linux containers, но нам мой взгляд будет полезно знать что, как и на сколько отличается в реализациях. Ну и как следует из названия доклада потом данная технология используется для того чтобы организовать:
- Ransomware/Wiper protection bypass
- DLP/Secured folders write bypass
- ETW-based correlations bypass

Со слайдами и кодом можно ознакомиться тут.

One-Time Pass Codes for Kyverno...With Quotas! – продолжение статьи (первая часть), в которой рассказывается как можно использовать Kyverno в качестве OTP системы. На этот раз автор представляет вторую, улучшенную версию.

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

Всё что для этого нужно – несколько политик Kyverno: одна для валидации данных, другая для генерации кодов и третья для регулирования квот.

Видео от автора с полной работой системы можно посмотреть тут.