Архив метки: Bugcrowd

На сайте Positive Technologies вышло исследование "Рынки монетизации уязвимостей"

На сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостей

На сайте Positive Technologies вышло исследование "Рынки монетизации уязвимостей". Сделаю краткую выжимку.

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

⚖️ Легальный рынок

Багбаунти является основным легальным способом монетизации уязвимостей. Компании выплачивают исследователям вознаграждения за найденные уязвимости в системах, продуктах и сервисах. Основной фокус багбаунти-программ составляет внешняя поверхность атаки: веб-приложения, API и корпоративная инфраструктура. 96% исследователей работают с веб-приложениями, а с ОС и ПО - лишь 38%. Чаще всего выявляют XSS, ошибки контроля доступа и конфигураций.

Компании могут запускать собственные программы или использовать платформы вроде HackerOne, Bugcrowd и Standoff Bug Bounty. Стоимость размещения компаний на платформе составляет около 1 млн ₽ в год в России и 15 000 - 50 000 $ за рубежом. Размер выплат зависит от критичности уязвимости. Максимальные вознаграждения за отдельные типы уязвимостей достигают 2,4 млн ₽.

🌫️ Серый рынок

Серый рынок монетизации уязвимостей занимает промежуточное положение между легальными багбаунти-программами и теневыми площадками. Исследователи передают данные об уязвимостях посредникам или специализированным компаниям, а дальнейшее использование информации часто остается непрозрачным. Как правило, брокеров интересуют эксплоиты для 0-day-уязвимостей, стоимость которых может достигать 2,5 млн $.

🚫 Нелегальный рынок

Теневые форумы представляют нелегальный рынок уязвимостей. 0-day уязвимости там ценятся выше всего и они чаще всего выставляются на продажу: 49% всех объявлений. Объявления о продаже 1-day уязвимостей встречаются реже и составляют 11% от общего числа. В 38% объявлений речь идёт не о продаже, а о покупке данных о конкретной уязвимости.

Наиболее востребованы уязвимости удаленного выполнения кода (RCE) и повышения привилегий (LPE), на которые приходится 43% и 25% объявлений о продаже уязвимостей соответственно. Основные цели: интернет сервисы (36%) и корпоративное ПО (33%).

Стоимость уязвимостей определяется их эксплуатационной ценностью. Наибольший интерес представляют редкие и сложные для обнаружения уязвимости с высоким потенциалом применения. В 47% объявлений цена на уязвимости не указывается. Цена 0-day уязвимостей на чёрном рынке может быть до 20 раз выше, чем в багбаунти-программах.

На этом рынке также активно развивается сервисная модель. Уже около 7% объявлений об услугах связаны с покупкой или продажей услуг по эксплуатации уязвимостей в программном обеспечении. При этом 0-day уязвимости упоминаются в 40% таких объявлений, что подтверждает их высокую востребованность.

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

💡 Рекомендации

Компаниям следует сочетать технические и аналитические меры защиты: использовать багбаунти для непрерывного поиска уязвимостей, кибериспытания для проверки реальных сценариев атак и threat intelligence для мониторинга угроз и теневых площадок.

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

Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч?

Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч?

Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч? Подсмотрел занимательный вопрос в канале Алексея Лукацкого.

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

С другой стороны, есть мобильные приложения, которые тоже часто попадают в скоуп багбаунти. А у мобильного приложения уже есть версия и пользователи могут использовать разные версии мобильного приложения. И, получается, для мобильных приложений уже может быть смысл заводить CVE.

В принципе, ничего не мешает сделать багбаунти программу вообще для любых приложений. Например, на hackerone есть багбаунти для Chrome/Chromium. И для этих уязвимостей Google заводит CVE. Ничего не запрещает самому вендору заводить CVE под найденные в рамках багбаунти уязвимости кроме нежелания этого вендора.

И не сказать, что это требует каких-то особенных усилий со стороны вендора, т.к. сама багбаунти платформа может заводить CVE уязвимости для своих клиентов. В списке CVE Numbering Authority (CNA) есть 11 организаций типа "Bug Bounty Provider", включая Bugcrowd, HackerOne, ZDI:

"Provides CVE IDs for its customers as part of its bug bounty and vulnerability coordination platform"

В общем, уязвимостей меньше, потому что не для всех уязвимостей есть смысл заводить CVE. А для тех уязвимостей, для которых смысл есть, CVE идентификаторы не заводят, т.к. сам вендор уязвимого продукта этого не хочет. 🤷‍♂️ А сам исследователь хоть и может добиться заведения CVE идентификатора помимо воли вендора, но это не массовая история.

PS: хороший вопрос для собеседования VM-щиков 😉