Как я перестал долбить сканерами и начал думать: мой путь в Bug Bounty

Я не начинал свой путь в Bug Bounty с мысли «хочу стать security researcher».

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

А потом был Bug Bounty.

Сначала я думал, что это что‑то вроде необычного фриланса: нашёл уязвимость, написал отчёт, получил результат. На практике оказалось, что между «я знаю, что такое SQL Injection» и «я самостоятельно нашёл SQL Injection в реальном приложении» лежит огромная пропасть.

В этой статье расскажу, как я её постепенно сокращал и почему в какой‑то момент перестал пытаться найти уязвимость напрямую.

Сначала был обычный курс по ИБ

Мой путь начался с курса по информационной безопасности.

Программа была довольно широкая: криптография, сети, TCP/IP, OSI, администрирование серверов, Docker, базы данных, веб‑приложения, Python, Bash, HTML/JS, OWASP Top 10, форензика и реверс‑инжиниринг. Информации было много. Настолько много, что с дедлайнами я справлялся далеко не идеально. В итоге практически всё пришлось сдавать в последней группе.

При этом сама техническая часть была интересной. Лучше всего мне заходили языки программирования, администрирование, базы данных, сети, веб и Docker. С реверсом было наоборот. Это оказался, пожалуй, самый тяжёлый для меня блок. Разбираться с бинарниками и пытаться понять происходящее на таком уровне было непросто. А вот форензика запомнилась совсем по другой причине. Например, работа с malware и его удалением была одной из тех вещей, которые действительно увлекали.

Но сам интерес к ИБ появился у меня ещё немного раньше.

От Python до пентеста

В какой‑то момент я смотрел видео про Python и наткнулся на материалы про пентест и машины на TryHackMe. Сначала это было просто любопытство, но постепенно я стал глубже разбираться в Linux, сетях и администрировании. И уже через это пришёл непосредственно к информационной безопасности.

В конце курса я впервые услышал термин Bug Bounty.

Первое впечатление было примерно таким:

«Можно искать уязвимости в реальных системах, соревноваться с другими исследователями и получать за это вознаграждение»

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

Первый заход в Bug Bounty

В голове была довольно простая схема:

найти программу → просканировать → найти уязвимость → отправить отчёт.

Проблема была в том, что реальный интернет совершенно не похож на учебную лабораторию. Вместо специально подготовленного приложения тебя встречают:

• WAF;

• rate limits;

• блокировки IP;

• сложные политики программ;

• scope;

• различные ограничения на тестирование;

• огромное количество уже исследованной поверхности.

И всё это нужно было ещё научиться понимать.

Первые два‑три месяца я в основном пытался применять знания с курса и то, что находил в интернете. Результат был довольно предсказуемым:

Практически ничего.

Сканеры должны были всё найти

На этом этапе я совершил классическую ошибку. Я слишком сильно полагался на автоматизацию.

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

Я мог запустить сканер и получить сотни интересных‑looking результатов. Но что дальше? Почему этот endpoint существует? Зачем ему этот параметр? Как он связан с остальным приложением? Какие права нужны для его вызова? Что произойдёт, если изменить последовательность действий?

На эти вопросы сканер ответа не давал. В какой‑то момент я просто перегорел.

Полгода вне Bug Bounty

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

Прошло примерно полгода. А потом я случайно наткнулся на статью, которая напомнила мне, что когда‑то я хотел заниматься этим всерьёз. Интерес вернулся. Но возвращался я уже немного другим человеком. На тот момент я ездил на работу примерно три часа в одну сторону. Шесть часов дороги каждый день. И значительную часть этого времени я начал проводить за чтением открытых отчётов HackerOne.

Это оказался один из самых полезных этапов моего обучения.

Hacktivity дал мне больше, чем очередной курс

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

Начинаешь обращать внимание на путь исследователя:

• что он заметил;

• почему выбрал именно эту точку;

• какие гипотезы проверял;

• что первоначально выглядело обычным;

• как появилась идея продолжить исследование;

• каким образом был доказан impact.

Для меня это было очень важным переходом. Я начал понимать, что между знанием OWASP Top 10 и реальным поиском уязвимостей есть ещё один навык.

Умение замечать то, что выбивается из нормы

Второй заход

В какой‑то момент я снова вернулся к Bug Bounty. На этот раз начал с VDP, где конкуренция обычно ниже. Правда, выбрал довольно популярную программу. И снова много работал. Иногда по десять часов в день.

Поначалу ощущения были знакомыми:

«Я опять ничего не понимаю».

Но затем, во время очередного монотонного тестирования и фаззинга, произошло то, ради чего вообще всё это затевалось.

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

Главное произошло внутри головы:

«Оказывается, я действительно могу это делать».

После первой находки отношение к процессу сильно меняется.

1000 сканеров или всё‑таки разум?

Самая очевидная вещь оказалась одновременно самой неприятной:

постоянное повторение одного и того же не делает тебя сильнее.

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

Сейчас основной инструмент для ручного тестирования у меня — Burp Suite. Но я не считаю необходимым запускать целую армию сканеров после каждого нового домена. Автоматизация полезна на первоначальном этапе, когда нужно быстро собрать информацию и сориентироваться.

Дальше начинается работа, которую за тебя никто не сделает.

Сначала нужно понять, во что ты играешь

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

В Bug Bounty я постепенно пришёл примерно к такому же подходу.

Когда открываю новую программу, сначала читаю policy. Смотрю ограничения. Понимаю допустимую частоту запросов. Разбираюсь с требованиями к тестированию. Потом начинаю изучать сам сервис.

Что это вообще такое? Для чего он используется? Какие есть домены? За что они отвечают? Какая функциональность доступна? Как разные части системы взаимодействуют между собой?

Это может показаться скучным этапом. Но именно здесь часто появляется информация, которой не даст никакой scanner.

Мне стало проще ломать то, что я понимаю

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

Ты примерно представляешь:

«Вот здесь пользователь должен иметь такие права»

«Вот здесь такой объект, скорее всего, связан с другим»

«А вот это поведение выглядит немного странно»

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

Главный навык — насмотренность

Если бы меня попросили назвать один навык, который сильнее всего влияет на Bug Bounty, я бы сказал:

насмотренность.

Она появляется только через практику. Самая сложная находка — первая. До неё ты просто не знаешь, как выглядит нормальное поведение реального приложения и где проходит граница между «так задумано» и «почему оно вообще так делает?». Со временем ты начинаешь узнавать знакомые паттерны, понимать, куда посмотреть, какие части запроса стоит изменить и быстрее замечать несоответствия. Просто мозг начинает накапливать библиотеку уже увиденных ситуаций.

Просто мозг начинает накапливать библиотеку уже увиденных ситуаций.

Где я сейчас?

Последний период у меня получился довольно интересным.

За полтора месяца я провёл больше 500 часов за работой. Сейчас решил немного притормозить. Занимаюсь Recon, немного ML и автоматизацией, делаю собственные проекты. Параллельно учусь в университете — сейчас я на первом курсе.

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

Вместо заключения

Если бы я мог вернуться к себе в первые месяцы Bug Bounty, я бы не дал себе список из двадцати инструментов. Не отправил бы изучать ещё сто payload'ов. И точно не сказал бы запустить ещё один scanner.

Я бы сказал:

Сначала пойми, что перед тобой.

Поиграй в эту «игру». Разберись, как она устроена. Посмотри, что является нормальным поведением. А потом ищи то, что в эту картину не вписывается.

Потому что в какой‑то момент я перестал искать конкретные уязвимости. Я начал искать аномалии. И именно тогда Bug Bounty для меня начал становиться по‑настоящему интересным.