Меня зовут Алексей Гришин, я руководитель направления 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 основные составляющие:

1. Названные домены. C такими доменами все просто, если в нем найти уязвимость, то за нее вознагражден будет в соответствии с правилами программы.

2. 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 правил эффективности багхантера.

1. Ищите баги только в заявленных доменах. Этим вы убережете себя и от конфликта интересов с владельцем Bug Bounty программы и от последующего разочарования. 

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

3. Не составляйте рекомендации по исправлению уязвимости (не тратьте на это свое время) — это зона ответственности внутреннего аналитика, а не хакера. 

4. Собирайте подтверждения (пруфы). Обязательно вместе с отчётом предъявляйте все возможные PoC (скрипт, видео, скрин и т.д.), подтверждающие, что в данный момент времени вы смогли что—то проэксплуатировать*.  

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

*Комментарий автора: Исследователи должны понимать, что это требование возникает не из вредности владельцев программ, а потому что именно на основании подтверждений происходит распределение финансов и принимаются решения по выплатам. За теоретическую возможность что-то сломать оплата не производится. Если исследователь очень хорошо описал теорию, но не смог применить ее на практике, то шансы получить деньги очень малы.

PS: Нам, как ребятам, отвечающим за работу программы Bug Bounty VK, интересно, чтобы исследователи приносили нам максимально сложные и дорогие уязвимости. 

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