"ABSTRACT SHIMMER (CVE-2020-15257): Host Networking is root-Equivalent, Again" - отличный технический рассказ с примерами кода о том, как находилась, исследовалась уязвимость CVE-2020-15257, о которой я писал раньше.

При прочтении вы узнаете о том, как работает containerd-shim, как закрыли данную уязвимость и как ее можно проэксплуатировать. Сам исходный код эксплоита автор собирается выложить 11 января, НО по статье его можно написать и самостоятельно.

Готовя/актуализируя свой тренинг по безопасности cloud native приложений в Kubernetes, обнаружил что (в версии 1.19) альфа фича DynamicAuditing и auditregistration.k8s.io/v1alpha1 API были депрекейтнуты и удалены. А данная фича мне очень нравилась - можно было очень быстро и удобно управлять своими обработчиками логов через ресурс AuditSink.

Так что в качестве backend остались только: Log backend и Webhook backend.

CVE-2020-8569: snapshot-controller DoS

Уязвимость среднего уровня критичности может привести к отказу в обслуживании компонента snapshot-controller через неавторизованный API запрос. Связано с тем, что атакующий может указать такой `VolumeSnapshot, который будет ссылаться на несуществующий PersistentVolumeClaim. Данный компонент будет падать, перезапускаться и снова падать. Доступ же к самим snapshots атакующий получить не сможет.

snapshot-controller это опциональный компонент Kubernetes, который включает volume snapshot фичу. Если вы его не используете, то и беспокоиться не о чем.

Наконец полностью изучил документ Cloud Native Security Whitepaper.

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

Целевая аудитория у него и в правду это CISO, CSO, CTO, Architects и люди, которым надо быстро вникнуть в суть Cloud Native Security подходов/решений что представлены на рынке. Там перечислено все что только возможно, но далеко не все из этого нужно и, конечно, не все всё себе из этого могут позволить.

А некоторые интересные моменты я обязательно рассмотрю на канале.

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

Risk8s Business: Risk Analysis of Kubernetes Clusters

Отличный гайд в стиле "zero-to-hero" по управлению рисками в Kubernetes. Читается очень просто, быстро и понятно - очень рекомендую.

Основную мысль, которую вы должны вынести после прочтения это вы должны понимать свое окружение (контекст очень важен), чтобы правильно оценивать риски и правильно выбирать подходы/методы/инструменты для их минимизации и/или избавления. Безопасность это процесс управления рисками! Все бизнесы, все сервисы, все Kubernetes разные. Не действуйте вслепую!

Закончу прекрасной цитатой автора: "While there are some things you should consider tooling up for like vulnerability scanning, runtime security verification, and storage permission checks, you’ll never be able to definitively conclude its overall risk without the context of its environment."

Крохотная заметка от авторов сетевого плагина Cilium о возможности данного CNI из коробки работать без использования kube-proxy и тем самым быть не подверженным MitM атаке из-за CVE-2020-8554: "we don't translate an ExternalIP address for traffic sourced from pods unless the ExternalIP is associated with a known node."

Еще в заметке немного общих данных о MitM атаках в Kubernetes. Также немного разговора о Zero Trust Networking и то, что они стараются смягчить возможности общеизвестных MitM атак (насколько это правда еще нужно поисследовать).

Напомню, что Cilium базируется на технологии eBPF.

В версии 1.20 до GA ветки добрались фичи для улучшения безопасности service account tokens.

Теперь Pods могут запрашивать service account tokens с улучшенной безопасностью.
Теперь kubelet может проецировать service account token в Pod с желаемыми свойствами, такими как аудитория и срок действия (для default token это не работает). При этом этот token станет недействительным для API при удалении Pod или ServiceAccount. Такое поведение можно сконфигурировать в PodSpec используя ProjectedVolume тип под названием ServiceAccountToken. kubelet будет заниматься ротации, но само приложения ответственно за подтягивание нового token.

Для всего этого вам придётся сконфигурировать соответствующие флаги для kube-apiserver (по умолчанию это не включено).


Какая из этого огромная польза для безопасности можете прочитать в KEP раздела Background (на скрине).

Инструмент DEEPCE, название которого является абревиатурой от фразы Docker Enumeration, Escalation of Privileges and Container Escapes. Название говорит само за себя.

Для максимальной совместимости весь инструмент написан на sh без каких-либо зависимостей (1234 LoC). Но для ряда задач он все же ожидает что внутри также окажутся тулзы: curl, nmap, nslookup, dig. Также учитывайте, что при эксплуатации ряда векторов он может создавать контейнеры, перезапускать runC, что потенциально может навредить системе - будьте осторожны. При этом есть классная возможность скачать и запустить его без записи на диск:

wget -O - https://github.com/stealthcopter/deepce/raw/master/deepce.sh | sh

Поддерживаемые эксплоиты:
- DOCKER - использование docker group
- PRIVILEGED - использование привилегированного контейнера
- SOCK - использование docker sock
- CVE-2019-5736
- CVE-2019-5021
- CVE-2019-13139

Применимо ли это в Kubernetes? Да! Инструмент даже знает про kubectl ;)

Сегодня пост из категории мысли в слух.

За последнее время появилось достаточно много статических анализаторов ресурсов (Terraform, Helm, Kubernetes и т.д.) для проверки их в репозитариях, которые по заветам GitOps являются единственным источником правды. Это могут быть проверки как на best-practices, так и на security.

Но есть ли уверенность в том, что мы увидим тоже самое после выкатки этих ресурсов? Ответ: совсем не обязательно - статическая и динамическая картина могут отличаться.

В процессе выкатки, MutatingAdmissionWebhook может внести туда множество изменений. В качестве примера: переменные окружения, init и sidecar контейнеры, изменение LimitRange и ResourceQuota, установку privileged режима, монтирование директорий и т.д. Это может быть как с благими, так и с вредоносными намерениями (ну или для обхода ограничений в угоду более быстрой разработки).

Может помочь ValidatingAdmissionWebhook, но не стоит забывать, что если условие было добавлено спустя какое-то время, то в инфраструктуре уже могут существовать ресурсы, не подходящие под его условия. В одном из своих постов я уже писал, что возможно и создание вредоносных ValidatingAdmissionWebhook. Создание вредоносного MutatingAdmissionWebhook злоумышленником/инсайдером или просто не очень квалифицированным сотрудником также возможно.

Динамическая природа Kubernetes вносит свои коррективы в жизнь ресурсов и это надо учитывать, как и строгий контроль того кто и что делает с помощью MutatingAdmissionWebhook и ValidatingAdmissionWebhook.

kubestrike - инструмент на Python для идентификации security misconfigurations (по сути своей слабых и не безопасных настроек) в Kubernetes (как self-hosted, так и Amazon EKS, Azure AKS, Google GKE и т.д.).

Есть поддержка двух режимов сканирования:
- Аутентифицированное (нужен токен с read-only привилегиями)
- Не аутентифицированное (возможно в случае наличия анонимного доступа в кластере)

Текущие возможности:
- Анализ IAM в кластере, привилегированных субъектов в кластере , контейнеров, сервисов, Pod Security Policies, Network Policies
- Возможность запускать команды в контейнерах
- Предоставляет информацию о потенциальных возможностях поднятия привилегий

Все проверки можно поискать по коду по паттерну [+] Scanning for их достаточно много. Сам инструмент по своей сути просто yet another tool для Kubernetes, но может кому и приглянется.

P.S.Вспомнил как еще в бытность редактором рубрик "X-Toolz"и "Security soft" в журнале "Хакер" приходилось к выпуску готовить по 15-30 tool

"Improving Kubernetes and container security with user namespaces"

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

Из этой статьи вы узнаете, что такое и зачем нужен user namespace, как он влияет на безопасность контейнеров. И самое интересное, что необходимо изменить со стороны файловой системы, Container Runtime и Kubernetes volumes, чтобы это наконец смогло заработать в самом Kubernetes. Работа кипит и за ней можно следить тут.

Статья просто MUST READ, в процессе чтения раскрывается много не самых простых и очевидных базовых моментов работы контейнеров, который очень важны для понимания.

Дополнительно можно почитать как к таким изменениям подошел Netflix в своей системе оркестрации контейнеров Titus.

Всем, привет!

Сегодня в преддверии праздников хочется рассказать и сказать спасибо за помощь и содействие моим друзьям и товарищам с других Telegram каналов, за которыми я слежу и с которыми мы хорошо общаемся:
- Технологический Болт Генона
- DevSecOps Talks
- CloudSec Wine

В наше время нет проблем с наличием информации, есть проблемы с ее фильтрацией - нахождением полезной и нужной информации в море маркетинга и рекламы. Читайте разные каналы, анализируйте информацию - помните, что у вас всегда есть своя голова на плечах ;)
Особенно это важно для Cloud Native инфраструктур/сервисов/приложений, где все очень разное, разнообразное и то, что отлично работает у одних, может быть совершенно не применимо у вас.

Всем, привет!

Ребята с не малоизвестного ресурса Habr пригласили меня сегодня в 19:00 (Мск) поучаствовать в их видкасте.

Тема:
Инфобез как война роботов

Описание:
Многие уловили момент, когда информационная безопасность перешла из стадии человек против человека в стадию человек против машины, но пропустили, когда же инфобез стал войной роботов. А между тем фактически вся ИБ уже работает на ИИ. Так когда это произошло? И какие форматы предиктивной защиты подарило нам машинное обучение? Чем теперь занимаются освободившиеся люди? Как дальше будут эволюционировать машинописные угрозы? Обсуждаем все, что касается настоящего и будущего инфобеза.

Online можно смотреть в VK, Facebook и YouTube.

Kyverno - Kubernetes Native Policy Management.

Проект также как и OpenPolicyAgent (OPA) находится под эгидой CNCF, но при этом известен/распиарен куда меньше. OPA мне всегда нравился, но при этом меня смущало в нем необходимость использование/знание Rego (считай еще одного ЯП). Это можно сказать прям ломало Kubernetes Native подход ...

Kyverno же использует для своей работы только YAML и очень прост в работе, если вы можете читать описание ресурсов, то и написать политику для него вам не составит труда!

Если их сравнивать, то OPA, конечно, способен покрыть не только Kubernetes (но нужно ли вам это вообще?) и его язык дает более широкие возможности (переменные, хранилища ресурсов и т.д.) (но я с ходу смог придумать только 1 такой кейс ...).

Но и у Kyverno есть свои фишки можно делать не только операции Validating, но и Mutating и Generating с ресурсами. Конечно, при использование последних двух опять GitOps в пролете, но может быть очень полезно ;) При этом они оба умеют сканировать ресурсы, которые уже работают в системе (у одного это называется Audit у другого Background Scans).

Лично мне ближе Kyverno как минимум тем, что он сохранят единый язык общения между Dev, Ops и Sec командами и они продолжают понимать друг друга. Очень важно, чтобы безопасность не была 'блокером', а прозрачно встраивалась для всех.

Контейнеры versus VM

В рамках своего канала я уже не однократно рассказывал, что в качестве container runtime в Kubernetes можно использовать VM. Изучая данное направление, следя за их развитием, я все больше убеждался в крутости использования VM, базирующейся в первую очередь на их высокой изолированности (и безопасности).

НО если посмотреть на них не с точки зрения безопасности, то можно заметить как очевидные, так и не очень ограничения и недостатки. Во-первых, это определенные требования к окружению/железу - не везде VM запуститься (тут еще стоит помнить про разные типы виртуализации full, paravirtualization, nested) и не любой сервис вам даст это сделать. Во-вторых, очень сильную изоляцию чаще рассматривают не в контексте security, а в контексте multitenancy, что далеко не всем вообще надо. В-третьих, сильно падает (исчезает?) observability происходящего внутри контейнеров. Если в случаи классических контейнеров для вас это такие же linux процессы просто с определенными свойствами, то в случаи VM это несколько общих процессов, представляющих для вас "черный ящик". И наблюдать за происходящим там можно только за тем, что вы сами или разработчики VM запрограммировали для передачи наружу в систему мониторинга, а любимые и проверенные инструменты уже не помогут.

Третий пункт лично для меня (как в прочем и для ИБ) наиболее критичный. Наличие любого "черного ящика" в системе затрудняет как обнаружение, так и расследование инцидентов.

P.S. Уверен есть и другие ограничения и недостатки - можно их собрать в комментариях.

BPFBox - Exploring process confinement in eBPF.

Очень интересный академический проект, о котором вы могли слышать на eBPF Summit 2020 в докладе "bpfbox: Simple Precise Process Confinement with KRSI and eBPF". Он точно не готов для использования в prod окружении. Там много чего не хватает, да и требования к ядру > 5.8 (таких ядер в prod я ни у кого еще не видел). Такая высокая версия ядра обусловлена требованием наличия KRSI (Kernel Runtime Security Instrumentation), который в upstream появился только с 5.7, и типу ringbuf map (5.8+).

Сам проект использует eBPF и позволяет ограничивать user-space и kernel-space вызовы в соответствии с описанной политикой. Можно представить себе это как будущее sandboxing и prevention систем. И можно это использовать как для standalone приложений, так и для контейнерный приложений в Kubernetes, без вреда стабильности работы и сложности SELinux или AppArmor.

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

Подробнее о проекте можно узнать из документа "bpfbox: Simple Precise Process Confinement with eBPF".

Есть такой замечательный инструмент как osquery. Он превращает вашу ОС на базе Linux, macOS, Windows, FreeBSD в реляционную БД (набор SQL табличек) и позволяет запрашивать из них данные о системе (пользователи, железо, процессы, ФС и т.д.) по необходимости или с определенной периодичностью, что может быть полезно для мониторинга или аналитики. У инструмента даже есть своя конфа QueryCon, где ее пользователи делятся своим опытом и наработками. Первая версия появилась в сентябре 2014.

В ноябре 2020 года появился проект cloudquery. Он был вдохновлен osquery и terraform и является compliance-as-code инструментом. Он также представляет вашу облачную инфраструктуру в виде SQL или Graph (Neo4j) базы данных. Сейчас инструмент поддерживает:
- AWS
- Azure
- GCP
- Okta
- Kubernetes (alpha стадия)

O Kubernetes инструмент знает только информацию о Pods и Services и пока все. Получает он это через Kubernetes API. Для AWS есть готовый AWS CIS policy pack.

P.S. kube-query экспериментальное расширение для osquery для поддержки Kubernetes + пример его использования.

В связи с нашумевшей атакой на SolarWinds очень остро стал вопрос с атаками на цепочку поставок (supply chain).

Давайте повернем это все в наш контекст - контекст приложений для Kubernetes. Что мы имеем:
1) Open Source код - а кто его сегодня не использует? Начиная от ваших собственных разработок, заканчивая инструментов/тулов что вы используете в готовом виде и коммерческих решений.
2) Образы контейнеров - тут сходу вспоминаются истории как на DockerHub залиты образы с backdoors и вредоносным кодом.
3) k8s ресурсы - такая своего рода обертка над контейнерами, которая также позволяет и внедрить что-то не очень заметно, так понизить уровень безопасности самого контейнера.
4) Helm чарты - наверно вершина этой пирамиды, призванная максимально упростить процесс установки приложений в кластер. И часто вы их читаете полностью что там написано? И легко ли это вообще сделать? Скорее нет ;)

В ситуации с SolarWinds был заражен их продукт Orion (это кажется платформа мониторинга). Долгое время вредоносная активность от этого решения была не замечена, а все из-за того что никто и не знал как оно работает (что может делать, а что нет - считай черный ящик). А также относились к нему как к доверенному компоненту системы - а в наше время без ZeroTrust подхода уже никуда.

В случае Kubernetes инфраструктуры при правильном подходе такое можно было бы обнаружить без супер усилий. На помощь приходит и observability, visibility в контейнерах и иммутабильность образов контейнеров с NetworkPolicy, PodSecurityPolicie для ZeroTrust.

Выложили запись workshop'а на тему "Applied Defense On Docker And Kubernetes" продолжительностью 2,5 часа с конференция HackInTheBox (язык английский). Очень люблю данную конференцию, сам там выступал и хорошо общаюсь с их главным организатором.

В самом workshop’e его участники по мне так могут узнать только основную базу - подробнее можно посмотреть agenda в программе:
- Docker
• Kernel namespaces
• Kernel capabilities
• Mandatory Access Controls
• Container UID & GID
• Userns-remap
• Distroless

- Kubernetes
• API Authentication
• API Authorization
• Security Context
• Security Policies
• Network Policies

Так что я не согласен с утверждением автора: "Students will walk away having learned the advanced security features of Docker & Kubernetes."

И сам workshop по мне полностью повторяет выступление автора с конференции BlackHat USA 2020 под названием "Defending Containers Like a Ninja: A Walk through the Advanced Security Features of Docker & Kubernetes", свое мнение о котором я уже писал ранее тут.

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

А речь сегодня пойдет о ресурсе `PodDisruptionBudgets (сокращенно `PDB), который может помочь избежать простоя в работе Kubernetes-кластера. Чаще всего вы, конечно, найдете упоминание данного ресурса при описании Zero Downtime Deployment или Upgrade кластера. Данные ресурс описывает квоту неработающих Pods. Важно также понимать отличия принципов работы PodDisruptionBudgets и Deployment.

По мне это он идет в туже копилку что и LimitRange и ResourceQuota, о которых я писал ранее.

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

Ни один инструмент вам не поможет, если он не используется или результат его работы попросту игнорируется. Также куда больше бед вам может принести, хождение разработчиков на prod кластера, чем не соответствие best-practices. При этом разработчик (или кто-то другой) не только могут нанести вред по неосторожности или невнимательности, но и быть скомпрометированы и сразу подарить атакующему билет в prod кластер.

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