Как заработать на Bug Bounty
Меня зовут Алексей Гришин, я руководитель направления Bug Bounty VK. За 9 лет участия в программе по поиску уязвимостей на различных платформах мы накопили огромный опыт получения, проверки и оплаты самых разношерстных отчётов, поэтому в этой статье я хочу поделиться советами о том, как правильно написать отчёт, чтобы его оплатили, и рассказать, что делать, если ваши ожидания по выплатам не совпали с реальностью. Добро пожаловать под кат.
Эволюция Bug Bounty в VK
Впервые программа Bug Bounty VK возникла 9 лет назад для почтового сервиса Mail.ru, и надо сказать, что в тот момент программы по поиску уязвимостей только начали набирать популярность и мы были среди первопроходцев по их организации и развитию.
В частности, у нас самих сперва не было четкого видения и требований к тому, как должен выглядеть хороший репорт. Поэтому спустя время мы выработали такую формулу — засчитывали и оплачивали только полезные отчёты, т.е. в которых были правильно и корректно описаны уязвимость и её влияние, а также приведен PoC (proof of concept).
За прошедшие годы Bug Bounty внутри всей инфраструктуры VK значительно разрослась и эволюционировала до системы с большим количеством различных программ, которые классифицированы и разделены по небольшим группам (скоупам). Мы выделяем сегменты либо по продуктам, либо по разрабатывающим их командам.
Для исследователей это стало, с одной стороны, удобнее — можно выбрать точный и понятный набор из IP—адресов и доменных имен, чтобы прицельно охотиться только на уязвимости в одном проекте, а с другой стороны, усложнило процесс, так как нужно помнить, к какому скоупу надо отнести случайно найденную уязвимость.
Совет №1: Помни, что искать уязвимость вне заявленных направлений — это всегда определенный риск. Ты можешь потратить время и не получить оплату за свою работу, так как владелец программы Bug Bounty не ожидает проблем в данном скоупе и у него нет бюджета для их оплаты.
Шпаргалка по проблемным зонам поиска багов
Для опытного охотника за багами предельно понятно, где и как искать уязвимости, но для новичков мы хотим рассказать, в каких случаях может возникать двусмысленность и конфликт интересов при поиске ошибок. Классифицируем все домены и расскажем, когда владелец программы Bug Bounty платит за найденные ошибки.
Область поиска уязвимостей можно разделить на 2 основные составляющие:
Названные домены. C такими доменами все просто, если в нем найти уязвимость, то за нее вознагражден будет в соответствии с правилами программы.
Wildcard домены (или те, что «под звездочкой»). В широких областях поиска иногда присутствуют домены, которые могут разочаровать исследователя отсутствием оплаты или тем фактом, что найденную в них уязвимость вообще не примут и не будут рассматривать. Давайте разберем их подробно.
Совет №2: В Wildcard попадают домены без оплаты не специально, они появляются там из—за постоянного развития и изменения программного продукта, в котором исследователь ищет уязвимость. Внимательно следите за новыми версиями ПО, изменения всегда несут в себе ошибки, а следовательно, и возможность заработать для исследователя.
Типы неприятных доменов в областях поиска «со звёздочкой»:
Тестовый домен. Может появиться в области поиска уязвимостей, если разработчикам нужно проверить технологию или решение. В таком WEB—сервисе нет важных данных (исключением может стать код, который потом будет использоваться в «боевом» продукте), а если нет данных, то и влияния от уязвимости нет. Соответственно, в таком случае, уязвимость будет исправлена, но не оплачена. Максимум, что можно заработать тут, — это опыт и очки рейтинга…, но их на хлеб не намазать.
Учебный домен. Создан с целью научить студента, нового сотрудника, провести отбор кандидатов или организовать публичный конкурс; реже, это может быть домен платформы для обучения на платной основе. Такие домены изначально предполагались ко взлому — в них нет ничего ценного. Хорошим тоном является их исключение из области поиска в Bug Bounty программе, но к сожалению, иногда они случайно попадают в широкие зоны поиска. За учебные домены не предполагается оплата, а уязвимости на них исправлены не будут (домены CTF—соревнований тому яркий пример).
Партнёрский/брендированный домен. Создается для проверки аналитических гипотез или в рамках партнерств, и зачастую сервера, обслуживающие WEB—приложение, находятся не под управлением владельца Bug Bounty программы. Оплата труда хакера при нахождении уязвимостей в таких доменах зависит от конкретного случая и только если исправление ошибки возможно. При обнаружении таких старых или не используемых партнерских доменов их следует убрать, чтобы они не попадали в зону поиска в будущем, но это не всегда возможно.
Изолированный домен. Не несет угрозы инфраструктуре, специально спроектирован для защиты от утечек. Оплата напрямую зависит от угрозы и критичности данных внутри него. Уязвимости типа SSRF на таких доменах не принимаются и не оплачиваются… в программах VK так точно.
Совет №3: Вероятность найти уязвимость в домене, входящем в Wildcard, выше, но это и более рискованное дело, так как может встретиться один из этих неприятных доменов. Если клинок обоюдоострый — будь аккуратен.
Надеемся, эта информация поможет тебе не потратить свои силы впустую и выбрать лучшую цель для поиска ошибок.
Шпаргалка по составлению идеального отчёта
Если исследователь хочет получить деньги в полном объеме и не отвечать на миллион уточняющих вопросов в переписке с аналитиком программы Bug Bounty, то лучше следовать определенному алгоритму описания уязвимости.
Образцовый отчёт должен содержать следующую информацию:
1. Правильно составить тему отчёта, указав название типа уязвимости, домена/приложения или IP—адрес и уязвимой «ручки» API.
2. В теле отчета описать вектор атаки:
Если атака не требует аутентификации, то вектор должен быть оформлен в виде команды c URL;
Если атака требует аутентификации и для её демонстрации достаточно GET—запроса, то вектор должен быть оформлен в виде полного URL, демонстрирующего ее исполнение, а также должна быть предоставлена информация о роли, необходимой для эксплуатации;
В любом другом случае WEB—уязвимости, участвующие в векторе атаки, должны быть оформлены в виде примера запроса, который необходимо выполнить в Burp Suite (оформленного в виде блок кода);
Бинарные уязвимости должны быть описаны подробно, с предоставлением кода и параметров сборки, если они необходимы при эксплуатации
3. Пошагово описать все действия, приводящие к эксплуатации уязвимости, со вставками блоков кода для запросов и ответов сервера на тех этапах, где это необходимо, включая название браузера, которым проверяется уязвимость (даже если она воспроизводится в любом браузере).
4. Для приложений или бинарных уязвимостей, воспроизводимых в определенных условиях, указать версию приложения и/или окружения.
5. Завершить отчёт кратким описанием влияния на безопасность.
Ниже пример отчёта с описанием одной и той же уязвимости двумя разными исследователями.
Пример отчёта среднего качества:
Пример хорошего отчёта:
Совет №4: Скупой платит дважды. Не жалейте время на хороший отчёт, он с большей вероятностью принесет вам вознаграждение и не придется отвлекаться на массу уточняющих вопросов.
Вместо заключения, или Топ—5 правил эффективности багхантера.
Ищите баги только в заявленных доменах. Этим вы убережете себя и от конфликта интересов с владельцем Bug Bounty программы и от последующего разочарования.
Подробно и корректно опишите алгоритм воспроизведения найденной уязвимости и влияние от нее. Помните, что все скрытые нюансы превращаются в дополнительные вопросы, которые впоследствии отвлекают и раздражают вас.
Не составляйте рекомендации по исправлению уязвимости (не тратьте на это свое время) — это зона ответственности внутреннего аналитика, а не хакера.
Собирайте подтверждения (пруфы). Обязательно вместе с отчётом предъявляйте все возможные PoC (скрипт, видео, скрин и т.д.), подтверждающие, что в данный момент времени вы смогли что—то проэксплуатировать*.
Избегайте конфликтов. Это всегда большая трата ресурсов и нервов с обеих сторон. В любой спорной ситуации приведите качественные аргументы в вашу пользу и попросите пересмотреть выплату. В патовых ситуациях, при уверенности в своей правоте, обратитесь к владельцу платформы как к лицу с независимой экспертизой.
*Комментарий автора: Исследователи должны понимать, что это требование возникает не из вредности владельцев программ, а потому что именно на основании подтверждений происходит распределение финансов и принимаются решения по выплатам. За теоретическую возможность что—то сломать оплата не производится. Если исследователь очень хорошо описал теорию, но не смог применить ее на практике, то шансы получить деньги очень малы.
PS: Нам, как ребятам, отвечающим за работу программы Bug Bounty VK, интересно, чтобы исследователи приносили нам максимально сложные и дорогие уязвимости.
Следуйте нашим советам, принимайте участие в наших программах, общайтесь с нами и составляйте отчёты так, чтобы мы могли заплатить вам максимум.
