The Power of Kubernetes RBAC

В конце того года я писал про опасность глаголов escalate и list при организации RBAC в Kubernetes. Тем не менее я не написал про bind, который имеет точно такой же эффект как и escalate. То есть, если пользователь или SA обладают правами на bind, то абсолютно неважно, какие глаголы еще выставлены у его роли в RBAC, ведь он может запросто изменить свою роль на cluster-admin. Про эффект bind можно прочитать в отдельной статье. Стоит это учитывать при написании RBAC, либо их аудите.

К теме RBAC хочется также упомянуть статью "The Power of Kubernetes RBAC LIST". Проблему с неявными полномочиями также можно встретить в GKE при выставлении прав container.secrets.list. Тут все еще страшнее, так как данные права есть в популярных IAM ролях Kubernetes Engine Developer и Kubernetes Engine Admin. Это в свою очередь позволяет пользователям получить доступ к секретам и завладеть ролью cluster-admin. Авторы в данном случае советуют руководствоваться правилом "один GKE на один проект" и использовать RBAC вместо IAM, чтобы распределять роли команды в рамках неймспейсов, а не назначать права на весь кластер. А еще в статье упоминается утилита, которая поможет выводить перечень конкретных прав для IAM в GCP.

В заключении хочу упомянуть про глагол impersonate. Он позволяет выдать себя за другого пользователя. На текущий момент я не встречал про то, как можно использовать данные права в рамках атаки на кластер, но на сайте CNCF есть статья, как используется impersonate для отладки RBAC.

#k8s #ops #gcp

Вчера в одном из чатов @ttffdd вбросил методичку по тестированию на проникновения k8s. Документ не новый, но напомнил мне тот, что я кидал по Docker, на основе которого я составлял репо Pentest-in-Docker. Информация хорошо структурирована, есть готовые скрипты и запросы к API, чтобы не тащить с собой kubectl.

Вообще для меня было когда-то приятной новостью увидеть страницу OWASP Kubernetes Security Testing Guide, на которой OWASP заявляли о своем желании выпустить подобную методологию. Однако релиз так и не произошел. Зато у них есть страница Kubernetes Security Cheat Sheet с хорошими реферансами в конце.

#attack #k8s #ops

OWASP Devsecops Maturity Model

Когда речь заходит о модели оценки зрелости (или в принципе некотором наборе лучших практик) почти всегда вспоминают BSIMM и OWASP SAMM, но оказывается у OWASP есть еще одна модель оценки зрелости - OWASP Devsecops Maturity Model (OWASP DSOMM). Более того, DSOMM и SAMM отлично сосуществуют вместе в рамках единого процесса. Это связано с тем, что цель DSOMM - определить конкретные активности для организации процесса безопасной разработки, а SAMM - задать некоторый roadmap без погружения в детали.

- Описание активностей, их статуса, связей с SAMM, ISO270001 и друг другом
- Подробное видео про OWASP DSOMM
- Ссылка на репозиторий с докладами, инструментами для оценки зрелости и ее визуализации

Еще очень много активностей находятся в стадии to-do, но репозиторий регулярно обновляется.

Кстати, если вы ищите другие альтернативные модели оценки зрелости, то предлагаю взглянуть на Secure development and deployment guidance от UK National Cyber Security Center.

#dev #ops

When the Levee Breaks: Protecting Vault Against Advanced Adversaries and Internal Threats

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

В основе работы лежит так называемый "криптобарьер" (Cryptographic Barrier), который включает следующее:
- "Распечатка" ключа (или разделение) с помощью схемы Шамира и сторонних HSM или облачных KMS.
- Использование Go-реализации алгоритма AES-256 GCM
- Платные фичи Seal Wrap для дополнительного уровня шифрования с помощью внешнего криптомодуля и Entropy Augmentation для генерации аппаратных случайных чисел и увеличения энтропии

Кроме криптографии к механизмам защиты Vault относятся:
- Контроль доступа через RBAC, ABAC
- Возможность аудита
- Использование кредов с коротким сроком службы
- Использование подхода Zero Trust, включая TLS и AuthN / AuthZ

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

Кстати, если Vault для вас также далек, то есть замечательная страница, где будут первые шаги, лабы, описание интеграций с тем же k8s.

#vault #ops

“Bad Pods: Kubernetes Pod Privilege Escalation”

Статья о 8 не безопасных конфигураций для Pod и соответствующие способы для повышения привилегий. Предполагается что у атакующего есть или возможность создать Pod с такой конфигурацией или он в него попал тем или иным образом. Рассматриваются такие свойства Pod и их сочетания как: hostNetwork, hostPID, hostIPC, hostPath, privileged (список на самом деле можно и расширить):

#1: Все разрешено
#2: Privileged и hostPid
#3: Только Privileged
#4: Только hostPath
#5: Только hostPid
#6: Только hostNetwork
#7: Только hostIPC
#8: Ничего не разрешено

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

Автор также выложил репозиторий со всеми манифестами, и вы можете повторить все описанное в статье. Материал полезен как пентестерам, так и людям, отвечающим за безопасность в Kubernetes.

Общий посыл не забываем про принцип наименьших привилегий (principal of least privilege).

P.S. Если атакующий попал в такой Pod через RCE, то он не знает о этих свойствах Pod и будет итеративно перебирать эти сценарии, тем самым создавая много аномальной активности внутри ;)

Using Jenkins, Vault, Terraform, Ansible, and Consul to Deliver an End-to-End CI/CD Pipeline

Серия статей и видео, посвященных выстраиванию инфраструктуры эффективного деплоймента, покрывая концепции IaC, CI/CD, управления секретами, динамических секретов, проблемы концепции secret zero, service mesh и так далее.

Тулстек:
- HashiCorp Packer
- HashiCorp Terraform
- HashiCorp Vault
- HashiCorp Consul
- Jenkins
- Ansible
- Microsoft Azure

Да, здесь нет статики, динамики и различных проверок образов, но практика показывает, что те, кто идут в DevSecOps, далеко не всегда люди из DevOps. Чаще всего это специалисты со стороны ИБ, которым еще предстоит разобраться во всем многообразии инструментов.

#ops #dev #vault

Безопасная разработка приложений, DevSecOps, Anti-malware

В один из чатов вбросили анонс онлайн-конференции по DevSecOps от Anti-Malware. Когда-то, помню, писал для них статью по сравнению решений Container Security.

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

Затрагиваемые вопросы на конференции по DevSecOps (помимо основ):
- Каковы требования к персоналу и каких специалистов придется нанять?
- Каковы метрики эффективности внедрения DevSecOps?
- С чего начать процесс внедрения DevSecOps?
- Какими средствами проводить фаззинг-тестирование?
- Когда лучше использовать статический (SAST) или динамический анализы (DAST)?
- Какова российская специфика рынка DevSecOps?

Из интересных гостей PT и BI.Zone.

https://live.anti-malware.ru/devsecops

#talks

Bringing Your A-Game: Availability for Security People

Любопытная статья-рассуждение на тему влияния безопасности на доступность важных для бизнеса сервисов. В статье приводится статистика о простоях в месяц для известных сервисов (Azure AD, AWS S3, Cloudflate и тд) и мысли на счет того, как с этим связана безопасность.

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

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

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

#ops

OpenShift Security Guide

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

Если знаете утилиты и другие гайды для аудита безопасности OpenShift - кидайте в комментарии.

#ops #k8s

Detecting zero days in software supply chain with static and dynamic analysis

Любопытная статья про поиск 0-day уязвимостей в сторонних компонентах. В качестве примера была собрана простая python-библиотека, считывающая переменные среды. Также в теории вредоносный пакет может устанавливать бэкдор, красть ресурсы для майнинга криптовалюты или использовать собранные данные для повышения привилегий. Решение максимально простое. Скачивать весь набор библиотек в пайплайне и применять статический анализ (например, Semgrep) или динамический анализ с помощью трассировщика системных вызовов.

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

Методы, описываемые в статье, применяют более современные практики вроде кастомных правил SAST или eBPF, однако есть и подводные камни. Semgrep не строит data flow, поэтому обойти данный набор проверок довольно просто, а писать правила на CodeQL мало кто потянет. Динамический анализ тоже не панацея. Не факт, что вредонос проявит себя на момент анализа работы компонента. Другой вариант - анализировать приложение, когда оно будет работать в Run-time на проде, блокируя активность на момент обнаружения аномалии, однако здесь все упирается в инструментальный стек, а с этим сейчас далеко не все хорошо в мире open-source и enterpise.

#dev

SAST and SCA correlation (?)

На самом деле идея проверки SAST'ом open-source компонентов наталкивает меня на мысли об инструменте корреляции SCA и SAST (понимание как искать совпадения SAST и DAST уже есть). Здесь правда все упирается в то, чтобы находить функции уязвимой библиотеки в коде приложения. Предлагайте идеи, как вы это видите в чате :)

HashiCorp Boundary

В 2020 году HashiCorp выпустили решение HashiCorp Boundary в open-source. Я долго тянул с тем, чтобы разобраться, что это, пока не наткнулся на статью Gating Access to Kubernetes API & Workloads with HashiCorp Boundary, в которой объясняется, каким образом HashiCorp Boundary обеспечивает безопасный доступ к API k8s и контейнерам. Выглядит довольно интересно. Даже прилагается пример в виде terraform.

HashiCorp Boundary представляет из себя CLI + Gateway, позволяющий администраторам получать доступ к ресурсам компании без прямого доступа к частной сети. Boundary интегрируется с существующими средствами аутентификаци, предлагает свою модель RBAC и подтягивает креды из HashiCorp Vault. Все это сопровождается возможностью аудита.

Первый вопрос, который возникает: Чем это отличается от современных Privileged Access Management (PAM) систем, кроме того, что это open-source?

- Boundary Connect (CLI) уже содержит в себе известные клиенты вроде RDP, SSH, kubectl, postgres, http. Таким образом, нет необходимости подключаться к некому бастиону по RDP/SSH, а оттуда перепрыгивать на целевую систему.

- Boundary не привязывается к IP-адресам целевых ресурсов. Это позволяет работать с объектами, которые динамически меняют свои адреса. Например, можно через boundary connect kube пройти аутентификацию, авторизацию и подключиться к желаемому контейнеру с временными кредами.

- Boundary имеет возможность развертываться через Terraform. Таким образом, можно реализовать привычный доступ в формате PAM не конфликтуя с DevOps-командами.

Вот, кстати, хорошее видео, где на пальцах объясняют как работает решение.

#ops #k8s

Cloud Security Newsletter #1

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

В этот раз я решил оформить это в виде подборки единым постом.

Cloud Controls Matrix (CCM) v4 - вышла новая версия матрицы безопасности облаков. Данный фреймворк объединяет требования ISO, NIST, PCI DSS и других нормативных документов, применяемых к облакам в едином файле.

Publishing Checkov Terraform Quality Checks to Azure DevOps Pipelines. - Встраивание Checkov для проверки Terraform в Azure Pipelines шаг за шагом.

How We Escaped Docker in Azure Functions. История про побег из Docker контейнера за счет уязвимости в Azure Functions.

Redefining Security in 2021. О том, что из себя представляют сервисы безопасности в Alibaba Cloud.

Cloud Security Table Top Exercises. Набор из возможных сценариев атак в AWS, которые стоит взять во внимание при аудитах.

New whitepaper: Designing and deploying a data security strategy with Google Cloud. Новый whitepaper от команды GCP по выстраиванию безопасности данных, покрывающий разделы Identity, Boundary, Access и Visibility.

#aws #gcp #azure #ops #dev

CodeQL: SAST своими руками (и головой). Часть 1

Вводная статья от Паши Канна про CodeQL. Что это такое, как начать с этим работать и чем это может быть полезно. Ссылки в дополнительных материалах помогут разобрать вопрос чуть глубже.

Конечно, здесь ещё много чего нет про построение data flow, подводные камни и сопутствующие страдания, но на то это и первая часть. Кое-что про основы я писал здесь.

Кстати, также Паша запустил чат по обсуждению CodeQL.

https://habr.com/ru/company/swordfish_security/blog/541554/

#sast #dev

Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies

Недавно вышла интересная статья про то, как исследователь получил возможность исполнять код на серверах компаний и внедрять бэкдоры в их приложения. Уязвимыми оказались такие гиганты, как Microsoft, Apple, PayPal и Tesla. Атака стала возможной благодаря особенности пакетных менеджеров, которые пытаются загрузить внутренние зависимости компаний, в том числе и из публичных репозиториев. Это касается и хранилищ артефактов, если в одном виртуальном репозитории смешаны внутренние и внешние пакеты.

Реализовать атаку довольно просто: находим имена приватных пакетов, создаем собственные версии с аналогичным названием, выкладываем в публичный репозиторий. Далее ждем, когда кто-то установит наш пакет вместо приватного пакета компании. На HackerOne есть репорт, который раскрывает всю подноготную атаки, включая "вредоносный" пакет для тестирования.

Защита от подобного рода атак описывается в новеньком документе Microsoft. Для Nexus и JFrog выпущены соответствующие рекомендации. Но какой-то серебряной пули, которая поможет здесь и сейчас, нет. Особенно в случае с npm, когда ваши разработчики не используют scope.

Кстати, ситуация с Dependency Confusion еще один звоночек в пользу создания своей баг-баунти программы. Ведь владельцы оных были уведомлены об уязвимости аж 7 месяцев назад.

Новость и разбор от @Khorcus

#dev #sca #attack #news

OWASP ASVS 4.0 Testing Guide

Неофициальное руководство, в котором описывается, как автоматически тестировать веб по проверкам уровня Level 1 стандарта ASVS с помощью OWASP ZAP. К методике также недавно появилась обзорная статья. В руководстве достаточно подробно написано, как завести ZAP под ASVS с применением пассивного сканирования. Также в репо прилагаются все необходимые скрипты .

https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide

#dast #dev

Launching OSV - Better vulnerability triage for open source

В вопросах, касающихся уязвимостей в сторонних компонентах (цепочке поставок), одна из главных проблем - полнота сведений в базе данных. В частности речь идет о NIST. Информации о CVE, CVSS и CPE чаще всего недостаточно, чтобы точно идентифицировать, какие компоненты подверглись уязвимости в цепочке поставок. Это же проблема является ключевой в вопросах корреляции SAST/SCA. Более того, мы не обладаем информацией о том, в каких версиях происходит исправления уязвимости. Чтобы решить данную проблему, крупные вендоры (например, Sonatype) ведут собственные фиды.

По этой причине команда Google на базе информации, полученной по итогам работы над OSS-Fuzz, запустила проект Open Source Vulnerabilities (OSV). Это сервис, который использует собственные фиды, чтобы предоставить расширенную информацию об уязвимостях в версии ПО. Про подход "Know, Prevent, Fix", взятый за основу, они также писали в отдельной статье.

Как работать с сервисом можно прочитать здесь, а на саму базу можно взглянуть по пути list.

Вот, например, OSV-2020-2291. Здесь содержится информация о том, что за уязвимость, какие компоненты также подвержены, ссылка на репо, коммит, в котором уязвимость была найдена и устранена. Здесь же есть данные о результатах тестирования с помощью OSS-Fuzz.

#dev #sca