Security Wine (бывший - DevSecOps Wine)

Attacking Kubernetes Clusters Through Your Network Plumbing: Part 1

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

#k8s #ops #attack

Kubestriker - Security Auditing tool for Kubernetes

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

#k8s #ops #attack

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

Разбор доклада от Александра Токарева про 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

Shifting Engineering Right: What security engineers can learn from DevSecOps

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

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

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

#dev

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

Help Shape ATT&CK for Containers

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

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

#ops #k8s #attack

Achieving Cloud Native Security and Compliance with Teleport

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

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

#ops

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

Возвращаясь к теме 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

Всем привет!

Была немного тяжелая неделя, накопилось много идей, о чем написать, но это потом.

Сейчас мы тестируем Clubhouse и знакомимся с комьюнити DevSecOps

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

https://www.joinclubhouse.com/room/xn76O70a

#talks

Red Hat and IT Security

Обзорная книга по безопасности в DevOps в связке с продуктами Red Hat от 2021 года.

Из интересного и не заезженного - обзор в связке с безопасностью:
- Red Hat Hyperconverged Infrastructure (HCI)
- Red Hat OpenStack Platform (RHOSP)
- Red Hat Smart Management
- Red Hat Insights.

#literature #ops

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

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

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

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

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

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

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

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

#sast #dev

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

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

SAST and SCA correlation (?)

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

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