Продолжу сегодня поднятую мною вчера тему про подход к процессу обновления ПО. Спасибо всем, кто высказался в комментариях!

Предварительно хотелось отметить несколько моментов:
1) У моего знакомого NDA и то, что они используют в компании, полностью рассказать не может
2) У них в компании очень высокий уровень зрелости в вопросах безопасности (Blue/Red/Purple team, обучение сотрудников и т.д.) - комплексный подход

Так что далее будет мое понимание и догадки на основе общения с ним по данному вопросу:
1) 0day это обыденная вещь в их модели угроз и рисков
2) Не делают отличий между 0day и 1day уязвимостями - то и то приносит одинаковый ущерб бизнесу
3) Используют deception подход - для поимки атакующего на какой-либо из стадии kill chain (достаточно 1 ошибки злоумышленника)
4) Смотрят за аномальными событиями в инфраструктуре - взаимодействие с SRE командой, ретроспективный анализ и т.д.
5) Threat hunting - делают постоянно и с появлением информации о патчах, PoC обогащают контекст и за чем-то могут посмотреть внимательнее

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

CVE-2021-30465: runc are vulnerable to a symlink exchange attack

CVSS Score: 7.6 High
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

В описании уязвимости (как по мне) вы увидите более запутанное название "mount destinations can be swapped via symlink-exchange to cause mounts outside the rootfs", за которым скрывается time-of-check-to-time-of-use (TOCTTOU) проблема и специфика работы с symlink.

При успешной эксплуатации уязвимости атакующий получит container escape. При этом если даже на системе используются LSMs (AppArmor/SELinux) и user namespaces, то они никак не остановят эксплотацию, а лишь помогут минимизировать возможный ущерб.

В первую очередь это критично для тех инфраструктур, где недоверенные пользователи могут запускать собственные контейнеры. Так как для успешной эксплотации атакующий должен контролировать конфигурацию volumes и иметь возможность выполнить свой вредоносный код внутри этого контейнера. Как мы знаем Kubernetes дает возможность при описании workload такое сконфигурировать - точки монтирования из хоста в контейнер. И в k8s данную уязвимость уже воспроизвели! При этом внешне данная конфигурация подозрительной не является, сигнатурами/правилами не описать. Это не как прямое монтирование / внутрь контейнера, но эффект тот же ;)

Чисто мое IMHO - некоторые априорные знания о системе и/или немного перебора могут позволить это провернуть и в контейнерах, которые созданы/подготовлены не злоумышленником, но имеют точки монтирования, и где у злоумышленника есть RCE - но это еще нужно проверить...

В runc уязвимость исправили в версии 1.0.0-rc95, а в containerd, который его использует, в версиях 1.4.6 и 1.5.2.

Наблюдая за рынком новых решений для monitoring, observability и security, я заметил, что разные вендоры при описании своего решения для Kubernetes по-разному понимают термин agentless, что в итоге может запутать потенциального пользователя. Мне как разработчику observability решения интересно как это подается и обыгрывается в маркетинговых материала, но сейчас речь не об этом. И так, какие же понимания термина agentless можно встретить на рынке:

1) Наше приложение в виде Deployment получает после подписки какую-то информацию и анализирует ее.
2) Наше приложение в виде DaemonSet просто ставится на ряду с другими приложениями и ...
3) Наше приложение в виде sidecar контейнера без каких-либо изменений встраивается и ...
4) Наше приложение в виде небольшой Go/Python/Java/... библиотеки встраивается и ...

Лично для меня только первый пункт ассоциируется с agentless, но возможно, что абстракции k8s все-таки расширяют это понятие? Как по-вашему?

P.S. Записывая данный пост, я поймал на мысли, что к понятию agentless-решения я также автоматом добавляю такие свойства как zero instrumentation / non-Intrusive - никаким образом не меняет наблюдаемые сущности.

P.S.S. Для более полного понимания рекомендую ознакомится с моим циклом про sensor-based решения по безопасности для Kubernetes.

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

И так в выплатах за RCE уязвимости можно увидеть 2 строчки:
- Remote code execution (RCE) ценой $40000
- RCE in standalone isolated/virtualized single-purpose process (e.g. image conversion) ценой $7500

Разница очень ощутимая - в 5,3 раза меньше!

Как я надеюсь вы уже догадались, во вторую категорию попадают RCE, которые проводит атакующий внутри контейнеров (Pod'ов Kubernetes) в случае корректно настроенных контролей. Все это по той логике, что навесить разных механизмы харденинга, изоляции, мониторинга в среде k8s заметно проще, чем на bare metal. В совокупности с микросервсисной архитектурой и использованием малых доменов доверия это позволяет строить инфраструктуру по принципам близким к идеям Zero Trust.

С очень нехитрой математикой по крайней мере на данном частном примере можно представить себе какой выигрыш для ИБ дает k8s с его NetworkPolicy, seccomp/AppArmor/SeLinux профилями, Admission Controllers (тут вспоминаем про policy engines) и т.д.

Но также хочу отметить, что при слабой конфигурации workload в K8s сделать container escape можно и вообще без уязвимостей - так что внимательно следите за их ресурсами.

P.S.
Почти аналогичный подход можно встретить и в BugBounty Google Chrome, где есть разделение:
- Sandbox escape / Memory corruption in a non-sandboxed process
- Renderer RCE / memory corruption in a sandboxed process

Задумывались вы когда-нибудь о том, как обеспечивать надёжность, безопасность в тысячах Kubernetes кластеров? А в десятках тысяч кластеров? На первый взгляд кажется какой-то фантастикой, ну или уделом может только облачных провайдеров ... Но реалии таковы, что IoT постепенно наступает и их работу нужно соответственно поддерживать с учетом адекватных задержек и т.д. Тут на помощь приходит Edge computing и как не удивительно Kubernetes.

Для меня это новая тема (хотя безопасностью IoT/Smart devices/... я уже занимался) и я с удовольствием ее открыл для себя из серии статей "Kubernetes at the Edge" [1,2] (еще KubeEdge, MicroK8s).

Далее я узнал, что в рамках Kubernetes сообществ есть IoT Edge Working Group, в репозитории которого можно найти документ с интересным названием Edge Security Challenges. В данном документе авторы выделили такие разделы:
- Trusting hardware
- Trusting connected devices
- Operating system
- Network concerns
- Edge microservices

Благодаря организатором конференции DevOpsConf 2021 у меня есть возможность разыграть 1-2 проходки на оба дня.

Долго думаю, что же такого сделать в качестве задания, пришел к следующему варианту. Я не очень люблю, да и разбираюсь в разных мемах/мемасах, но порой так или иначе встречаю очень смешные из области Kubernetes. Поэтому для участия в конкурсе необходимо в комментариях запостить ваш любимый мем про Kubernetes связанный с security или observability (область моих интересов). Это может быть как чужой мем, так и полностью ваших рук дело. Выбирать буду я чисто по своему субъективному вкусу и победителя/ей объявлю уже завтра (26 мая до 12:00 по Мск).

Увидимся на конфе!

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

P.S.S. Еще была идея про запись про самый интересный ИБ/ИТ инцидент на вашем опыте в Kubernetes, но думаю большинство работодателей будут этому не рады =)

Если вы работаете в 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 ;) На просторах интернета можно еще найти много других полезных трюков с этим параметром.