Non-Actionable Findings в 3rd-party Security Scanners...и как их распознать

Инженер Google написал блог-пост о том, как обрабатывать результаты CVE от сканеров безопасности и как распознать те, которые можно спокойно убрать из списка задач на фиксы.

Краткий конспект от нашей команды:

Rejected уязвимости: Самый простой вариант — исключить уязвимости с пометкой rejected в NVD (например, CVE-2023-4881). Это имеет смысл, когда сканер тащит весь NVD без минимальной фильтрации. Такой случай не особо интересен, двигаемся дальше.

Переоценка от мейнтейнеров: Бывает, что NVD отмечает уязвимость как high, а мейнтейнеры ОС считают, что у неё минимальный импакт и не выпускают патчи для своих дистрибутивов Linux. В таких случаях мнение мейнтейнеров может быть более релевантным, и уязвимость можно классифицировать как false positive.
Пример — CVE-2018-20657:

10-byte memleak, not considered important to be fixed by upstream, so no patch is available as of 2023-06-02

Отсутствие импакта на используемую ОС: NVD может показывать широкий диапазон уязвимых версий пакета, но не учитывать влияние на конкретную версию ОС. Если сканер использует только данные NVD и игнорирует статусы not affected от ОС, то он может ложно сработать на уязвимость, которой на самом деле нет (пример CVE-2023-52426)

Кастомные патчи от ОС: Иногда сканеры не учитывают кастомные патчи, которые ОС выпускает для фиксов. Например, сканер видит версию Python 3.6.10 как уязвимую, но Ubuntu выпустила патч с версией 3.6.9-1~18.04ubuntu1.1. Внешние сканеры, использующие NVD вместо базы уязвимостей от Ubuntu, могут ложно считать патченную версию Python уязвимой.

Неполная информация об уязвимости пакета: Некоторые фиды, как Debian, репортят уязвимости только для исходных пакетов. Сканеры часто ошибаются, считая уязвимыми все связанные бинарные пакеты, даже если они не содержат уязвимых библиотек. Например для уязвимости CVE-2024-6387 затрагивается только OpenSSH-серверы, но Debian отмечает уязвимым исходный пакет "openssh". В итоге даже системы с установленным только "openssh-client" будут ошибочно помечены как уязвимые, хотя уязвимых библиотек там нет.

Нерелевантные к безопасности срабатывания: Некоторые сканеры репортят пакеты, не связанные с безопасностью. Например, Trivy репортит файндинги из Debian LTS (DLA) о таких вещах, как обновления часовых поясов или новые GPG-ключи, которые не влияют на безопасность. Отсутствие этих обновлений не создает рисков для безопасности.

А какие классификации используете вы? Может быть расширим и углубим список "гугла"?

#sca #supplychain

GitHub Users Targeted by New Wave of Spambots

Ищите чтиво на выходные? Если вдруг вы увидели спам в комментариях своего репозитория на GitHub на этой неделе, вы не одиноки. Недавно мы писали об атаках на разработчиков, но на этот раз методы напоминают устаревшие практики. Боты оставляют комментарии, предлагая загрузить файлы с платформы MediaFire, содержащие вредоносное ПО. Цель злоумышленников — убедить разработчиков загрузить эти файлы, что в итоге приводит к компрометации системы и аккаунта GitHub.

GitHub пытается удалять такие комментарии, но проблема остается. Один из разработчиков создал GitHub Action, который фильтрует подобные комментарии.

"Это не должно быть задачей мейнтейнеров open-source — предотвращать спам с вредоносным ПО, но пока GitHub не решит эту проблему, я создал небольшой автоматизированный action, которая удаляет подозрительные ссылки из комментариев в задачах."

В целом подобного рода атаки на open-source не первые и не последние. В феврале этого года волна спама обрушилась на проект Express.js в следствие того как популярный youtube блогер с почти 5 млн подписчиками продемонстрировал пример как делать PR на нетестовом Github репозитории (вот здесь можно увидить результат). Несмотря на то, что это может показаться безобидным, но дело дошло даже до того один из мейнтейнеров Express.js заявил, что люди начали отправлять электронные письма с угрозами и преследовать участников репозитория за открытие спам-запросов на слияние (PR).

#supplychain #malware

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

Secrets and Shadows: Leveraging Big Data for Vulnerability Discovery at Scale

Помните, когда Big Data была такой же популярной, как сейчас искусственный интеллект?

Очень объемная и интересная статья "Secrets and Shadows: Leveraging Big Data for Vulnerability Discovery at Scale". Автор с высокой степенью детализации описывает исследование, которое началось еще в 2021 году. Оно посвящено двум аспектам: поиску "висящих" DNS-записей (записей, указывающих на освобожденные IP-адреса, что может привести к захвату домена) и поиску hardcoded credentials в больших объемах данных, полученных из открытых источников.

В рамках данного поста мы сосредоточимся на аспекте поиска hardcoded credentials, хотя рекомендуем ознакомиться и с кейсом, связанным с DNS-записями.

Многие инженеры знакомы с сервисом VirusTotal, созданным для быстрого анализа файлов на предмет вредоносного кода. При загрузке файла VirusTotal выводит сообщение:

By submitting data ... you are agreeing ... to the sharing of your sample submission with the security community

Вопрос извлечения и анализа загруженных файлов в VirusTotal достаточно прост: используя инструмент Retrohunt и написав YARA-правило, можно извлекать образцы из ранее загруженных файлов на основе регулярных выражений. Учитывая, что захардкоженные секреты часто имеют определенные regexp паттерны, это идеальный способ их идентификации в загруженных файлах. Однако автор пошел дальше, стремясь извлечь и те секреты, которые не поддаются стандартным паттернам. Для этого он искал косвенные признаки, такие как строки вида [a-zA-Z0-9]{32} для поиска потенциальных API-ключей. Он также создал конвейер на базе AWS Lambda для автоматизированного извлечения и проверки валидности секретов из Retrohunt.

Избегая подробностей, в результате было просканировано 5 миллионов файлов, в которых было обнаружено более 15 тысяч секретов, включая ключи OpenAI, AWS и GitHub.

Хотя статья и результаты исследования впечатляют, особенно заслуживают внимания дальнейшие действия автора. В попытке устранить выявленные секреты он решил воспользоваться функционалом GitHub. Платформа, предоставляющая открытые репозитории, может стать источником утечек конфиденциальной информации, которая быстро попадает в руки злоумышленников. В связи с этим GitHub сотрудничает с различными вендорами для оперативного отзыва таких секретов через интеграцию. Однако, поскольку GitHub не предоставляет API для массового отзыва секретов, автор был вынужден использовать кратковременные Gist'ы для публикации всех найденных данных. Идея заключалась в том, чтобы создать настолько коротко живущий Gist, который GitHub успел бы обработать для отзыва секретов, прежде чем их могли бы скомпрометировать. Тем не менее, из-за большого количества созданных Gist'ов, аккаунт автора попал под теневой бан, что лишило его возможности видеть создаваемые публикации. К счастью, несмотря на это ограничение, процесс отзыва секретов продолжал успешно работать, что позволило автору безопасно удалять ключи без дополнительных рисков.

Цитата исследователя:

Облачные провайдеры недостаточно защищают клиентов от неправильных настроек, которые они сами провоцируют. Хотя клиент создает эти уязвимости, то, как спроектированы платформы, напрямую определяет, могут ли такие проблемы возникать вообще.

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

А завершим мы пост цитатой статьи о том, что такое "The Security at Scale Mindset":
- Начните с уязвимости, а не с цели.
- Работайте в обратном направлении, используя креативные источники данных.
- Должны присутствовать взаимосвязи, указывающие на целевой класс уязвимостей.
- Должна быть возможность поиска по этим данным в масштабах.

#secrets

А вы импортозаместили виртуализацию? Тогда мы идем к вам!

С момента мая 2022 и 250 Указа прошло почти 3 года. И хотя в рамках некоторых базовых технологий типа отечественного NGFW активно продолжается так называемое развитие и конкуренция, в других областях, больше привязанных не к "железу", а к "софту", российские решения уже достигли определенного уровня зрелости. Речь не только об известных кейсах типа антивируса Касперского, который еще в досанкционные времена успешно конкурировал с западными вендорами на рынках Америки, но и о множестве других продуктов. 2022 подстегнул этот тренд и дал отечественным разработчикам дополнительные шансы "быть замеченными в своем отечестве" на фоне проверенных решений зарубежных поставщиков. И те разработчики, кто начал развитие собственных продуктов заранее, а не под влиянием "дедлайна 1 января 2025 года" получили возможность "разыграться на полную".

Из критичных для импортозамещения технологий интересно посмотреть на аналитику в области VDI, где согласно аналитикам iKS-Consulting по итогам 2023 года выделился явный фаворит отечественных виртуализаторов - компания "Базис", которая согласно исследованию:

Заняла 52% рынка виртуальных рабочих мест, а следующие игроки - ГК «Астра» и «Даком М», заняли соответственно, 9 и 8 процентов.

Образованный в 2021 году через слияние активов "Ростелекома", YADRO и Rubytech "Базис" позиционирует свои решения как импортонезависимую экосистему продуктов "от инструментов управления виртуальной инфраструктурой и средств ее защиты до конвейера для организации полного цикла разработки". Решения, само собой, сертифицируются по "высшему разряду": 4 уровень доверия согласно требованиям ФСТЭК России и возможность использования в ОКИИ 1 категория значимости, ИСПДн и АСУ ТП 1 уровня защищенности, ГИС 1 класса защиты. В сегодняшних реалиях, когда основным заказчиком подобных продуктов является крупный бизнес и государственные структуры, наличие сертификатов давно стало must have для разработчиков подобного уровня. А малосредние покупатели всегда могут найти оупен сурсные и бесплатные аналоги.

На этом фоне возникает глобальный вопрос: в сообществе много представителей как крупных, так и малых и средних компаний, оставшихся работать в России. Каков ваш опыт работы с отечественными решениями? И что вы можете сказать о своем опыте перехода/использования импортозамещенной виртуализации (особенно интересно послушать опыт товарищей, которые несмотря на большие размеры инфраструктуры остаются на оупен сурс и не собираются никуда уходить)? Можно не только о VDI, но шире... Чувствую особую остроту вопроса после начала форума Банка России.

Источник картинки: исследование iKS-Consulting

#Тренды #Импортозамещение #VDI #Виртуализация