Возвращаясь к теме Dependency Confusion, хочется упомянуть несколько простых скриптов, которые могут помочь в обнаружении проблемных артефактов: confused и repo-diff.

Первая утилита анализирует файл с определением зависимостей и проверяет, заняты ли имена приватных пакетов в публичных репозиториях. Работает для Python (pypi), JavaScript (npm) и PHP (composer). Подойдет для сканирования небольшого количества проектов.

Если репозиториев больше нескольких десятков, то гораздо проще взаимодействовать с хранилищем артефактов. Неплохим примером, иллюстрирующим работу с API Nexus, служит repo-diff. Он проверяет, нет ли в проксируемых репозиториях Nexus пакетов с такими же именами, что и в приватных. На его основе можно написать кастомный скрипт. Например, чтобы вытащить все приватные зависимости. Такую задачу можно решить также с помощью кастомных groovy скриптов.

P.S. В предыдущем посте никак не затрагивался PHP с его composer. Хотя про эту парочку есть хорошая статья. Исправляюсь.

От @Khorcus

#attack #sca #dev

Keep it secret. Keep it ... safe?

"It look just 6 minutes for the malicious actor to find the leaked credentials on GitHub and compromise our AWS account."

Любопытный эксперимент. Команда вендора Shhgit умышленно разместила ключи AWS в публичном репо GitHub. Первое, что происходит спустя 4 минуты - срабатывание политики AWSCompromisedKeyQuarantine, согласно которой скомпрометированные ключи отзываются с автоматическим уведомлением администратора.

Что же будет, если эту политику выключить?

Спустя 6 минут после утечки происходит волна активности с IP-адресов в Нидерландах. Эти же IP-адреса связаны со спамом и узлами TOR. Почти сразу создаются экземпляры EC2. Очевидно, что это майнинг криптовалюты, а именно XMR (Monero).

Спустя 36 минут IP-адреса из Израиля используют секреты для доступа к S3. В это же время злоумышленник связывается с администратором требуя выкуп.

Итого 13 разных обращений к AWS в течение 24 часов и 4 злоумышленника выполнили действия, аналогичные описанным выше.

#secret

Achieving Cloud Native Security and Compliance with Teleport

До этого я немного касался нового решения HashiCorp Boundary для контроля привилегированного доступа администраторов взамен старым легаси решениям. Сегодня на очереди статья про его аналог - Teleport.

В статье вы узнаете об архитектуре решения, его преимуществах по сравнению с классическими бастион хостами и порядке инсталляции. В Teleport также есть интеграция с Kubernetes, запись сессии, выбор ресурсов через веб-интерфейс. В платную подписку входит SSO, RBAC, возможность запрашивать доступ через Jira, Slack. RBAC кстати также интегрирован с RBAC Kubernetes. То есть вы можете настраивать более жесткие политики контроля, если пользователь, скажем, входит в system:masters.

#ops

Help Shape ATT&CK for Containers

Каждый, кто когда-нибудь подходил к оценке рисков, связанных с Kubernetes, сталкивался со статьей от Microsoft "Threat matrix for Kubernetes". Она построена на базе ATT&CK матрицы, созданной организацией MITRE, которая до этого не подходила к безопасности контейнеров.

Вышла драфтовая версия MITRE ATT&CK матрицы для безопасности контейнеров. Она включает как риски обозначенные Microsoft, так и новые, например, выход за пределы контейнера, сборка образа злоумышленника на хосте, получение доступа к API и так далее.

#ops #k8s #attack

OWASP API Security Top 2019 на русском

Подписчик Eugene Rojavski скинул результат собственного перевода OWASP API Security Top 2019, выполненного совместно с его командой (act1on3, keni0k). Перевод уже стал частью официального репо OWASP.

"Несмотря на то, что более обширный Web Application Security Risks Top 10 по прежнему актуален, ввиду специфики API, необходим отдельный список рисков безопасности специфичных для API. Безопасность API фокусируется на стратегиях и решениях, направленных на понимание и предотвращение уникальных уязвимостей и рисков безопасности, связанных с использованием API."

#dev #web #attack

Shifting Engineering Right: What security engineers can learn from DevSecOps

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

Некоторые тезисы о том, как могут участвовать инженеры безопасности в разработке:
- Быть в курсе дорожной карты компании и продуктов
- Узнавать, может ли инженер безопасности повлиять на фичи продукта, направленные на повышение безопасности (2FA)
- Вносить самому PR
- Развивать навыки разработки и научиться погружаться в то, как собственные фичи влияют на впечатления конечного клиента
- Участвовать в мероприятиях разработчиков

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

#dev

"Враг не пройдёт, или как помочь командам соблюдать стандарты разработки"

Разбор доклада от Александра Токарева про Open Policy Agent на русском языке - что это, примеры проверок манифестов k8s и конфигурации сборок, способы интеграции OPA, use cases и немного про архитектуру OPA в Сбере.

https://habr.com/ru/company/oleg-bunin/blog/328262/

Для тех, кто заинтересовался инструментом, гораздо больше за хэштегом #opa

Сейчас, кстати, стало популярно относить все security практики к каким-то вехам DevSecOps. Open Policy Agent не исключение, поэтому часто можно услышать, что технология относится к Compliance as Code. Сюда же относится Chef InSpec, HashiCorp Santinel и, по сути, любой другой сканер. Подробнее про другие инструменты можно найти по ссылке.

#ops #dev

Kubestriker - Security Auditing tool for Kubernetes

Kubestriker - инструмент для тестирования безопасности Kubernetes. В отличие от большинства инструментов тестирования работает с read-only правами и поддерживает сканирования с anonymous доступом. Проверяет открытые порты, мисконфигурации контейнеров, IAM, PSP, Network Policies, возможность для повышения привилегий. Также поддерживаются все основные виды managed k8s.

#k8s #ops #attack

Attacking Kubernetes Clusters Through Your Network Plumbing: Part 1

CyberArk выпустили достаточно подробную статью о реализациях атак в кластере Kubernetes используя специфику работы сети. В частности речь пойдет о подмене DNS и обходе сетевых ограничений внутри кластера (удаление NET_RAW из пода, правила iptables), используя оверлейные сети. Вот, кстати, пример PoC для спуфинга DNS.

#k8s #ops #attack

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

Со своей стороны дополнил бы паком semgrep, куда входит небольшое число проверок на nginx (расширить рулы довольно просто). Semgrep также поможет переварить конфиги, которые, например, находятся в ConfigMap в случае, если вы столкнулись с таким при аудитах.

Вот оригиналы статей:
- Common Nginx misconfigurations that leave your web server open to attack
- Middleware, middleware everywhere - and lots of misconfigurations to fix

#dev #ops

Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым
https://habr.com/ru/company/cloud4y/blog/547164/

У Яндекса есть анализатор конфигов Nginx
Nginx configuration static analyzer
https://github.com/yandex/gixy

Detecting MITRE ATT&CK by Sysdig Falco

Время от времени получаю различные запросы на проведение аудита Kubernetes и DevSecOps процессов. В рамках одного из них столкнулся с тем, что заказчик использует Falco совместно со встроенными правилами. Основными здесь являются falco_rules.yaml и k8s_audit_rules.yaml. На первый взгляд все очень красиво. Отдельным тэгом выделена классификация правил по MITRE ATT&CK. Каждое правило проставлено тэгом, который говорит о принадлежности правила к тому или иному этапу развития атаки.

На этот счет в 2019 году Sysdig выпустили даже отдельную статью "MITRE ATT&CK framework for container runtime security with Falco", а в 2021 году вышло две статьи о том, как Falco может определить реализацию атак на практике:
- MITRE ATT&CK framework for container runtime security with Falco.
- Detecting MITRE ATT&CK: Defense evasion techniques with Falco

Можно ли применить сразу данные правила и почему подобного пака нет в OPA? Все дело в том, что встроенный пак от Falco никак не учитывает специфику вашей организации и используемые инструменты. Если мы посмотрим на правило "Write below etc", то увидим более 30 различных исключений, которые потенциально могут использоваться злоумышленником. По этой причине весь встроенный пак нуждается в серьезной кастомизации, чтобы не повторить кейса, похожего на Falco Bypass. Даже если вы не готовы выделять деньги на коммерческие решения с встроенным механизмом профилирования, всегда придерживайтесь концепции Least Privilege и Zero Trust.

#ops #attack

Безопасность Kubernetes, Яндекс Облако

Сегодня я хочу поделиться небольшим набором вебинаров от команды Яндекс.Облако на тему безопасности Kubernetes.

- Безопасность в инфраструктуре, основанной на Kubernetes
- Настройки ролевых моделей и политик для Managed Service for Kubernetes
- Практический вебинар по сетевой безопасности

Также у них можно найти репо с тестовым стендом. Весь стенд предполагается развертывать в облаке Яндекса. Здесь есть и примеры "плохих" подов и примеры политик Kyverno.

#ops #k8s

Awesome Kubernetes (K8s) Security

Свеженький Awesome по безопасности Kubernetes. Безусловно, есть чем дополнить, но на текущий момент это самая широкая сборка по данной теме. Отдельным открытием для меня стали материалы из раздела Trainings. Здесь и KubeCon NA 2019 CTF со сценариями атаки и защиты, и бесплатные тренинги от ControlPlane.

Отдельно хотелось бы добавить ссылку на ресурс CloudSecDocs по инструментам для проведения аудита Kubernetes.

#ops #k8s

Introducing sigstore: Easy Code Signing & Verification for Supply Chain Integrity

Сегодня у нас новый проект от Linux Foundation - Sigstore, основная цель которого предоставить возможность подписывать и проверять релизы. Из слов разработчиков, "Так же, как Let's Encrypt предоставляет бесплатные сертификаты и инструменты автоматизации для HTTPS, sigstore предоставляет бесплатные сертификаты и инструменты для автоматизации и проверки подписей исходного кода."

На текущий момент проект нацелен на артефакты вроде tar, бинарных файлов и образов контейнеров. Позже будут рассмотрены jar-файлы, манифесты (например, SBOM).

Важно отметить, что речь идет именно о проекте. Реализация зависит от конкретного инструмента. На текущий момент это Cosign от инженера Google (пример работы), Rekore и Fulcio.

Среди примеров угроз, от которых потенциально спасает инструмент - dependency confusion attack и импорт уязвимых пакетов RubyGems.

#sca

Kics - Secure IaC by Checkmarx (with OPA engine)

Checkmarx выпустили open-source инструмент Kics - сканер IaC (Terraform, Kubernetes, Dockerfile, Ansible, CloudFormation, Helm) на предмет мисконфигураций. Работает на базе правил Rego и умеет выдавать результат в JSON и красивых HTML. Правила все находятся в репо и дописываются, пока я пишу текст к этому посту. В общем выглядит очень интересно.

Если кто хочет послушать про это вебинар 15 апреля от самих Checkmarx, то ссылка вот. Спасибо подписчикам!

Если вам интересны еще подобные проекты, то оказывается, существует отдельный Awesome под OPA - интеграции, статьи, тренинги, коммерческие обвязки.

#opa #dev #ops

Статья "PodSecurityPolicy Deprecation: Past, Present, and Future".

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

Краткая выжимка:
- PodSecurityPolicy (PSP) перейдет в статус deprecated в версии 1.21
- Alpha релиз замены должен состояться в версии 1.22
-Старая версия будет удалена скорее всего в версии 1.25
- Разрабатывается замена для покрытия ключевых потребностей
- Изменения связанные с PSP никаким образом не повлияют на PodSecurityContext
- Основная причина отказа от текущей реализации – не удобство в использовании
- K-Rail, Kyverno и OPA/Gatekeeper это хорошо, но надо иметь простую, гибкую и встроенную реализацию
- За разработкой замены можно следить в Kubernetes Enhancement Proposal (KEP 2579)

Kubernetes Pentest: Methodology, Kubesploit and other resources.

Сегодня на очереди небольшая подборка статей и инструментов на тему пентеста Kuberentes для offensive-команд.

Серия статей от CyberARK о методологии тестирования Kubernetes от 2019 года:
- Kubernetes Pentest Methodology Part 1
- Kubernetes Pentest Methodology Part 2
- Kubernetes Pentest Methodology Part 3

А еще не так давно команда CyberARK выпустила инструмент Kubesploit для тестирования на проникновение среды Kubernetes. Поддерживает следующие возможности для тестирования:
- Выход за пределы контейнера с помощью маунтинга, docker.sock, эксплоита CVE-2019-5736;
- Поиск известных CVE кластера Kubernetes;
- Сканирование портов, относящихся к сервисам Kubernetes;
- Сканирование контейнеров на предмет RCE и доступных токенов сервис-аккаунтов за счет встроенного легковесного инструмента kubeletctl.

От этой же команды есть также инструмент KubiScan для аудита небезопасных ролей. В продолжении к этой же теме вот небольшая подборка инструментов, которая, правда, включает далеко не все (в частности здесь нет CDK). Больше про атаки можно найти по хэштегу #attack.

Для тех, кто пропустил, в конце марта Microsoft обновила свою Threat Matrix for Kubernetes. Обязательно советую к ознакомлению.

#ops #k8s

Security Chaos Engineering, Gaining Confidence in Resilience and Safety at Speed and Scale

Давно ждал эту книгу от Verica и рад, что она есть в открытом доступе. В книге описано подробно про Chaos Engineering в разрезе безопасности с примерами тестов. Прошлый пост с другими материалами по данной теме можно почитать здесь.

#ops #literature