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

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

1 комментарий

Почему участники багбаунти нашли в прошлом году 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-щиков 😉

Доклад Рустэма Хайретдинова про багбаунти

Добавить комментарий

Доклад Рустэма Хайретдинова про багбаунтиДоклад Рустэма Хайретдинова про багбаунтиДоклад Рустэма Хайретдинова про багбаунтиДоклад Рустэма Хайретдинова про багбаунти

Доклад Рустэма Хайретдинова про багбаунти. Доклад был секретный про внутреннюю кухню багбаунти-сервисов. Видео для него не будет. Были интересные подробности. 👍 Из того, что можно было сфоткать это 3 слайда со сравнением пентеста и багбаунти. Что в итоге выбрать? "И то, и другое, и можно без хлеба" (с)

Не грех пошарить важную новость:

Добавить комментарий

Не грех пошарить важную новость:

"Тинькофф запустил публичную программу по поиску ошибок и уязвимостей в своих сервисах за вознаграждение на платформе BI.ZONE Bug Bounty. В ней могут участвовать любые исследователи безопасности из России и стран ЕАЭС."

Собственно ссылка на программу.

Что в скоупе:

"Уязвимости можно искать на всех наших ресурсах, а именно — *.tinkoff.ru, *.tcsbank.ru, *.tinkoffinsurance.ru." Но максимальные выплаты только для уязвимостей определенных сервисов.
Максимальная выплата за Critical 150 000 ₽.

За что платят:

"Ниже приведены примеры уязвимостей, за которые мы с радостью выплатим вознаграждение (список далеко не полный):

Удаленное исполнение кода (RCE);
Инъекции (например, SQL-инъекции или XML-инъекции);
LFR/LFI/RFI;
SSRF;
Утечки памяти;
Уязвимости бизнес-логики;
IDOR;
Уязвимости контроля доступа;
Раскрытие чувствительной информации;
Угон аккаунта;
Недостатки аутентификации/авторизации;
XSS и CSRF с воздействием на чувствительные данные."

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