Bug bounty: от первого отчёта до топа рейтинга

Что такое bug bounty и почему багхантинг усиливает карьеру в ИБ

Bug bounty (багхантинг) это способ легально искать уязвимости в чужих сервисах по согласованному скопу и получать за это вознаграждение. Крупнейшая в России bug bounty-платформа это Standoff Bug Bounty: больше 40 тысяч зарегистрированных пользователей, больше 26 тысяч сданных отчётов и свыше 490 миллионов рублей выплат за всё время. Поток отчётов растёт.

Выплаты не единственная ценность.

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

Некоторые команды даже вписывают опыт в bug bounty в требования для HR. Бывает, что собеседование сразу превращается в разговор об условиях и о том, что ты принесёшь в компанию: раз человек багхантер, базовые вопросы отпадают сами. Плюс широкая насмотренность. Работая AppSec в одной компании, ты видишь ограниченный набор сервисов, а на площадке через тебя проходит много разных.

Как стать багхантером: какой опыт помогает войти в тему

Тем, кто думает, как стать багхантером, технический бэкграунд почти всегда работает в плюс.

• Системное администрирование учит быстро разбираться в незнакомой области. На площадке постоянно попадается сервис или функционал, с которым раньше не сталкивался, и этот навык выручает.
• Работа аналитиком SOC даёт усидчивость и привычку копать вглубь. Можно двенадцать часов смены разбирать однотипные алерты в ожидании чего-то критичного. В багхантинге бывает так же: два или три часа ничего, а потом пазл собирается в хороший отчёт.
• CTF помогают освоить инструменты: как работает фаззинг, как пользоваться Burp. По пользе это сопоставимо с лабораториями PortSwigger. Разница в том, что в задании уязвимость заложена заранее, а в живом сервисе её может и не быть, и вокруг много мусорных запросов, в которых легко запутаться.

Bug bounty с чего начать: выбор первых программ

Выбор программы в bug bounty зависит от того, на каком ты этапе.

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

Насмотренность важнее глубины: так быстрее понимаешь, как устроены разные сервисы и какие параметры стоит проверять. Закапываться в одну программу имеет смысл позже, когда уже знаешь много векторов и понимаешь, за что конкретная программа платит больше.

Отдельно стоит смотреть на локальные программы без крупных выплат, к примеру до 30 или 50 тысяч рублей. Туда не всегда ходят топовые хантеры, поэтому сложные векторы там находить проще. Это хороший способ получить первый крит и первые заметные выплаты. А чем лучше ты проявил себя в публичных программах, тем выше шанс получить инвайт в приватные, куда пускают ограниченный круг хантеров.

Ошибки новичков в bug bounty и путь к первой выплате

Частая ошибка новичка в bug bounty в том, что он не раскрывает максимальный импакт находки. Можно сдать SSRF и не показать, до чего её удаётся раскрутить: например, просканировать внутреннюю сеть и найти внутренние хосты. Понимание импакта приходит с насмотренностью.

Первый результат может занять до месяца, и первые отчёты нередко уходят в дубликаты. Это нормально, останавливаться не стоит. Информативы тоже не вредят: их спокойно можно сдавать, а у опытного хантера их набирается больше сотни. Рабочий цикл простой:

1. 1

   Изучаешь теорию.

2. 2

   Проверяешь её руками.

3. 3

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

Потом цикл повторяется. Магической таблетки нет, работает только системность.

Дубликаты в bug bounty: как превратить дубль в опыт

Дубликат это не тупик, а источник знаний.

Если на твой отчёт об уязвимости поставили дубль и раскрыли только название первого отчёта, запроси раскрытие полного: по правилам площадки это твоё право. Чужой, более проработанный отчёт показывает, какой импакт стоило довести и какие payload использовать. В следующий раз ты не сдашь находку в сыром виде, а докрутишь её.

Дубль куда полезнее в первую очередь не для площадки и не для клиента, а для тебя как для хантера: посмотреть со стороны, сделать вывод, записать себе в заметки.

Роман Приходько

Ещё один приём касается статуса «исправлено». Он подтверждает, что уязвимость закрыта, и если ты найдёшь байпас, за него должны заплатить ещё раз, а в худшем случае начислят баллы. Важный нюанс: не пытайся обходить отчёт, который пока в статусе «принят». Вендор просто доисправит, и доказать уже ничего не выйдет. И не стоит цепляться за отличие в пару процентов, называя его самостоятельной находкой.

Bug bounty и закон: где граница легального поиска уязвимостей

Для легального поиска уязвимостей очень важно правовое основание. Искать их на сайтах, которые не участвуют в программах, а потом просить за это вознаграждение, опасно: на такие действия есть статьи закона. Для частного специалиста bug bounty и кибериспытания почти безальтернативный легальный способ показать экспертизу, другой вариант это договор ГПХ.

Если ты наткнулся на уязвимость в сервисе без программы, разумнее сообщить о ней и забыть, сделав сервис безопаснее. Был показательный случай: находку по захвату аккаунта на площадке отклонили как out-of-scope, но после обращения напрямую к разработчику софта за неё заплатили 50 тысяч рублей, больше, чем предлагали грейды программы. При этом давить на вендора ради наживы и тем более шантажировать недопустимо: это неэтично и непрофессионально.

AI в багхантинге: помогает разбираться, но не ищет уязвимости за тебя

AI вроде ChatGPT хорошо работает в багхантинге как справочник. Он объясняет сложные темы простым языком, подсказывает, как запустить инструмент вроде dirsearch, помогает написать скрипт или PoC. Для новичка это быстрый способ разобраться в теме вроде request smuggling, на которую раньше уходило три перечитывания статьи. Он же хорошо докручивает точечную задачу, когда ты дал конкретный вектор и ручку, а свои идеи закончились.

Автономно это не работает. Запрос «найди все уязвимости» выдаёт шум: на сервисе вроде hh.ru AI найдёт раскрытие данных на каждой ручке, хотя сам сервис построен на том, что эти данные видны. Половина работы и больше всё равно делается руками. Автономный режим ещё и опасен: AI способен сменить пароль так, что его не восстановить, положить сервис DoS-ом или выполнить деструктивное действие над другими пользователями, даже когда правила программы это запрещают.

Каждую находку AI стоит проверить руками: иногда штатным функционалом то же действие сделать нельзя.

Отдельная ловушка это отчёты, написанные нейросетью целиком. Лонгрид на четыре страницы на триаже вызывает подозрение и баннерную слепоту, а на просьбу показать скриншоты подтверждённой эксплуатации новичок несёт тот же чат, который и родил галлюцинацию. Так инструмент превращается в стеклянный потолок. Сильный хантер одновременно хороший триажер, а это понимание нарабатывается только через ручной разбор сервиса. В бизнес-логике AI пока слабее. Например, связка трёх легитимных функций позволила отправлять любой текст в SMS от имени сервиса любому пользователю на любой номер, и за такую находку заплатили очень хорошо.

OSINT, Google-дорки и докрутка, которые решают исход отчёта

Много находок в bug bounty приходит через OSINT (разведку по открытым источникам). Правильно составленный Google-дорк, захардкоженные ключи в проекте на GitHub, поддомены и упоминания в выдаче дают результат, если понимаешь, что именно ищешь. Бывает, что так находится даже собственный отчёт, который вендор по ошибке раскрыл из админки, и за это тоже платят.

Докрутка руками часто решает судьбу отчёта. Простой пример: ручка за basic auth, перебор дефолтных пар вроде admin/admin открыл админку, а более глубокий разбор показал ещё две учётки с совпадающими логином и паролем. Вендор хотел закрыть отчёт как дубликат: admin/admin уже нашёл внутренний аудит. Но дополнительных учёток в его задаче не было, и именно они позволили оспорить решение и получить выплату.

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

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

Спорные отчёты: как договориться с вендором

В отличие от проектного пентеста (тестирования на проникновение), в bug bounty уязвимость валидирует сам заказчик и обсуждает с хантером её критичность. Поэтому важно не только найти баг, но и правильно подать отчёт. Девяносто процентов вендоров и больше идут на контакт, спорные случаи в большинстве решаются прямо в переписке по отчёту. Если договориться не выходит, остаётся медиация площадки. Писать стоит максимально понятно. Был случай, когда хантер выделил цветом в Burp шесть уязвимых ручек, а триажер понял скриншоты иначе. После уточнения выплату пересчитали. Директивы занижать выплаты у вендоров нет, у них своё понимание бизнес-логики, поэтому диалог лучше вести экспертно и искать слабые места и в своей, и в чужой позиции.

Если не уверен, уязвимость это или нет, сдай отчёт и прямо напиши: если это не баг, я отзову. Вендоры почти всегда идут навстречу, когда отчёт написан по-человечески, а не нейросетью на четыре страницы. Отчёт, который точно не признают ни багом, ни информативом, разумнее отозвать. Удобно сразу предложить вендору выбор: поставить информатив или отозвать.

Как легально оформить доход от bug bounty и платить налоги

С деньгами всё несложно:

1. 1

   Оформляешь самозанятость, это занимает минут пять.

2. 2

   Выплата приходит в консоль площадки автоматически.

3. 3

   Подписываешь акты.

4. 4

   Платишь налог раз в месяц.

Если доход превысит 2,4 миллиона рублей, открывается ИП со ставкой около 8 процентов, где налоги считает банк. Работать как физлицо в этой схеме не нужно.