Сегодня речь пойдет об атаке Terminal escape injection в сервисе AWS CloudShell, обнаруженной командой Google Project Zero в феврале 2021 года.
Суть уязвимости в возможности RCE, из-за ошибки компонента библиотеки aceterm, приводящей к некорректной обработке последовательности символов xterm rewrite терминала javanoscript, при использовании AWS CloudShell. Это может привести к возможности удаленного выполнения кода на EC2 серверах, доступ к которым осуществлялся с помощью консоли CloudShell.

Сервис AWS CloudShell предоставляет возможность доступа к терминалу сервера любых сервисов на AWS c помощью браузера, прямо из веб интерфейса консоли управления AWS.

Поскольку AWS CloudShell имеет полный доступ к учетным данным, используемым для входа в веб интерфейс консоли управления AWS,
успешная эксплуатация данной уязвимости могла бы дать злоумышленнику очень мощную точку входа в инфраструктуру AWS, включая сервисы managed k8s: EKS, ESC. Уязвимость была опубликована в рамках сроков responsible disclosure и в настоящее время устранена.

PS: Примечательно, что 2 года назад такой же баг, приводящий к RCE (CVE-2019-0542) был найден в аналогичном сервисе Azure Cloud Shell/VSCode.

Сегодня открою "страшную" тайну хорошо известную в "узких" кругах о Falco - он легко обходится и трудно настраивается. Но обо всем по порядку:
1) Если вы используете Falco, то срочно обновитесь до последней версии 0.28.1
2) В данной версии закрыли несколько Security Advisories уровня critical и high
3) Сritical позволяла незаметно уронить модуль и отключить Falco
4) High говорит о множественных обходах default правил из falco_rules.yaml (закрыто не все)
5) Об этом всем известно в открытом доступе уже 17 месяцев
6) Все это доступно вместе с PoC из стороннего публичного аудита безопасности опубликованного в репозитории Falco

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

Запомните: Правила, созданные человеком, хороши ровно на столько на сколько хорошо их автор знает систему в конкретный момент создания правила. А ОС Linux совсем не простая ОС + ваши микросервисы развиваются ...

Во время последнего KubeCon + CloudNativeCon Europe 2021 была опубликована первая версия Cloud Native Glossary. Если вы или ваши коллеги только начинаете свой путь в Cloud Native мир, то это будет хорошей отправной точкой, чтобы получить общее представление о базовых терминах и определениях.

В первой версии 25 терминов (список будет расширяться) в 3-х категориях:
1) technology
2) property
3) concept

При описании каждой technology объясняют, что это такое, зачем это надо и как помогает. От сюда вы узнаете и что такое Kubernetes и что такое DevOps c DevSecOps и многое другое ;)

Компания Amazon опубликовала серию постов "Policy-based countermeasures for Kubernetes" [1,2].
По сути, это свежий (от 31 марта 2021) обзор и сравнение policy engines, который поможет вам выбрать наиболее подходящий для вашей компании. Среди рассматриваемых кандидатов:
- OPA
- Gatekeeper
- MagTape
- Kyverno
- k-rail

К сожалению, на момент публикации Kubewarden еще не был выпущен, и он тут не рассматривается.

Все решения описываются по следующим пунктам:
1) Создание политик
2) Реакция на недоступность webhook (fail open vs. fail closed)
3) Возможность фонового сканирования
4) Расширяемость кода и данных
5) Архитектура и развитие используемых политик
6) Возможность работы вне Kubernetes кластера (встраивание в CI\CD)

Материал просто MUST READ, а policy engine уже должен быть неотъемлемой частью вашего Kubernetes кластера!

Если вы планировали провести эти выходные с пользой, то как раз для вас CNCF выложил записи докладов с недавно прошедших своих сессий:
- KubeCon + CloudNativeCon Europe 2021
- ServiceMeshCon EU 2021
- Kubernetes on Edge Day EU 2021
- Crossplane Community Day EU 2021
- Cloud Native Security Day EU 2021
- Kubernetes AI Day EU 2021
- Cloud Native Wasm Day EU 2021
- FluentCon: Cloud Native Logging Day with Fluent Bit and Fluentd EU 2021
- Cloud Native Rust Day EU 2021
- PromCon Online EU 2021
- Magma Day EU 2021


Обратите внимание, что доклады на тему security были не только на Cloud Native Security Day, но и в основной программе, и в других сессиях ;)

От версии к версии Kubernetes приобретает все новые и новые возможности для повышения уровня безопасности.

Так в версии 1.22 в alpha стадии будет добавлен "KEP-2413: Enable seccomp by default". Данный KEP позволит, через feature gate под именем SeccompDefault для kubelet, запускать все рабочие нагрузки (`workloads`) c seccomp профилем по умолчанию, который будет разрешать только определенный набор системных вызовов. На текущий момент никаких ограничений НЕТ, если вы, конечно, не создали и назначили seccomp профиль вручную. По сути, это сузит для атакующих перечень системных вызовов через, которые они могли бы сделать побег из контейнера через уязвимости ядра хостовой ОС.

Насколько я понял из черновой документации прям финального профиля пока нет и вообще он будет скорее всего отличаться от container runtime к container runtime. Но судя по этой же странице в профиле будет всего порядка 50 разрешенных системных вызова.

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

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

И он подсветил для меня один очень интересный момент, о котором лично я никогда не задумывался, не рассматривал и сейчас хотел бы поделится им с вами. Общий смысл его посыла был примерно следующий: "Мало обновить весь софт до актуальных версий, также необходимо убедиться, что закрытые уязвимости не были проэксплотированы до их закрытия". И все очень логично, если подумать - патчи нас защищают от будущих атак на эти 1-day уязвимости, но совершенно ничего не говорят о прошлом этих уязвимостей в нашей инфраструктуре, когда они для нас, по сути, были 0-day. То есть инцидент уже был, но мы о нем просто не знаем ...

Никто не застрахован от того, что кто-то раньше разработчика нашел эту уязвимость и использует ее в злонамеренных целях, никто не может мгновенно обновить весь код в продуктивном окружение - всегда есть окно между выходом патча (информация становится известна широкой публике) и непосредственным обновлением и все это время вы под большой угрозой. А с учетом того, что сейчас в разработке используется огромное количество open source кода из публичных репозитариев, то плохим парням достаточно внимательно следить за тикетами, фиксами в этих проектах. На моей памяти так уже делают, на пример, следя за изменениями в кодовой базе Chromium.

Для тех кто хочет поглубже разобраться в теме, посмотреть на нее с разных сторон советую ознакомится с документом "ENCOURAGING VULNERABILITY TREATMENT: Responsible management, handling and disclosure of vulnerabilities".

И напоследок вопрос: многие ли из нас помимо обновления ПО, убеждаются в том, что инцидента до этого не было?)

Поговорим о kube2iam - инструменте для настройки конфигурации IAM roles кластера k8s, запущенного в облачной инфраструктуре AWS. Часто бывает, что внутри кластера разрешено взаимодействие через IMDSv1 (о котором мы уже писали). Относительно k8s конфигурация доступа контейнеров/pod's напрямую к сервисам IMDS приведет угрозам безопасности, в случае успешной компрометации одного из контейнеров злоумышленник может обратиться к IMDS для получения значений temporary credentials для дальнейшего продвижения.
kube2iam предлагает решение для проксирования трафика IMDS всех контейнеров/pod's в составе k8s на основе arn, при настройке IAM roles кластера на AWS, которое может быть запущенно как kube2iam daemonset на каждой ноде кластера.
За проксирование API IMDS отвечает iptables --to-destination curl 169.254.169.254/latest/meta-data/local-ipv4:8181
Внимательный читатель может заметить ряд пересечений по функциональности с GKE Workload identity, только это утилита с открытым исходным кодом.

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

Предварительно хотелось отметить несколько моментов:
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 для всех!