Когда говорят про recon в Bug Bounty, обычно вспоминают subfinder, httpx, поиск директорий, JS-файлы и огромные списки URL. Всё это действительно используется. Но проблема в том, что сам по себе список из нескольких тысяч поддоменов почти ничего не даёт.
Главный вопрос начинается после сбора информации: что из этого действительно заслуживает внимания и почему?
Для меня recon — это не отдельный этап перед поиском уязвимостей.
Это постоянный процесс построения модели приложения: как оно устроено, какие сервисы существуют, зачем они нужны, как общаются между собой и где поведение системы отличается от ожидаемого.
1. Выбор программы — это тоже Recon
Я начинаю не с инструментов, а с самой программы. Сначала читаю policy: scope, выплаты, запрещённые действия, особенности тестирования и пожелания компании. Это позволяет не только не получить нарушение правил, но и понять, что именно компания считает важным.
При выборе программы я обычно смотрю сразу на несколько вещей:
-
насколько хорошо я понимаю сам сервис;
-
насколько активна программа и что находят другие исследователи;
-
какие там выплаты и насколько оправданы затраты времени;
-
что пишут исследователи о триаже и работе программы;
-
насколько сама компания и её инфраструктура мне интересны.
После этого смотрю на саму программу. Мне намного проще работать с сервисом, которым я уже пользовался или хотя бы хорошо понимаю его назначение. Если ты знаешь, как пользователь должен взаимодействовать с приложением, гораздо легче заметить момент, когда оно начинает вести себя не так, как должно.
Количество репортов тоже не стоит воспринимать буквально. Малое число багов не означает автоматически, что программа «пустая». Возможно, там жёсткий scope, сложный триаж или огромное количество исключений. И наоборот, популярная программа может быть интереснее именно потому, что её постоянно исследуют другие люди: по их находкам можно понять, какие части инфраструктуры вообще имеют смысл изучать.
Имеют значение также выплаты, отзывы исследователей и банальный интерес к самой компании. Нет большого смысла тратить двадцать часов на систему, если потенциальная отдача минимальна и при этом она тебе вообще неинтересна. Bug Bounty — достаточно длинная игра, поэтому мотивация тоже является частью выбора цели.
2. Recon — это не список поддоменов
После выбора программы начинается уже техническая часть. Автоматизация здесь нужна, но я не считаю, что recon заканчивается на subfinder и httpx. Получить список поддоменов сегодня несложно — проблема в том, что такой же список уже могли получить десятки или сотни исследователей.
При этом полностью отказываться от автоматизированного сбора информации тоже нельзя. Инфраструктура постоянно меняется: какие-то домены появляются, какие-то выключаются, старые сервисы снова становятся доступными.
Поэтому мне важна именно актуальная картина внешней инфраструктуры.
Я смотрю не только на результаты обычного subdomain discovery. Использую Censys, Shodan, Google и другие источники, чтобы понять:
-
какие домены и сервисы вообще существуют;
-
какие из них работают постоянно;
-
какие появляются или исчезают периодически;
-
как разные части инфраструктуры связаны между собой.
Например, периодически включающийся домен может заставить задать вопрос: почему он вообще существует и чем отличается от основной production-инфраструктуры? Иногда интересна и цепочка зависимостей: если один сервис перестаёт работать, не начнёт ли другой возвращать что-нибудь необычное?
После httpx начинается самая скучная, но одновременно самая полезная часть. Я отбрасываю очевидный мусор, уже известные директории и всякие стандартные ресурсы, а дальше отдельно смотрю на странные и новые ссылки.
Например:
Большинство просто пропустит такой PNG. Но у меня сразу появляется несколько вопросов:
почему
records? Что такоеalabam? Что изменится, если заменить5на4? Является лиrecordsкаким-то storage, почему файл находится именно здесь?
Важен не сам PNG — важна цепочка вопросов, которую он запускает.
3. Нужно понять архитектуру, а не просто найти endpoint
Когда я начинаю изучать приложение, мне интересна не только конкретная страница или API. Сначала пытаюсь понять общую картину: какие домены существуют, за что отвечает каждый сервис, как пользователь с ними взаимодействует и как сами сервисы взаимодействуют между собой.
Дальше я постепенно уменьшаю масштаб: от общей архитектуры к конкретному сервису, затем к API и отдельному endpoint. В этот момент постоянно возникает один вопрос: почему этот сервис вообще существует?
Например, есть сервис авторизации. Тогда интересно не только наличие /login, а то:
-
как он создаёт сессию
-
какие параметры передаёт дальше
-
какие данные добавляет в запросы
-
кому и чему он доверяет
-
можно ли повлиять на дальнейшее поведение через эти данные
Если есть сервис заказов — можно смотреть не только на его прямые права доступа, но и на то, что происходит, когда другой сервис взаимодействует с ним.
Получается примерно такая модель:
И дальше возникает уже более интересный вопрос:
кто здесь слабое звено?
Может оказаться, что напрямую обратиться к B нельзя, но A имеет к нему доступ и может передать туда данные. Тогда граница доверия между сервисами становится отдельной точкой исследования.
JS в этом процессе тоже полезен. Я смотрю клиентскую логику, нахожу API endpoints, дополнительные пути и параметры, а затем уже взаимодействую с ними напрямую. Иногда код помогает понять логику, но довольно часто именно непосредственное взаимодействие с endpoint показывает реальное поведение системы.
4. Ищи аномалии, а не названия уязвимостей. HackerOne Case
Одна из самых частых ошибок — увидеть знакомый паттерн и сразу назвать его уязвимостью.
Все начинается с непонятного endpoint или случайно найденного функционала. Именно того, что выбивается из общей нормальной картины.
Полный отчёт: #3578842 — SQL Injection vulnerability found on ibm.com endpoint
Во время recon я наткнулся на скрытый функционал, который вообще не был похож на обычную production-часть приложения.
Скорее он выглядел как какой-то старый тестовый или legacy-сервис. Начал смотреть, что там вообще есть и какие параметры принимает endpoint.
Один из GET-параметров показался интересным, поэтому решил просто покидать в него разные значения. В какой-то момент обычная кавычка начала стабильно приводить сервер к 500 Internal Server Error. Сам по себе 500, конечно, ещё ничего не значит, но стало понятно, что параметр как-то влияет на backend. Дальше уже появилась гипотеза про SQL Injection.
Запустил sqlmap — он подтвердил time-based SQLi. Но понятное дело, если запускать автоматизированную утилиту без специльного rate limit, delay, tamper scripts, то это это приведет только к потраченному времени, но об этом дальше.
Аномалия — это скорее сигнал: я сделал что-то, чего приложение, возможно, не ожидало. Дальше начинается проверка гипотезы разными схемами.
5. Насмотренность появляется не из чеклистов
Самый сильный буст в этом плане даёт первая настоящая находка. В лаборатории Burp Suite ты знаешь, что где-то существует уязвимость, и твоя задача — её найти. В реальном Bug Bounty ты можешь часами смотреть на систему и вообще не знать, есть ли там что-нибудь интересное.
Поэтому большое количество гипотез, которые никуда не приводят, — это нормальная часть процесса. Иногда 50–80% идей не развиваются в валидный баг. Но именно они постепенно учат не искать готовый ответ в интернете, а самостоятельно строить гипотезы:
-
изменить параметр
-
попробовать другой endpoint или HTTP-метод
-
связать два сервиса
-
проверить другое состояние приложения
-
посмотреть, что произойдёт при неожиданных входных данных
Со временем у конкретной программы появляется собственная «насмотренность».
Ты уже знаешь, как обычно ведёт себя её инфраструктура, какие ответы являются нормальными, где встречаются определённые паттерны. Поэтому через несколько недель может внезапно появиться несколько находок за пару дней — не обязательно потому, что «повезло«, а потому что ты накопил достаточно контекста, чтобы быстрее распознавать интересные ветки.
6. В Bug Bounty важнее Impact, чем название баги
Bug Bounty нельзя полностью приравнивать к пентесту. В пентесте ты можешь пройтись по определённой методологии и проверить конкретные классы уязвимостей. В Bug Bounty конечный вопрос немного другой: что опасного может сделать атакующий с помощью найденного поведения?
Одна проблема может пересекаться сразу с несколькими категориями уязвимостей. Но для триажа это не означает автоматически несколько отдельных находок. Важнее реальное влияние на безопасность компании.
Поэтому я стараюсь не начинать с вопроса «какая это уязвимость?». Сначала интереснее спросить:
Что изменилось в поведении системы и что это позволяет сделать?
Иногда первоначально слабая аномалия становится частью цепочки. Один endpoint позволяет получить данные, другой принимает их без достаточной проверки, третий выполняет действие с более высокими правами. По отдельности эти вещи могут выглядеть незначительно, а вместе уже давать совершенно другой результат.
Именно поэтому в Bug Bounty полезно не останавливаться на первом найденном поведении. Если оно действительно интересно, стоит попробовать понять, куда ещё оно ведёт и можно ли доказать реальный security impact.
7. Recon никогда не заканчивается
Я не воспринимаю recon как этап, который можно однажды закончить и поставить галочку.
Практически каждая новая находка, новый endpoint или изменение инфраструктуры создают новую информацию, которую потом можно использовать для следующего поиска.
Процесс получается примерно таким:
Поэтому на знакомую программу тоже приходится периодически возвращаться.
Инфраструктура меняется, сервисы включаются и выключаются, появляются новые endpoints, меняется логика приложения. То, что месяц назад выглядело бесполезным, сегодня может стать частью интересной цепочки.
В Bug Bounty ты постоянно пытаешься ответить на один вопрос: почему приложение ведёт себя именно так? Если на него получается ответить — дальше часто находится и то, что действительно стоит отправлять в репорт.
ссылка на оригинал статьи https://habr.com/ru/articles/1088328/