Меня зовут Алексей Гришин, я руководитель направления 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, интересно, чтобы исследователи приносили нам максимально сложные и дорогие уязвимости.
Следуйте нашим советам, принимайте участие в наших программах, общайтесь с нами и составляйте отчёты так, чтобы мы могли заплатить вам максимум.
Автор: Алексей Гришин
