Некоторое время назад мы уже обсуждали тему специально подготовленного image для пентеста контейнерных инфраструктур. И там речь шла о проекте botty. Сегодня хотелось бы представить проект под названием hacker-container, который сам автор описывает как: "Container with all the list of useful tools/commands while hacking Kubernetes Clusters" . На борту данного контейнера порядка 52 инструментов и есть еще список todo, что автор хочет туда добавить.

Сравнивая инструменты, что есть в его составе и в составе botty можно достаточно легко прийти к выводу, что хоть в botty и меньше инструментов, но они там больше специализируются и на контейнерах и на Kubernetes и на облаках в целом. В составе же hacker-container есть много сканеров, брутеров и других инструментов, для классических сетевых и web пенестов.

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

На сайте конференции KubeCon + CloudNativeCon Европа 2020. Выложили слайды и транскрипции выступлений (где-то только транскрипции, видео пока не доступно).
- Доклады с KubeCon + CloudNativeCon (+ фильтр "Security + Identity + Policy")
- Доклады с Cloud Native Security Day

Попозже обязательно рассмотрим отдельно наиболее интересные доклады по теме security.

В версии Kubernetes 1.19 поддержка seccomp перешла в статус General Availability (GA) (начало было положено в 1.10)! Благодаря данной штуке можно повышать безопасность ваших workload'ов с помощью ограничений допустимых системных вызовов для определенного Pod'а (и всех контейнеров внутри него) или чисто для определенного контейнера. Это сузит Attack Surface для злоумышленника и может ему очень сильно усложнить попытки поднять свои привилегии или сбежать из контейнера. Задаются эти профили в securityContext в seccompProfile секции spec при описании Pod или в PodSecurityPolicy. Более технические моменты реализации данного механизма можно посмотреть в KEP - Seccomp to GA.

Подробнее о использовании seccomp в Kubernetes можно почитать на страничке tutorials. Там же можно посмотреть, как выглядят данные профили.

Проблемой для применения в проде seccomp по-прежнему остается сложность создания полноценных fine-grained профилей, что может привести к аварийному завершению приложения. Имеющиеся инструменты oci-seccomp-bpf-hook, go2seccomp, а также "SCMP_ACT_LOG" режим самого seccomp имеет ряд недостатков и ограничений ... Хотя для начала можно начать и с типа RuntimeDefault, но нет гарантий что даже он у вас заработает.

C релизом Kubernetes 1.19 увеличилось окно поддержки с 9 месяцев до 1 года (начиная только с этой версии!). По-простому, теперь вместо поддержи 3 релизов, будет поддержка 4 релизов, что и увеличит поддержку до 1 года.

Раньше нужно было обновляться как минимум 1 раз в 9 месяцев чтобы иметь поддерживаемую версию.

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

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

Поговорим сегодня о Honeypots, а именно о Honeypot stack на Kubernetes под названием beehive. В этот стек сейчас входит 15 honeypot'ов, покрывающих:
- Android Debug Bridge over TCP/IP
- Cisco ASA honeypot
- ICS/SCADA honeypot
- SSH/Telnet honeypot
- dionaea honeypot
- Elasticsearch honeypot
- Credentials catching honeypot
- Low to medium interaction honeypot
- TCP or UDP services honeypot
- SMTP Honeypot
- HL7 / FHIR honeypot
- RDP honeypot
- Web application honeypot sensor

И за всем смотрим логи с помощью Elasticsearch и Kibana.

Если ваше приложение уже работает в K8s, то можно очень просто сделать honeypot инсталляцию вашего сервиса или специальную тестовую инсталляцию для растерзания при аудите/пентесте или BugBounty, чтобы случайно не пострадали пользовательские данные. K8s позволяет очень быстро и гибко развернуть вашу уникальную приманку (ваш собственный сервис) как у себя локально, так и в любом облаке, в любом масштабе. В данном направлении уже есть выступления на конференциях ("How to Deploy Honeypots into your Kubernetes"), так и отдельные статьи ("Creating and Deploying Honeypots in Kubernetes"). Это позволит ловить на 1-day так и 0-day атаки на ваше приложение. Тут главное, чтобы у вас был хороший мониторинг нацеленный на Container RunTime Security.


Вся тема honeypot'ов получила в последнее время вторую жизнь благодаря лозунгам "Detection through Deception", "Security Through Deception" и продуктам класса Deception Technology (спасибо маркетологам).

Выложили видео выступлений с KubeCon + CloudNativeCon Europe 2020

Выложили ряд видео докладов с Cloud Native Security Day:

- Opening Remarks - Emily Fox, US National Security Agency
- Collection is not Detection - Sec Ops in a Cloud Native Environment - Sarah Young, Microsoft
- PARSEC: A New Platform Abstraction for Security - Hugues de Valon & Ionut Mihalcea, Arm
- Image Provenance and Security in Kubernetes - Adrian Mouat, Container Solutions
- Cloud native or cloud agnostic? The questions you need to ask - Sriram Rajan, Rackspace
- How Secure Is Your Build/Server? - Patrick Debois, Snyk
- Pod Security as an Afterthought - Alban Crequy, Kinvolk
- Defenders Think in Lists. Attackers Think in Graphs. - Reuven Harrison, Tufin
- Kubernetes Attack and Defense: Inception-Style - Jay Beale, InGuardians
- New Paradigms for the Next Era of Security - Sounil Yu, Cyber Defense Matrix
- Closing Remarks - Brandon Lum, IBM

Интересная (но предсказуемая) эволюция арсенала преступной группы TeamTNT, атакующей облачные окружения, включая Docker, Kubernetes. Теперь на ряду с криптомайнерами, зараженными docker образами есть и легитимные инструменты. В частости известный инструмент для мониторинга Weave Scope. Они используют его для составления карты окружения жертвы, выполнения системных команд без деплоя вредоносного кода. В результате они получают мощный backdoor на основе легитимного инструмента.

Развитие атаки:
1) Через доступный Docker API устанавливают привилегированный контейнер с чистым образом Ubuntu
2) Данный контейнер сконфигурирован с маунтом к файловой системе сервера жертвы для полного доступа к файлам сервера
3) Скачивание и выполнение криптомайнеров на сервере
4) Попытка получения root доступа на сервере и создание пользователя ‘hilde’ для соединения по SSH
5) Скачивание и установка Weave Scope с git
6) Подключение к Weave Scope dashboard по HTTP на 4040 порт для полного контроля инфраструктуры жертвы.

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

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

При проектирование своего Kubernetes кластера чрезвычайно важным его элементом является Container Runtime. При этом мало кто знает, что он, по сути, состоит из 2 частей: High-level Runtime и Low-level Runtime.

High-level Runtime (CRI Implementations):
• Dockershim
• CRI-O
• Containerd
• Frakti
• rktlet

Low-level Runtime (OCI Runtimes):
• runC
• runV
• Clear Containers
• kata-runtime
• gVisor


Изучая и сравнивая Docker и Containerd - можно лишний раз убедиться, что специализированное решение (Containerd) лучше, чем решение общего назначения. Для этого я сравнил security related информацию, выдаваемую командами crictl inspect <containerid> и docker inspect <containerid>. По мимо той же прямой связи с ресурсами Kubernetes есть и нформация по capabilities, seccomp настройкам работающего контейнера.

Отдельно советую посмотреть слайды "How Container Runtimes matter in Kubernetes?" про сравнение данных вещей в плане производительности и более новое исследование "Performance Evaluation of Container Runtime".

На днях от одного security вендора вышел отчет "2020 Cloud Native Threat Report: Evolution of Attacks in the Wild on Container Infrastructure". В отчете авторы рассматривают "attacks against cloud native environments".

Мой же взгляд что атакующие в первую очередь не cloud атакуют, а приложения, сервисы и они могут даже не знать где это все располагается. Облачные/контейнерные технологии как и любые технологии изменяют/расширяют attack surface (те самые misconfigured Docker API). И глупо было бы со стороны злоумышленников к своим сканам приложений на различные RCE, не добавить еще и этот крутой мисконфиг.

Отчет строится на основе результатов полученными с помощью honeypots. Honeypots очень классная штука. ТОЛЬКО в зависимости от того, как он "приготовлен", такие результаты и получаться! Глупо ожидать от honeypots с misconfigured Docker API, ловли RCE атак на Redis, Nginx, WordPress и другие приложения, что крутятся и смотрят в интернет в ваших сервисах.

К сожалению, авторы совсем не описали свою методологию тестирования ... Говорится что "In 100% of the attacks, the initial access was ‘Exploit Public-Facing Application’.", то что это за приложения непонятно. Скорее всего Honeypot это misconfigured Docker API и все.

По мне заголовок отчета не соответствует содержимому и более правильное название — это "Анализ вредоносных images".

P.S. В отчете нет ни одного упоминания Kubernetes/k8s. Хотя можно было бы в интернет вытащить и порты от его сервисов (etcd, dashboard и т.д.) и вообще много чего еще интересного ;)

Интересную заметку в своем блоке опубликовали исследователи из одной security-компании - "Falco Default Rule Bypass".

Обходы заключаются в логической ошибке в описании двух достаточно серьезных правил детектирования: "Launch Sensitive Mount Container" и "Launch Privileged Container". Из-за этой ошибки атакующий может создать такие images, что при их использовании система Falco ничего не увидит и промолчит.

За данным проектом я наблюдаю давно и для меня всегда оставалась загадкой его целевая аудитория?!

Если предполагается что предопределённые правила нужны новичкам, то в это не укладывается конфигурирование файла falco_rules.yaml (объем которого боле 1600 строк). Для его грамотной настройки явно порог входа не новичок. Тут нужно и Kubernetes понимать и то, как работают все ваши сервисы. Часть правил к вам вообще может быть не применима или применима не всегда и не везде в вашей инфраструктуре. А с учетом того, что сервисы меняются/развиваются, то и данный файл с правилами также надо своевременно редактировать. И как мы видим в блоге ни сами авторы инструмента, ни вы при редактировании правил не застрахованы от ошибок.

Если предполагается что предопределённые правила нужны большим и зрелым security командам, то большинство из его детектов можно закрыть другими механизмами, встроенными в сам Kubernetes. Например, Admission Control, PodSecurityPolicy, NetworkPolicy + Logging. Есть конечно и прецеденты, кто использует его, но тут надо иметь очень зрелый цикл разработки, слаженное взаимодействие между командами + приличную security team, что могут позволить себе далеко не все. Так как иначе это поддерживать в актуальном состоянии будет очень-очень тяжело.

Также Falco позиционирует себя как детектор аномального поведения и при этом базируется на человека созданных предопределенных правилах... При этом абсолютно естественно, когда, например, в одном image запуск процесса bash это аномально, а для другого это нормально. Так что это будет в итоге? Или на этот случай надо модифицировать правила для каждого image?

Замечательная заметка "Impact of CVE-2020-14386 on Kubernetes and Containers (Docker)" лишний раз не дает забыть о том, что безопасность хоста, на котором работает Kubernetes это также часть безопасность Kubernetes инфраструктуры.

Здесь речь идет о критической уязвимости ядра Linux - CVE-2020-14386, благодаря которой можно поднять свои привилегии до root'а или сделать побег из контейнера на Node, на которой он работает. Атакующий способен эксплотировать данную уязвимость, выполняя свой код внутри Pod'а с CAP_NET_RAW capability.

Естественно, это далеко не первая и не последняя уязвимость в ядре Linux которая позволяет делать "container escape". И все это никакими правилами и сигнатурами заранее не описать, не предусмотреть.

Что в таком случае делать для защиты?
1) Можно/нужно мониторить аномальную активность внутри ваших контейнеров. Так или иначе атакующему придётся для побега из контейнера делать то, что ранее в контейнере у вас не происходило. Это позволит вам ловить не только попытки "container escape", но и другу. Вредоносную активность внутри контейнера (Lateral Movement, запуск манейров и т.д.)
2) Можно присмотреться к защищенным/усиленным вариантам Low-level Runtime (OCI Runtimes) о которых говорили ранее. Но стоит учитывать, что они, как и любое ПО сами не застрахованы от уязвимостей, а просто сильно уменьшают и усложняют attack surface. Так GKE Sandbox использует для этого gVisor.

Уже давно хочу написать о докладе "Advanced Persistence Threats: The Future of Kubernetes Attacks" и чтобы на него обратило как можно больше не равнодушных к безопасности Kubernetes людей.

Сразу стоит отметить, что все продемонстрированные атаки в докладе предполагают, что атакующий так или иначе стал администратором кластера. А возможно это вообще недовольный кластер админ перед своим увольнением =)

Основная суть не в том, чтобы стать кластер админом, а закрепиться на кластере - получить Persistence. В общем, это краткое пособие о том, как могут оставить backdoor в вашем кластере.
Сценарии:
- Вредоносный validating webhook - во время валидации все что надо отправляется атакующему
- Shadow API Server - теневой kubeapi server с отключенной безопасностью лазит в etcd и забирает все что надо.
- C2BERNETES - С2 на базе k3s
- Вредоносное использование фич 1.19 для возрождения kubelet-exploit

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

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

Многие думаю не особо следят за CNCF Special Interest Group on Security, но в ней сейчас кипит работа над очень интересным документом "Cloud-Native Security Whitepaper" для CISO, CSO, CTO, Architects, целью которого является безопасность Cloud Native приложений. Как говорят сами авторы: "Our perspective for operators, what they should be thinking when considering cloud native security. How to inject security into the pipeline, not as an afterthought."

Документ находится еще в статусе WIP, так что его более детальный анализ проведем по его релизу. Но пробежавшись по нему могу сказать, что это очень достойный документ. Отличная работа SIG Security Group!

В своих постах я не раз отмечал чрезвычайную важность безопасности etcd. Если у атакующего есть туда доступ, то это GAME OVER.

На страницах документации etcd в разделе Operations guide есть секции "Role-based access control" и "Transport security model", на которых и строится базовая безопасность данного компонента Kubernetes кластера.

В первой секции говорится о работе с пользователями, ролями и аутентификацией, а во второй насчет транспортной безопасности на основе 4 примеров:
1: Client-to-server transport security with HTTPS
2: Client-to-server authentication with HTTPS client certificates
3: Transport security & client certificates in a cluster
4: Automatic self-signed transport security

Все больше компаний начинают переходить на Kubernetes (не важно внутренний или managed в облаке) или по крайней мере присматриваться к нему. Логично что в начале возникает вопрос: а с чего необходимо начать формирование его безопасности?

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

Далее идут всем хорошо известные встроенные механизмы безопасности Kubernetes. НО нужно помнить, что в каждой компании Kubernetes уникален почти как снежинка, от компании к компании разные подходы к разработке, культура/процессы работы/разработки, в конце концов разные продукты/сервисы и, конечно, же уровень зрелости в вопросах информационной безопасности.

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

Инструменты/подходы должны не латать дыры, а выстраивать правильный процесс (не забываем, что безопасность — это не состояние, а процесс!) внутри компании. Так на пример использование самого крутого инструмента поиска/анализа инцидентов будет совершенно не эффективным, если команда безопасности будет утопать в этих же инцидентах, не успевая их разбирать.

Подход при котором для решение проблемы "A", возьмем решение "X", для решения проблемы "B" возьмем решение "Z" и т.д. далеко не всем по карману и в условиях быстро трансформирующегося современного бизнеса не эффективен на длинных дистанциях.

Поэтому выстраивайте процессы, а не состояния безопасности и перед тем, как что-то внедрять разбирайтесь в том что и как у вас работает/устроено внутри. Иначе внедрением почти любого security механизма можно очень легко что-то сломать … А знакомство с безопасностью должно быть приятным, а не отталкивающим =)

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

Не все сразу задумываются о важности для безопасности культуры использования tags для images и labels для k8s ресурсов.

Хотя именно благодаря ним с помощью различных selector'ов и других механизмов можно очень гибко применять управлять и контролировать вопросы безопасности. Те же NetworkPolicy, PodSecurityPolicy без этого не взлетят.

Чем раньше вы продумаете стратегию/систему использования tags для images и labels для k8s ресурсов, тем проще вам будет потом использовать различные security и не security инструменты и подходы в будущем. Поэтому уделите время на обсуждение данного вопроса с вашими разработчиками, DevOps специалистами и это сэкономит вам много времени в будущем.

P.S. Не используйте tag latest ;)

Разрабатывая систему защиты для контейнеров, часто сталкиваюсь с вопросами по prevention угроз в них. Исследуя данный вопрос, я выделили 3 типа prevention, которые можно сегодня встретить на рынке:

1) Системный - seccomp, AppArmor, SeLinux в режиме prevention. В общем неувядающая классика. Стабильно и быстро, но не просто.
2) Реакционный - по сути это не prevention, а реакция на угрозу. То есть если что-то случается в контейнере, что там не должно быть, то container runtim’у отправляется команда на выключение контейнера или установку его на паузу. В общем тут не настоящий prevention, а сила маркетинга.
3) Самописный - тот случай, когда prevention реализуется не силами встроенных в ОС механизмами, а собственными силами. На текущий момент все что доводилось видеть на рынке использует различные грязные трюки и хаки. По сути, там инъекции собственных библиотек в системные процессы или процессы приложений. Опасно, медленно, но гибко.

Если вы с разбегу захотите использовать PodSecurityPolicy, то вас ждет разочарование и придется начать с ряда приседаний:
1) Создать саму политику
2) Создать Role/ClusterRole, которая сможет использовать созданную вами политику
3) Создать RoleBinding/ClusterRoleBinding для связи роли с service accounts, users или groups
4) Включить PodSecurityPolicy admission controller

Последний пункт должен быть обязательно таким по очереди иначе вообще ни один Pod не сможет создаться в кластере!

Почему сделано так сложно мне лично непонятно... Использование той же NetworkPolicy куда проще, правда там реализация лежит на стороннем разработчике CNI плагина, а не на встроенном admission controller, как в случае с PodSecurityPolicy.

На выручку при создании PodSecurityPolicy может прийти лишь kube-psp-advisor, выполненный в виде Krew плагина. Он сгенерирует Role, RoleBinding и PodSecurityPolicy в едином YAML файле.

Постоянные читатели моего канала, которые со мной с самого начала, наверняка уже заметили что я достаточно негативно отношусь к таким вещам как предопределенные правила, сигнатуры, строгие чеклисты в виду их возникновения только лишь на знаниях о ТЕКУЩИХ возможностях атакующего. Все эти вещи ассоциируются у меня с предопределенностью, линейностью, некоторой неоспоримой, постоянной последовательностью. Но нет ничего более постоянного, чем временное. Особенно того что касается Agile разработки, развития микросервисов и подходов атакующих ;)

На эту мысль меня натолкнула еще несколько лет назад замечательная статья "The Dangers Of Linear Thinking and Why Security Analysts Should Defend in Graphs".

В статье в качестве примера приводится Incident Response активность, но это применимо и для построения безопасности в целом на мой взгляд это подходит. При построении системы безопасности также появляется подобный граф только разветвления там: А что мы защищаем? А что самое критичное? А какие модели нарушителей для нас актуальны в первую очередь? А как и где мы хотим обнаружить атакующего? А какой attack surface нужно закрыть в первую очередь? и т.д.

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

На пример, многие из тех же проверок CIS benchmark актуальны в основном для внутреннего атакующего, который уже проник на pod/контейнер. Хотя внешний атакующий еще должен стать этим внутренним атакующим. Поэтому слепое следование по списку, чеклистам, бенчмаркам, методикам может оставить более критичные вопросы без внимания.

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

Еще одна очень важная политика на ряду с PodSecurityPolicy, NetworkPolicy в рамках Kubernetes это Audit policy. Логи аудита помогают ответить на вопросы: Что произошло? Кто сделал? Когда? Где?
Данная политика очень гибко конфигурируема можно задать: тип ресурса, за которым мы хотим наблюдать, namespace ресурса, типы операций, совершаемые над ресурсом, конкретные users и userGroups совершающие действия над этим ресурсом. И отдельно еще отмечу:

Уровень детализации:
• None
• Metadata
• Request
• RequestResponse

Стадии логирования:
• RequestReceived
• RequestStarted
• RequestComplete
• Panic

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