Меня зовут Алексей Гришин, я руководитель направления Bug Bounty VK. За 9 лет участия в программе по поиску уязвимостей на различных платформах мы накопили огромный опыт получения, проверки и оплаты самых разношерстных отчётов, поэтому в этой статье я хочу поделиться советами о том, как правильно написать отчёт, чтобы его оплатили, и рассказать, что делать, если ваши ожидания по выплатам не совпали с реальностью. Добро пожаловать под кат. Впервые программа 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, интересно, чтобы исследователи приносили нам максимально сложные и дорогие уязвимости.  Следуйте нашим советам, принимайте участие в наших программах, общайтесь с нами и составляйте отчёты так, чтобы мы могли заплатить вам максимум.   Меняю жуков на деньги в компании VK