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

Vulncov - A tool that correlates Semgrep scans with Python test code coverage

Небольшой тул-эксперимент недельной давности — VulnCov. Его цель — приоритизировать файндинги Semgrep, исключая уязвимости, найденные в "мертвом коде". Для этого тул берет файндинги из Semgrep и объединяет их с результатами работы юнит-тестов Pytest.

Чтобы лучше разобраться, проще всего рассмотреть демонстрационный пример, где есть несколько уязвимостей внутри недостижимого участка кода:
- Закомментированный роутер #@app.route
- Невыполнимое условие if 1 == 2

По результатам сканирования Semgrep, по очевидным причинам, выдаст все уязвимости, включая те, что находятся в недостижимом коде. В проекте также есть тесты, которые по итогам выполнения формируют файл coverage.json. Файл coverage из отчета юнит-тестов содержит информацию о том, какие строки кода были выполнены в процессе тестирования, а также предоставляет сводную статистику о покрытии кода тестами. Этот файл помогает разработчикам понять, какие части кода проверены тестами, а какие — нет, что создает идеальную базу для приоритизации результатов Semgrep. В результате VulnCov сравнивает два файла и выдает JSON с наиболее релевантными файндингами.

А еще проект имеет поддержку приватной LLM ollama (хотя где-то без подключения OpenAI) для генерации баг-фиксов.

В репозитории всего 21 ⭐️, но в домене корреляции результатов, даже в эпоху искусственного интеллекта, вряд ли стоит ожидать величайших прорывов. Сразу вспоминаются решения класса IAST и сопутствующие рассуждения о корреляции SAST и DAST из далекого 2020 года. Как мы можем видеть, гораздо быстрее и эффективнее развиваются практики reachability analysis и автоматического триажа с помощью AI.

#sast #ai

SLSA provenance и кое-что еще

Так как канал исторически носит название "DevSecOps", самое время вспомнить то, что было активно обсуждаемым в 2021 году — SLSA. Недавно мы наткнулись на репозиторий s3cme — тестовое приложение на Go, в котором реализованы следующие лучшие практики:

- Сканирование с помощью Trivy
- Сканирование с помощью CodeQL
- Сборка и публикация образа с использованием ko (включает генерацию SBOM)
- Сканирование уязвимостей образа с использованием trivy с параметром проверки максимальной серьезности
- Подпись образа и аттестация с использованием cosign
- Генерация происхождения (provenance) SLSA с помощью slsa-framework/slsa-github-generator
- Проверка происхождения SLSA с использованием slsa-framework/slsa-verifier и CUE политики через cosign.

Напомним, что такое provenance. Всякий раз, когда образ публикуется в реестр, к этому образу прикрепляется аттестация в виде файла SLSA provenance (v0.2). Это позволяет отследить этот образ вплоть до его исходного кода в репозитории (включая GitHub Actions, которые использовались для его создания). Способность обеспечивать такую проверяемую прослеживаемость называется как раз происхождением (provenance). Делать это наибходимо с той целью, чтобы убедиться, что конечный доставляемый артефакт нигде не изменился по пути прохождения цепочки поставок, включая CI/CD. Отследить это можно либо вручную с помощью cosign, либо сразу в кластере с помощью sigstore admission controller.

Вот ссылка на наш старый пост с описанием фреймворка SLSA с действующими ссылками. Сейчас, спустя три года, можно с уверенностью сказать, что сообщество обогатилось конкретной реализацией некогда абстрактной теории, предложенной Google (к вопросу вечного холивара теоретиков и практиков - по-настоящему хорошо работает только синтез 😊 ).

А вот, например, автор из GitHub рассказывают про фичу GitHub по аттестации артефактов, которая упрощает подписание кода для программного обеспечения, созданного в GitHub Actions, и помогает достичь соответствия уровню 2 SLSA. Provenance включает информацию о происхождении, такую как данные о репозитории, инструкции по сборке и SHA исходного кода, делая процесс "голеньким и прозрачненьким".

А как вы решаете эти задачи, и дошли ли до их решения в своих пайпах?

#slsa #supplychain #devsecops

Enhancing LinkedIn’s security posture management with AI-driven insights

В сегодняшнем нашем посте инженеры LinkedIn рассказывают о собственной Security Posture Platform (SPP) — внутренней системе, которая предоставляет динамическое представление об инфраструктуре компании и упрощает управление уязвимостями. Основная цель SPP заключается в предоставлении актуальной картины безопасности всей цифровой экосистемы компании. Платформа интегрируется с существующими инструментами безопасности и автоматизирует сбор и анализ данных, что позволяет оценивать риски практически в режиме реального времени. Это помогает проактивно управлять безопасностью, сокращая количество ручных операций.

Ключевые особенности SPP:

- Каталогизация активов: SPP собирает данные обо всех цифровых активах компании, включая физические устройства и облачные ресурсы. Это обеспечивает полную видимость инфраструктуры, что упрощает приоритизацию рисков.
- Анализ рисков и автоматизированные решения: Платформа использует метаданные для постоянной оценки рисков. Это позволяет оперативно реагировать на новые угрозы, включая упреждающие меры, такие как изоляция устройств с высоким уровнем риска.
- Централизованное управление рисками: В основе SPP лежит Security Knowledge Graph — граф знаний, который объединяет информацию о взаимосвязях между активами. Это помогает быстрее идентифицировать риски и принимать обоснованные решения. Визуальные панели предоставляют полную информацию о состоянии безопасности пользователей и активов.

Для повышения эффективности в условиях большого числа активов, команда LinkedIn добавила в SPP поддержку AI, позволяя безопасникам обрабатывать данные с помощью промптов.

Немного про AI в платформе:

- Генерация контекста: Исходные данные, такие как метаданные из различных источников, преобразуются в формат, понятный AI-моделям, что повышает эффективность ответов на запросы пользователей.
- Создание запросов: AI анализирует пользовательские запросы и трансформирует их в команды для поиска данных в графе знаний, используя нетривиальные механизмы для оптимизации запросов и повышения точности.
- Маршрутизация запросов: Запросы распределяются по различным источникам данных с минимальной задержкой, что обеспечивает высокую скорость ответов.
- Обобщение данных: AI также выполняет обобщение информации, предоставляя краткие и информативные ответы.

В процессе разработки системы команда LinkedIn столкнулась с рядом технических проблем. Одной из них было ограничение ранних AI-моделей (старая модель Davinci, относящаяся к GPT3) , которые не справлялись с объемами данных в графе знаний. Также возникали сложности с управлением «галлюцинациями» AI, когда система предоставляла неверные ответы. Для решения этих проблем были внедрены сложные системы тестирования и итеративная настройка моделей, что значительно повысило точность ответов.

Результаты работы SPP впечатляют: время реагирования на уязвимости сократилось на 150%, а охват цифровой инфраструктуры увеличился на 155%.

Красивая success-story без единого скриншота и ссылок на open-source😄

#ai #experience

Revival Hijack and Fake recruiter coding tests

В различных телеграм-каналах можно встретить множество упоминаний о новой атаке на цепочку поставок PyPI, известной как Revival Hijack, выявленной исследователями из JFrog. Суть атаки заключается в загрузке вредоносного пакета с тем же именем, что и у популярного пакета, который был удален. Это возможно благодаря тому, что PyPI позволяет использовать имя пакета практически сразу после его освобождения. Уже опубликовано немало постов с подробным разбором этой уязвимости на русском языке, поэтому не видим большой необходимости углубляться в детали. Для нас примечательнее скорее то, что эта атака не является совершенно новой: о ней сообщали исследователи из ReversingLabs еще в апреле 2023 года, однако тогда она не вызвала большого резонанса как сейчас 😅. Более того, ReversingLabs также предоставили инструмент для онлайн-идентификации подобных вредоносных пакетов.

В преддверии возможных аналогичных громких заголовков расскажем о еще одном сценарии атаки, который недавно, около недели назад, описали те же исследователи из ReversingLabs. Речь идет о целенаправленной атаке на разработчиков через вредоносный код, замаскированный под тестовое задание от фейкового HR в рамках python проекта. Атака осуществляется следующим образом: фейковый HR связывается с разработчиком через LinkedIn, предлагая решить тестовое задание, которое предполагает нахождение и исправление бага в проекте. Для этого требуется, соответственно, необходимо выполнить сборку, во время которой запускается исполняемый python-файл. В результате жертва подключается к C2 серверу. Помимо известных примеров подобных вредоносных заданий, в сети также были обнаружены реальные жертвы среди разработчиков. На данный момент известно, что за этой вредоносной кампанией, получившей название VMConnect, скорее всего стоит северокорейская APT-группа, действующая в интересах правительства.

P.S. Но самое забавное во всех этих атаках то, что за поверхностным разнообразием инструментов и сценариев скрываются универсальные принципы и базовые архитектурно-процессные изъяны, хорошо известные специалистам с 80-х годов, а то и раньше. Ведя книжный клуб в Кибердоме ваш покорный слуга открыл для себя Клиффорда Столла и «Яйцо кукушки: история разоблачения легендарного хакера». Эта любопытная, но нудноватая книга, на материале 1986 года наглядно показано как "уникальная специфика мира КИИ, цепочек поставок и кибервойн" на деле является давно известной и хорошо изученной территорией, но как обычно "скорость прогресса", пресловутый TTM и плохое понимание и игнорирование универсальных принципов PDCA приводят к тому, к чему приводят и даруют работу десяткам тысяч безопасников по всему миру, создавая ещё один дефицит на рынке труда....

#supplychain #attack

AI Security Newsletter

В свете текущих тенденций мы всё чаще пишем о синергии AI и безопасности. История про автоматизацию ИБ с помощью ИИ - это не только способ преодолеть пресловутый дефицит кадров (который, если смотреть исторически существовал, кажется, всегда: что во времена индустриализации 30х годов 20 века; что времена средних веков и аграрного хозяйства, что...), но и возможность реализовать пресловутый риск-ориентированный подход и гибкость системы защиты на практике (именно за счет применения ИИ, и высокоскоростной аналитики событий, журналов, изменений, угроз и т.д. мы впервые в истории получаем объективную возможность попытаться выстроить достаточно взвешенный подход к управлению ИБ организации).

В этот раз мы решили не мелочиться и предлагаем ознакомиться с пакетом материалов, который мы нашли за последние несколько недель.

1). jthack/ffufai – расширение для известного фазера ffuf, которое предлагает варианты файловых расширений для тестирования на основе предоставленного URL и заголовков. В основе используется выбор между OpenAI и Anthropic;

2). Using AI for Offensive Security - материал от Cloud Security Aliance о применении AI в OffSec, включая методики reconnaissance, scanning, vulnerability analysis, exploitation, и reporting.

3). The tech behind Semgrep Assistant’s triage and remediation guidance – статья о том, как работает AI Assistant от Semgrep. Используемый LLM помогает предложить варианты исправления уязвимостей в PR. Semgrep пошли дальше и предоставили клиентам своей enterprise-версии возможность автоматически генерировать правила на базе их движка, используя промпт.

4). Provisioning cloud infrastructure the wrong way, but faster - статья посвящена рискам использования LLM для генерации небезопасного Terraform-кода. Одной из проблем является то, что ИИ может сгенерировать инструкции для создания виртуальных машин с захардкоженными паролями, далеких от соответствия корпоративным политикам безопасности. В качестве примера в статье приведён пароль "P@ssw0rd1234!", предложенный ИИ при создании VM. Это происходит потому, что ИИ использует метод "следующего наиболее вероятного токена" для генерации текста, который не подразумевает полноценную рандомизацию, делая пароли предсказуемыми. Примечательно, что даже при использовании скриптов, созданных с помощью ChatGPT, пароли генерируются через небезопасный метод random...

5). TL;DR: Every AI Talk from BSidesLV, Black Hat, and DEF CON 2024. Подборка материалов по AI и security с конференций BSidesLV, Black Hat USA, DEF CON, проводимых в 2024 году (больше 60 докладов).

#ai

🙃

#Юмор

CI/CD Attack Diagram

В развитии недавнего поста - диаграмма* атак на CI/CD на примере GitHub. Для каждого шага работы CI/CD описываются актуальные "сценарии провала", по некоторым из которых даны линки на статьи с подробными описаниями соответствующих атак и утилитами для их автоматизации.

Автор схемы - John Stawinski IV (именно так он именует себя на личном сайте) - с 2023 года сосредоточен на исследованиях атак на CI/CD в компании Praetorian.

*Фрагмент соответствующей схемы на ваших экранах

#ci #scheme

Друзья, подписчики и читатели! В день знаний символично открыть новую страницу в истории канала. На эту идею нас натолкнули последние посты, и размышления об эволюции безопасной разработки и развитии prodsec. Что мы имеем?

- DevSecOps "как вещь-в-себе" вылетает из хайповых трендов (привет аналитика gartner!);
- DevSecOps без наличия зрелых сопутствующих практик, вроде развивающегося AI, reachability analysis и ASPM теряет смысл (а на самом деле, если вспомнить лучшие практики и системный подход к управлению ИБ а-ля ISO 27001 - никогда его не имел, как не имеют смысл отдельные меры не встроенные в систему управления "как в целое");
- Написание интересных постов про DevSecOps без затрагивания других областей, типа AppSec и ProdSec, стало практически невозможным - это либо пережевывание "хорошо известного старого" (для чего появляется все больше курсов, гайдов, программ); либо достаточно частная и слишком узкая тема (не интересная широкой аудитории);
- На фоне этого нам удается находить все меньше статей и материалов про голые практики DevSecOps. Все меньше людей довольствуются фразой "DevSecOps - это стратегическое решение". Комьюнити уже не впечатляют выстраивание secure SDLC как таковое, комьюнити интересно видеть то, что поможет им получить как можно больше ощутимого профита, а это зачастую выходит далеко за пределы автоматизации в CI/CD и затрагивает проблемы далеко за рамками DevSecOps.

Таким образом за 5 лет существования канала тематика DevSecOps в пространстве .ru прошла пик, и вышла на определенный "уровень зрелости". А мы, чтобы не потерять интерес к ИБ и сохранить полезность канала для коммьюнити постараемся расширить круг тем, и оставаться на фронтире кибербезопасности, чего бы нам это не стоило 🙃 А что думаете вы? О чем бы вам хотелось читать на Security Wine и поддерживаете ли вы расширение тематик?

P.S. Дополнительно обращаем внимание, что заявление выше не означает отказ от "классики жанра": в канале продолжат выходить и более консервативные материалы, ровно как сохранится история "прошлых постов". Поэтому вы всегда сможете вернуться "в прошлое" и найти актуальные для ваших кейсов материалы.

#оргвопрос #strategy

Channel name was changed to «Security Wine (бывший - DevSecOps Wine)»

GitHub Actions Exploitation

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

Итак, рассмотрим одну из интересных атак. Атака на цепочку поставок CI через инструменты безопасности, а именно через Dependabot, сканер уязвимых зависимостей!

1) Атакующий создаёт форк репозитория, куда собирается заинжектить вредонос.

2) Затем он тригерит работу Dependabot, который делает pull request (PR) в созданный форк, предлагая обновить библиотеку до безопасной версии. При этом создаётся новый форк от Dependabot для слияния. На этом этапе авторы нашли способ изменить то, что именно добавляется в PR от Dependabot, и внедрить вредоносный код (посредством излечение секрета бота через self-hosted runners и коммуникации с Dependabot API). Хотя это уже звучит угрожающе, при внимательном ревью PR вредоносные файлы все равно могут быть обнаружены, поэтому давайте продолжим цепочку эксплуатации.

3) Далее атакующий берёт новый PR, созданный Dependabot, и вместо слияния со своим форком отправляет его в основной бранч репозитория жертвы (main). GitHub позволяет изменить цель PR, перенаправив его из одного бранча в другой. В этом случае, хотя PR и был создан ботом, авторство будет приписано атакующему, так как он инициировал действия, а не сам Dependabot.

В обычной ситуации на этом всё должно было бы закончиться, но не в случае с авторами репозитория spring-security. Они намудрили с actions на GitHub, разрешив автоматическое слияние PR, если github.actor == 'dependabot[bot]'. Проблема в том, что в контексте GitHub github.actor — это не автор бранча, а последний пользователь, совершивший действие с PR!

4) Атакующий вызывает Dependabot повторно в своём PR в main, после чего уязвимый workflow автоматически сливает PR, включая вредоносный код.

Фикс в данном случае - использовать github.event.pull_request.user.login, а не github.actor, который выдает именно автора PR как и ожидается.

SynAcktiv также поддерживает собственный инструмент octoscan для анализа безопасности GitHub Actions, куда они уже добавили файндинги со своих ресерчей.

Среди других статей от них мы также рекомендуем ознакомиться с Introduction, где авторы разбирают базовые аспекты атакующего на GitHub Actions, а также со статьей про Untrusted Input.

Здесь важно понимать, что данная проблема не является уникальной для GitHub; аналогичные проблемы и векторы атак могут возникнуть в любом элементе цепочки поставок. Обратите внимание на причины, которые привели к появлению уязвимости:
- Наличие вызовов в платформе GitHub, название которых говорит совсем не о том, как их воспринимает конечный пользователь с позиции "здравого смысла".
- Использование вызовов авторами, не до конца разобравшимися в их логике работы.
- Автоматический обход ревью, основанный на неочевидных скриптах, которые могут быть использованы широким кругом лиц...

А если вы еще пока далеки от темы CI/CD Security, но хотите с легкостью понимать, о чем здесь идет речь, вот вам awesome ci-cd attacks, где есть и Threat Matrix, use cases, инструменты и многие другие ресерчи.

#cicd

Making Sense of the Application Security Product Market

Недавно мы опубликовали пост о наших размышлениях на тему AppSec, ProdSec и DevSecOps, который вызвал широкий отклик среди наших читателей в чате. Сегодня мы наткнулись на статью, которая повторяет многие из этих тезисов, дополняя их новыми аспектами, о которых мы хотели бы также поговорить.

- AppSec охватывает буквально все: приложения, CloudSec, ProdSec, DevSecOps, AI Security, SaaS Security, Data Security, Runtime Security. Это также перекликается с определением CNAPP от Gartner.

- Систематичные практики AppSec по устранению выявленных проблем пошли дальше и распространись на облака, API, что привело к появлению Product Security, который включает AAA, privilege management, secrets management, encryption и тд.

- SAST, DAST и WAF по отдельности остаются классами инструментов, которые генерируют больше шума, чем пользы. По мнению автора, они продолжат существовать, но скорее станут частью более широкого кастомизированного класса продуктов.

- CSPM-решения вроде Wiz добились успеха благодаря отличному UI/UX и механизмам приоритизации, таким как "Attack Paths".

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

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

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

#trends

Security Templates

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

Первый из них — шаблон моделирования угроз по STRIDE для Miro от самого Head of Product Security Miro. Этот шаблон наглядно демонстрирует процесс моделирования угроз и включает сопутствующие диаграммы, которые помогают на каждом этапе составления списка угроз.

Второй — это целый набор шаблонов от Robert Auger. Роберт делится материалами, которые помогали ему на его пути в построении программ bug bounty, управления уязвимостями, внешнего пентеста и реагирования на инциденты. Во всех своих шаблонах Роберт опирается на свой опыт в таких компаниях, как PayPal, eBay, Box, Workday и Coinbase. В качестве примера к посту приложена упрощенная диаграмма процесса bug bounty. Еще нам в целом понравился чеклист в подготовки построения процесса vulnerability management, который также учитывает AppSec-процессы. По нему хорошо можно проследить попытку автора передать именно свой личный опыт.

#templates #process

Harnessing LLMs for Automating BOLA Detection

Одна из самых распространённых уязвимостей в веб-приложениях — это broken access control. На сегодняшний день SAST и DAST бесполезны при их поиске, и всем известно, что выявление таких уязвимостей решается исключительно ручным тестированием с помощью плагинов для Burp, таких как Autorize, AuthMatrix, Authz.

Однако, недавно мы наткнулись на статью от Unit42 (Palo Alto Networks) о том, как они автоматизировали поиск уязвимостей типа broken object level authorization (BOLA) с помощью ИИ. В качестве входных данных используется спецификация OpenAPI, после чего механизм ищет потенциально уязвимые API, где происходит обращение к объектам (например, username, email, teamId, invoiceId, visitId). Далее строится дерево зависимостей между этими эндпоинтами и формируются тестовые кейсы, в которых инструмент пробует различные сценарии обращения к объектам на основе имеющихся доступов двух пользователей. Если один из пользователей имеет доступ к объектам другого, то существует высокая вероятность наличия уязвимости BOLA.

Звучит достаточно интересно и логично автоматизировать такого рода тестирования! В результате исследователи обнаружили уязвимости в Grafana (CVE-2024-1313), Harbor (CVE-2024-22278) и Easy!Appointments (целых 15 CVE). Они также отметили, что эксперименты показывают: обратная связь от людей постоянно улучшает точность и надёжность ИИ.

В конце статьи также много полезных ссылок на смежные исследования Unit42.

P.S. Кстати, вот еще один прекрасный пример поиска CVE с помощью LLM - анализ вылетов на предмет полезности при фаззинге браузера.

#ai

А между тем череда интересных митапов продолжается. Вот и Купер.тех (ex-СберМаркет) подготовил свой DevSecOps митап со спикерами из RuStore, Positive Technologies, Купер.тех (ex СберМаркет), SolidLab и MTS Web Services.

Дата: 21 августа в 19:00

Место: Москва, офис Купера + онлайн

На митапе будут представлены доклады на следующие темы*:

- Как выстроить DAST на Open-Source: гибкое использование Nuclei и ZAP под сервисы компании
- Вредные советов для вашего ASPM.
- Написали свою DSO-платформу, но все равно купили ASOC. Да как так-то?…
- Опыт тестирования Defect Dojo SASTами
- Какой должен быть SAST?

*по итогам каждого доклада и в афтерпати - обсуждение тем со спикерами

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

#event #инфо

Container and Kubernetes Security Fundamentals

Я уверен, что многие из вас заметили, что мы редко затрагиваем вопросы безопасности Kubernetes и контейнеров, хотя обладаем соответствующей экспертизой. Поэтому вечерком, под чашечку расслабляющего чая, давайте преисполнимся оркестрации.... Мы не могли пройти мимо и решили опубликовать уже не новую, но постоянно обновляемую серию видео и статей от известного исследователя Rory McCune под названием "Kubernetes Security and Container Security Fundamentals" (ссылка на статьи). Материалы охватывают важные аспекты безопасности Kubernetes, включая его компоненты, а также такие механизмы безопасности контейнеров, как capabilities, namespaces, AppArmor, SELinux, cgroups и seccomp-фильтры.

В одном из последних материалов, опубликованных около двух недель назад, рассматривается вопрос авторизации в Kubernetes, включая модули авторизации (AlwaysAllow, AlwaysDeny, Node Authorizer, ABAC, RBAC) и авторизацию на уровне компонентов.

Rory McCune известен своими статьями еще с тех времен, когда работал в Aqua Security. Большую известность он получил как соавтор Kubernetes Benchmark и Docker Benchmark от CIS, а также как автор документа "Guidance for Containers and Container Orchestration Tools" для PCI DSS.

Этот курс идеально подходит для начинающих, а учиться никогда не поздно! Даже ночью 🙃

#k8s #docker #containersecurity