Security Wine (бывший - DevSecOps Wine)
7.14K subscribers
281 photos
1 video
68 files
491 links
https://radcop.online/

"Security everywhere!"

🍷Канал, в котором публикуются материалы о "выращивании" безопасности в организации (а начиналось все с безопасного DevOps и shift security left!)

По всем вопросам: @surmatmg
加入频道
Security Wine (бывший - DevSecOps Wine)
Возвращаясь к теме Dependency Confusion, хочется упомянуть несколько простых скриптов, которые могут помочь в обнаружении проблемных артефактов: confused и repo-diff. Первая утилита анализирует файл с определением зависимостей и проверяет, заняты ли имена…
Still Dependency Confusion. Defending Against Software Supply Chain Attacks

На тему атаки Dependency Confusion продолжают выходить статьи и инструменты.

В частности ребята из Salesforce выпустили инструмент DazedAndConfused для проверки Cocoapods, composer, gems, gradle и не только.

Вышла даже статья по реализации атаки в Game Development на Unity (потому что NPM). На тему устранения уязвимости в NPM вот. Если вы используете Bundler для работы с зависимостями в Ruby, то для вас также есть статья.

На тему Supply Chain последнее время пишут достаточно часто. В частности CISA выпустила методичку "Defending Against Software Supply Chain Attacks" по защите от атак на цепочку поставок. В ней есть упоминание множества полезных практик NIST - NIST SP 800-161 (April 2015), NISTIR 8276 (February 2021), SSDF (April, 2020)

#dev #sca #attack
Nuclei and DevSecOps

Если вы сидите в чатиках, посвященных пентестам / уязвимостям веба, то наверняка могли слышать про инструмент Nuclei. Nuclei позиционируется как быстрый сканер уязвимостей в вебе, в котором можно определять шаблоны отправки запросов на базе yaml. Похожий подход используется, как мы знаем, современными SAST (Checkmarx, CodeQL, semgrep). Также, как и в CodeQL, предполагается, что эти же заполненные шаблоны могут быть переданы исследователями безопасности в рамках Bug Bounty. В дальнейшем Nuclei вместе со всеми шаблонами встраивается в CI/CD. У инструмента также есть отдельное репо с готовыми шаблонами на разные случаи жизни (от фаззинга до IoT).

Прилагаю также дополнительный полезный материал на тему Nuclei:

- Exploiting Race conditions with Nuclei

- How to Scan Continuously with Nuclei?

- Nuclei - Fuzz all the things

#dev #ops #attack #dast
Jenkins attack framework

Инструмент для тестирования безопасности Jenkins от Accenture - jenkins-attack-framework. Инструмент работет как white box и требует URL сервера и агента, username, password или API-токен. Среди атак попытка просмотра и запуска джоб и скриптов, дамп кредов, загрузка файлов.

Есть также сопровождающая статья:
- Red teaming Jenkins with the Jenkins Attack Framework

#dev #ops #attack
Detecting Malicious Activity in CI/CD Pipeline with Tracee and Codecov story.

Aqua Security показали один из примеров, как можно использовать относительно новый инструмент Tracee. Напоминаю, что Tracee - это утилита, которая помогает собирать информацию об активности приложения, которое развернуто на сервере с Tracee, в режиме runtime на основе технологии eBPF (по аналогии с тем, как работают движки Container Runtime в современных средствах защиты класса CSP).

Так вот Аква предлагает запускать Tracee в CI/CD, анализируя аномальную активность собираемых и разворачиваемых приложений. При этом у Tracee появился встроенный набор сигнатур.

Сам автор поста заявляет, что данный механизм защиты может помочь предотвратить индицент аналогичный тому, что произошел с Codecov в апреле 2021 года, когда злоумышленники подменили скрипт Bash Uploader, используемый в Codecov-actions для Github, Codecov CircleCl Orb и Codecov Bitrise Step. Злоумышленнику удалось воспользоваться ошибкой в используемом Codecov процессе создания образа Docker, позволившей ему извлечь учетные данные, необходимые для внесения изменений в скрипт Bash Uploader (наглядный пример supply chain атаки).

Ненавистники сигнатур занегодуют, но стоит признать, что сам по себе подход имеет право на существование.

Помимо анализа работы ПО, используемого в CI/CD на наличие аномалий, важно не забывать про механизмы защиты самого процесса CI/CD: MFA, хранение секретов, изоляция окружений, сетевая безопасность и многое другое. Этой теме в будущем будут посвящены отдельные посты.

#attack #dev #ops
Terraform Plan “RCE”

Небольшая статья о реализации "Remote Code Execution" (RCE) злоумышленником при работе с terraform plan. Это особенно актуально, если вы проверяет таким образом PR перед merge в прод бранч.

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

В статье есть раздел по митигации риска.

#terraform #attack #dev #ops
Attacking Kubernetes Clusters Through Your Network Plumbing: Part 2

Вторая часть от CyberARK по атакам на сети Kubernetes (первая здесь). В этот раз речь пойдет об изменении маршрутизации (в частности BGP), что приводит к скрытой MiTM-атаке.

#attack #ops #k8s
Hack Series: Is your Ansible Package Configuration Secure?

Хорошая статья, которая раскрывает аспекты безопасности Ansible: несколько простых рекомендаций и разбор уязвимости CVE-2020-14365, которая позволяет реализовать атаку через supply chain.

Основная проблема кроется в том, что ansible старых версий использует dnf-модуль, который позволяет скачивать внешние пакеты без проверки их целостности и организации безопасного соединения через HTTPS. Проблема актуальна и для новых версиях в тех случаях, когда используется force: true.

#ops #attack
Siloscape: First Known Malware Targeting Windows Containers to Compromise Cloud Environments

Разбор от Unit 42 (отдел исследований Palo Alto) вредоносного ПО Siloscape, которое использует Windows контейнеры для выходы за их пределы и эксплуатации мисконфигурации Kubernetes. Все это сопровождается коннектом до внешних C2-серверов через Tor-прокси. Инициализация вредоносного ПО предполагается через RCE веб-сервера.

Кстати, это не первая статья автора, которая посвящена безопасности Windows-контейнеров:
- Windows Server Containers Are Open, and Here's How You Can Break Out
- What I Learned from Reverse Engineering Windows Containers

Важно отметить, что Windows-контейнеры используют те же привилегии, что и хост, из-за чего не должны использоваться в качестве security boundary. Вместо этого рекомендуется использовать Hyper-V containers.

Обсудить можно здесь: @sec_devops_chat

#ops #attack #k8s
AquaSecurity_Cloud_Native_Threat_Report_2021.pdf
7.5 MB
Attacks in the Wild on the Container Supply Chain and Infrastructure

Помните отчет от Aqua, где они установили honeypot'ы для определения атак направленных на контейнерную среду? Они выпустили новый отчет, где атак было зафиксировано больше (рост на 26% за квартал), а результаты не менее интересны. Отчет достаточно хорошо описывает векторы атаки, связанные с MITRE ATT&CK, с приложенными скриншотами используемых скриптов.

#attack #docker #k8s #ops
Изучаем уязвимости в сервисах поставки кода

Увидел тут в Античате вырезку из журнала "Хакер" - "Опасная разработка. Изучаем уязвимости в сервисах поставки кода". Рассматриваются уязвимости и мисконфигурации таких продуктов как Jira, Confluence, Asana, GitLab, TeamCity и нескольких других.

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

#attack
NCC_Group_Google_GOIST2005_Report_2020-08-06_v1.1 .pdf
849.7 KB
Announcing the results of Istio’s first security assessment

Команда Istio выпустила результаты аудита безопасности их продукта версии 1.6.5, который проводился NCC Group в прошлом году. К отчету идет сопутствующая статья, где поясняется, откуда взялись те или иные Security Best Practices.

#ops #attack #report #k8s
Jenkins secrets extraction

Возвращаемся к нашему квизу, который вызвал бурные обсуждения в чате. 59% человек посчитало, что схема является безопасной с точки зрения управления секретами. Как итог они оказались неправы. Дело в том, что упомянутый плагин сredentials-binding может позволить разработчикам извлечь секреты даже если секреты используются во внешнем хранилище Vault. Но дело даже не в плагине, а в самой возможности разработчика влиять на конфигурацию сборки, ведь с тем же успехом можно извлечь секреты напрямую из $JENKINS_HOME/credentials.xml и $JENKINS_HOME/secrets воспользовавшись hudson.util.Secret.decrypt или сторонними инструментами.

Так как разработчик имеет доступ к конфигурации сборки и ее запуску в Jenkins, то помимо извлечения секретов может быть поднят reverse shell или вызван DoS всего сборочного конвейера. Все зависит от сетевых доступов и прав на агенте сборки.

Какой же вывод? Как ни странно, то компенсирующей мерой сделать так, чтобы конфигурация джобы тащилась из внешнего Jenkinsfile, который будет расположен в Git, а разработчик мог эту джобу только запустить. Jenkinsfile на стороне Git-репозитория в свою очередь будет защищен принудительным merge approval и другими мерами, которые могут быть реализованы на стороне SCM.

#dev #ops #talks #attack