Как-то это прошло мимо меня, но 2 месяца назад в Istio закрыли забавную, но при этом классическую уязвимость для подобных механизмов (Подобное можно было видеть и в случаях с saml/oauth.), в проверке JWT токена. Суть: "If a JWT token is presented with an issuer that does not match the issuer field specified in JwtProvider, then the request is mistakenly accepted". Подвержена была версия 1.17, а более младшие версии нет (1.16 и младше). Уязвимость получила идентификатор CVE-2021-21378 и высокий CVSS рейтинг 8.2 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N.

P.S. Не очень понятно почему авторы во всех переписках это публикуют как "fix for zero day"... Может они видели использование данной уязвимости в реальном мире ?!

Сегодня с 10:00 CEST стартует KubeCon + CloudNativeCon Europe 2021 и продлится до 7 мая включительно. Полное расписание можно посмотреть тут.

А завтра будет специальная секция Cloud Native Security Day от CNCF - программу этой секции можно посмотреть тут. Там, как всегда, много всего интересного (будет даже CTF), но этого не значит, что в остальные дни на конференции нет докладов затрагивающий тему безопасности.

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

Совсем недавно компания Google на одной из страниц своей официальной документации опубликовала/обновила раздел "Compare AWS and Azure services to Google Cloud". То есть она сопоставила свои облачные сервисы с сервисами своих основных конкурентов. Это может быть полезно как при выборе облачного провайдера, так и при миграции из одного в другой или при создании Multi-cloud.
Отдельно стоит обратить внимание (применить фильтр) на следующие моменты:
- "No equivalent alternative" - так как таблица строится от сервисов Google, то это свойственно только конкурентам. Так что у конкурентов тоже могут быть сервисы, которым нет альтернативы в Google.
- "Security" - быстро посмотреть, что позиционируется как механизм безопасности
- "Kubernetes" - быстро посмотреть, что на прямую связывают с k8s

До этого я встречал только вот такое сравнение "Mapping of On-Premises Security Controls vs. Major Cloud Providers Services" (не со всеми пунктами я там согласен) для решений ON-PREMISES, AWS, AZURE, GOOGLE, ORACLE, IBM и ALIBABA.

Определенно было бы здорово иметь подобное сопоставление/сравнение и с участием российских облачных провайдеров.

https://doc.crds.dev/ - очень удобный online сервис по работе с CRD (Custom Resource Definition). Он очень прост и полезен в использовании - достаточно вбить только github адрес проекта, CRD которого вас интересуют. А далее проект самостоятельно выделит версии проекта и для каждой из них имеющийся там набор CRD с описанием. По сути, это такая автоматическая генерилка документации на CRD сторонних проектов.

Это очень может быть полезно при знакомстве, разбирательстве с чужим проектом, оператором и т.д. до его непосредственной установки. В одном из своих прошлых постов я уже писал о проблеме, которую они привносят и потенциально могут понизить уровень безопасности и сыграть на руку атакующему. А благодаря данному проекта можно очень просто, удобно и быстро ознакомиться с внутренностями любых CRD на просторах github.

ELF внутри YAML ресурса Pod или x86 assembler внутри ConfigMap ?) Вот такие кейсы [1,2] можно найти на просторах сети... И при этом это также может использовать атакующий, но уже не в ваших интересах.

Вот и прошел KubeCon + CloudNativeCon Europe 2021 - на нем было много интересного и полезного. Мы обязательно отдельно рассмотрим доклады, что затрагивали тему security, а их было прям предостаточно. Но уже сейчас большинство слайдов докладов доступно на сайте, внутри расписания: основная программа и Cloud Native Security Day.

Сегодня речь пойдет об атаке 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