CI/CD Attack Diagram

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

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

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

#ci #scheme

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

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

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

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

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