Если вы работаете в compliance team и естественно отвечаете за соответствие тем или иным стандартам, типа NIST-800-53, PCI-DSS, CIS benchmark и т.д. А возможно еще каким-то своим внутренним требованиям в организации, то естественно стает вопрос как это сделать? Да, еще и при условии, что у вас Kubernetes и он активно развивается.

Компания RedHat для своего OpenShift разработала Compliance Operator на базе решения OpenSCAP. OpenSCAP это: "National Institute of Standards and Technology (NIST) certified scanner designed to perform configuration and vulnerability scans on a system, validate security compliance content, generate reports and guides based on these scans and evaluations, and allows users to automatically remediate systems that have been found in a non-compliant state." При этом оба проекта OpenSource! Для меня это лучшее решение для решения данной задачи, так как:
0) Концепция ComplianceAsCode
1) Реализован в виде operator с хорошо продуманными Custom Resources
2) Может проверять и настройки Kubernetes и самих Node
3) Большая база готовых проверок
4) Возможность писать собственные проверки и оформлять стандарты
5) ComplianceRemediation - возможность автоматически применять правки

При этом есть Workshop и целая Lab’а, объясняющие и обучающие работать с Compliance Operator и OpenSCAP. На основе этих проектов достаточно просто сделать решение удовлетворяющее любым капризам по данной теме и которой при этом уделывает (IMHO) любое коммерческое решение, которое вы ни поправить, ни модифицировать не сможете.

Давненько ничего не слышно было о группировке TeamTNT, которая по данным разных security компаний специализируется на контейнерных/облачных инфраструктурах. Но вот опять еще одна компания выпускает по ним отчет "Taking TeamTNT’s Docker Images Offline".

Ничего особо нового в их инструментарии по сравнению с прошлыми отчетами не появилось, кроме одного момента: "Docker images containing TeamTNT malware are being hosted in public Docker repos via account takeovers. ". То есть они каким-то образом получили доступ к аутентификационным данным разработчиков обычных, легитимных образов. На лицо проблема Software Supply Chain, о которой на канале уже не раз писали. Так что думайте и проверяйте от куда и какие библиотеки, образы, k8s ресурсы, Helm чарты приносит и использует ваша компания.

В выводах понравилась рекомендация: "Understanding your deployed container/Kubernetes attack surface and cloud workloads attack surface is paramount in today’s changing cloud landscape. "

Забавный случай произошел с одним исследователем безопасности, который решил пофаззить AWS API с целью найти там какие-то проблемы и уязвимости. Не знаю нашел ли его фазер какие-то баги, но активировать дорогущий сервис он смог ;)
Будьте аккуратней при исследовании облачных платформ =)

Хорошее описание эксплуатации уязвимости ядра в подсистеме eBPF под номером CVE-2021-31440. Из примечательного тут то, что в качестве демонстрации продемонстрирован container escape в Kubernetes (Ubuntu 20.10, ядро 5.8.0 и mikrok8s 1.20).

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

Ну а все благодаря тому, что по умолчанию можно делать любой системный вызов. Тут либо cами харденим или ждем дефолтного использования seccomp о котором писали раньше. Ну и, конечно, capability нужно тоже резать.

P.S. Сегодня и завтра я на DevOpsConf 2021 с докладом про "SecDevSecOpsSec" - буду рад познакомится и пообщаться со всеми лично AFK!

P.S.S. Как говорят создатели The Pirate Bay: "In Real Life (IRL). We don't like that expression. We say AFK - Away From Keyboard. We think that the internet is for real."

Releases - полезная страница документации Kubernetes, позволяющая всегда быть в курсе и/или быстро освежить в памяти какие версии сейчас последние, сколько они еще будут поддерживаться (End of Life), в каких версиях какие правки, нововведения были сделаны и когда будет следующий релиз и из чего он будет состоять.

Нужная вещь при планировании обновлений и поддержки инфраструктуры.

Недавно запустили новую версию сервиса поиска Сensys Search, который вроде как специализируется/позиционируется как Continuous Internet Discovery ваших/чужих внешних, cloud ассетов. Как по мне из аналогичных сервисов мы можете знать: Shodan, PunkSPIDER, IVRE, ZoomEye. Про массовые поиски в интернете я писал тут и тут.

В общем, народ уже начал его тестировать, ища упоминание "Kubernetes" в SAN (Subject Alternate Name) в SSL сертификата. Для это используют запрос:

services.tls.certificates.leaf_data.names="kubernetes"

По итогу, в результате более 737тыщ совпадений, из которых 2,814 результатов из России. Естественно, там есть ошибки и 1 и 2 рода, но информация занимательная. Можете поискать себя ;)

P.S. Хождение по данным результатам уже на свой страх и риск, что-то может быть honeypot и т.д.

Некоторое время назад я уже рассказывал об инструменте CDK, который представляет собой набор сетевых тулов, PoC'ов и эксплоитов для побега из контейнеров и захвата Kubernetes кластера.

Так вот теперь публично стали доступны слайды с презентации данного инструмента под названием "Attack Cloud Native Kubernetes" с конференции HackInTheBox 2021 Amsterdam. И я снимаю шляпу перед авторами данных слайдов - она практически полностью состоит из отлично проработанных поэтапных, систематизированных схем атак на Kubernetes кластер. Схемы очень детальные и понятные. Их изучение будет полезно не только для Red Team команда, но и для команд, занимающихся обеспечением безопасности.

Сложно выделить что-то одно оттуда - так что материал просто MUST READ для всех!

При обсуждении темы security supply chain чаще всего рассматривается только одна сторона, представляющая собой в том или ином виде код, есть и еще одна очень немаловажная. Это подрядчик/и. Уже известно не мало историй, когда внутрь компаний проникали не напрямую, а через подрядчиков, сервисные компании или просто у них забирали нужную информацию т.д. Часто такие компании с виду не представляют большого интереса и дела с вопросами безопасности там обстоят не хорошо. В итоге, проще атаковать их для достижения цели, чем, конечную, компанию.

Поэтому могу рекомендовать следующее:
1) Заранее узнавать, как обстоят дела с вопросами безопасности у подрядчика.
2) Договариваться, что в случае инцидента у него он об этом не умолчит.
3) Контролировать, чтобы вашу инфраструктуру покидали правильно и чисто.

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

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

Из нового добавили следующие сценарии и знакомства с инструментами:
- Hidden in layers
- RBAC Least Privileges Misconfiguration
- KubeAudit - Audit Kubernetes Clusters
- Sysdig Falco - Runtime Security Monitoring & Detection
- Popeye - A Kubernetes Cluster Sanitizer
- Secure network boundaries using NSP

По этой же теме я недавно нашел проект Kube-Goat, который, к сожалению, 2 года не обновляется, но может кому-то он приглянется. А так это два хороших проекта для обучающих целей)

Ресурс ResourceQuota уже не раз упоминался в контексте ИБ у нас на канале. Сегодня хочется поделиться еще одним прикольным трюком с ним в контексте ограничения сетевого доступа. Неожиданно правда?)

Если внимательно почитать о данном объекте в документации, то станет известно, что можно ограничивать количество ресурсов разных типов в определенном namespace, в том числе и базовых связанных с сетью:
- services
- services.loadbalancers
- services.nodeports

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

Если у вас используются еще какие-то другие Custom Resource связанные с сетью, то и их можно также описать в ResourceQuota ;)

24 июня в Москве offline пройдет конференция Kuber Conf от Yandex.Cloud - как не сложно догадаться про Kubernetes ;)

И мне посчастливилось быть одним из докладчиков на этой конференции. Там я выступлю с докладом "Kubernetes: Observability важная часть Security". Основными тезисами которого я выделил следующие моменты:
- Неразрывная связь security и reliability
- Observability это не только логи, метрики и трейсы
- "Complexity is the worst enemy of security, and our systems are getting more complex all the time.", Bruce Schneier
- `"Scientia potentia est"
- Observability для Continuous inventory и Continuous security profiling

В общем, хочется поделиться своим взглядом на такой buzzword как observability =)

Регистрация на мероприятие уже открыта!

В первой части этой заметки, мы поговорим о необходимости обеспечения безопасности образов контейнеров, которые хранятся в реестрах Amazon Elastic Container Registry (ECR). Для управления доступом и контроля над тем, кто или что (например, какие инстансы EC2) имеет доступ к образам контейнеров, Amazon ECR использует сервис IAM, который позволяет установить политики доступа для пользователей в рамках одного аккаунта или открыть доступ к образам в частном репозитории для другого аккаунта AWS. К тому же, в ноябре прошлого года AWS анонсировали ECR Public, публичную версию реестра образов контейнеров , которые можно загрузить, даже не имея аккаунта AWS.

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

Поэтому, очень важно перед запуском таких контейнеров проводить самостоятельный аудит содержимого образов, наряду со стандартным сканированием на уязвимости. А для мэйнтейнеров популярных образов необходимо обеспечить непрерывный мониторинг изменений, с помощью CloudTrail и GuardDuty и других интегрированных инструментов обеспечения безопасности AWS. Завтра, мы продолжим обсуждение этой темы и рассмотрим инструменты позволяющие автоматизировать подобную атаку, в рамках проведения тестирований на проникновение.

Как по ресурсу Namespace определить с хорошей вероятностью что в данном кластере не используют NetworkPolicy, ну или по крайней мере микросервисы в данном namespace никак не ограничены NetworkPolicy (исключение OpenShift с его концепцией project)???

Если вспомнить как NetworkPolicy определяется и что для это использует namespaceSelector, который завязан на labels от namespace, то правильный ответ: отсутствие labels в описании.

Сейчас при создании данного ресурса они по умолчанию никак не назначаются ... Но с версии 1.21 появилась [beta] фича automatic labelling! Но если у вас еще не такая версия, то можно воспользоваться Mutating возможностями от policy engines при создании новых 'namespace'. А для тех, что уже существуют пройтись с помощью команды:

for ns in $(kubectl get namespace -A -ojsonpath='{.items[*].metadata.name}'); do kubectl label namespace $ns label.name/namespace=$ns; done

P.S. Учтите, что от этого сами NetworkPolicy автоматически не появятся ;)

В продолжении темы про возможность supply chain атак на реестр образов контейнеров AWS ECR, рассмотрим утилиту Cloud Container Attack Tool (CCAT). С помощью этого инструмента, можно автоматизировать создание и загрузку вредоносного образа контейнера в репозитории AWS ECR, во время проведения тестирований на проникновение в облачной инфраструктуре AWS.

Предположим, что злоумышленнику удалось каким-либо образом получить учетные данные аккаунта мэйнтейнера репозитория популярных и часто загружаемых образов контейнеров в ECR. CCAT позволяет выгрузить все образы, на лету создать на основе интересующего образа новый Dockerfile содержащий, например reverse shell отрабатывающий по cron'у. Далее собрать вредоносный контейнер и загрузить обратно в AWS ECR и уже ловить шеллы от других пользователей, которые будут им пользоваться в дальнейшем. Подобная простая в реализации атака на единственный аккаунт AWS может потенциально привести к печальным последствиям для большого количества пользователей, использующих забекдоренный контейнер.

Осознавая риски и последствия подобных атак в начале 2021 года более 200 крупных технологических компаний присоединились к программе Docker Verified Publisher, которая призвана обеспечить безопасность и регулярный аудит образов контейнеров популярного ПО. Но это вовсе не значит что образ помеченный, как Verified по умолчанию безопасен и не нуждается в самостоятельном аудите содержимого.

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

Решение: У kubectl есть замечательный параметр -v, отвечающий за verbosity вывода. Так вот если его использовать в значении --v=8, то будет отображено все содержимое HTTP запроса`. На пример:

kubectl get services -A -l environment=production -ojson -v=8

Далее уже можно этот запрос добавить, как себе в код так в любимый инструмент типа Burp ;) На просторах интернета можно еще найти много других полезных трюков с этим параметром.

30 июня в Санкт-Петербурге offline пройдет юбилейная 10-я конференция по информационной безопасности ZeroNights.

На ней я в рамках секции Defensive Track представлю доклад "Container escapes: Kubernetes edition" - поговорим о том, как и что могут атакующие и что можно сделать, чтобы усложнить побег из Pod’а.

Также в рамках данной секции для аудитории данного канала точно будет интересен доклад "Attacking the microservice applications: methods and practical tips".

Приходите буду рад познакомится и пообщаться в живую =)

На канале уже не раз писали о важности правильно выдавать/контролировать своим workload'ам Capabilities (особенно про CAP_NET_RAW [1,2,3,4]). Напомним, что, Capabilities является частью securityContext и здесь ими можно управлять.

И вот вышла замечательная статья “Linux Privilege Escalation – Exploiting Capabilities”, в которой есть:
- полный список Capabilities с их описанием
- список опасных
- как определить имеющиеся
- пример поднятия привилегий

И еще упоминается полезные проекты LinPEAS, GTFOBins и статья с HackTricks по этой теме. К этому, я могу добавить еще старый, но хороший документ "Exploiting capabilities: Parcel root power, the dark side of capabilities".

Также рекомендую вспомнить наш пост про GKE Autopilot и как он работает с Capabilities.

Как сделать аутентификацию в приложении в GKE?

В обычном варианте обычно это происходит так — средствами ingress controller добавляется аутентификация через Basic Auth/OAuth.
Недостатки данного метода:
- в случае с Basic Auth, где-то надо хранить хеши паролей и уметь их обновлять
- в случае с OAuth, надо полагаться на внешний OAuth provider, либо держать свой (самые популярные Dex, Keycloak, ORY Hydra)

Google позволяет нам забыть про всё это и использовать уже известный нам IAM.
Identity-Aware-Proxy (IAP) — инструмент реализующий централизованную авторизацию для приложений в GCP.

Принцип работы прост:
- Google Sign-In аутентифицирует клиента (живого человека или ServiceAccount)
- IAM проверяет доступ и проводит aвторизацию клиента
- если проверка прошла, запрос проксируется на backend c JWT токеном, подписанным IAP'ом

Нюанс №1 — необходимо проверять заголовки от IAP.
Если вы используете GKE, то за вас это сделает Ingress Controller, необходимо лишь создать нужные ресурсы в Kubernetes. Если нет, то заголовки придется проверять самому.

В качестве backend IAP поддерживает Compute, GKE, Cloud Run, App Engine, и даже on-premises через Interconnect.
Также, IAP поддерживает Google Workspaces, что позволяет организовать доступ сотрудников к ресурсам компании.

Велика вероятность, что вы уже используете IAM, тогда IAP — еще один удобный сервис, который обеспечивает безопасность ваших приложений.

Про второй неочевидный нюанс в следующем посте.

Классная заметка/инструкция "How to protect your ~/.kube/ configuration".

По итогу, с помощью encfs - вы сможете шифровать данную директорию, делать ее доступной только на определенное время и только по паролю.

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

Недавно я стал гостем замечательно подкаста по информационной безопасности под названием "Мимокрокодил". Выпуск называется "Qu3b3c: Немного про K8s и Cloud Native" и там мы поговорили о Kubernetes, DevSecOps, Shift Left Security, Observability и многом другом что связано с Cloud Native.

Подкаст можно послушать на:
Яндекс.Музыка
Apple.Podcasts
Google Podcast
Anchor
Castbox
Spotify (за пределами РФ)

P.S. Рекомендую послушать и другие выпуски - там в гостях уже побывало много моих хороших друзей и знакомых!

Замечательный документ "Cloud Incident Response Framework" от Cloud Security Alliance про реагирование на инциденты в облачных окружениях.

Авторы все разбили на четыре фазы:
1) Preparation
2) Detection and Analysis
3) Containment, Eradication and Recovery
4) Postmortem

Если вы уже живете в облаках есть ли у вас это в ваших процессах?)

Отдельно выделю еще Incident Evaluation Metrics, где описываются, рассматриваемые нами ранее:
- Mean time to detect (MTTD)
- Mean time to acknowledge (MTTA)
- Mean time to recovery (MTTR)
- Mean time to containment (MTTC)

И мое любимое: "A lack of visibility in the cloud means that incidents that could have been remediated quickly are not addressed immediately and are at risk of further escalation."