[HaHacking] BugBounty: Пережить сезон охоты

[HaHacking] BugBounty: Пережить сезон охоты

HaHacking
🪲

Участие в Standoff Hacks подарило мне возможность попробовать себя в багхантинге в рамках программ багбаунти. Я не в первый раз берусь за анализ защищённости веб-приложений, но практически впервые занимаюсь этим как независимый исследователь: без команды и чёткого плана, так ещё и впопыхах. Скоуп – сюрприз, и, встретившись с ним, легко растеряться.

Выделила для себя некоторые пункты, которые помогали мне находить баги, не впадая в отчаяние и не особо посыпая голову пеплом, и описала их в этой небольшой статье;


📎 Содержание

1. Помните про инструменты
2. Изучайте структуру
3. Отмечайте функциональность
4. Оставляйте заметки
5. Делайте шаг назад
0. Продолжайте жить

🧰 Помните про инструменты

Да, большинство уязвимостей получится найти, подтвердить и раскрутить исключительно вручную. И всё-таки для первоначального анализа и для того, чтобы нащупать аномалии (🔗 – доклад про систематизацию с помощью аномалий на Standoff Talks), могут быть полезны и инструменты. Они, если и не явным образом укажут на наличие уязвимости, то хотя бы зададут направление для дальнейшего изучения приложения. Анализ и эксплуатация находок в любом случае останется за исследователем ;)

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

Энумерация 🔍

  • Поиск поддоменов: Видим вайлдкард – скоуп со звёздочкой – запускаем поиск поддоменов. Помимо всем известных Sublist3r и Amass хочется упомянуть мой любимый инструмент для поиска поддоменов – Lepus, который умеет генерировать дополнительные проверки на существование поддоменов методом перестановки + с помощью цепей Маркова.
  • Доркинг: Формирование специальных запросов к поисковым системам на случай, если они успели проиндексировать что-нибудь занимательное, вроде административных панелей, конфигурационных файлов или бекапов. Список примеров таких запросов доступен и периодически обновляется на сайте Exploit DB. Описала перечень инструментов, автоматизирующих процесс доркинга тут, но, если кратко, среди всех выделила Fast-Google-Dorks-Scan, sitedorks, pagodo и подборку запросов google-dorks.
  • Перебор путей: Обращение к путям веб-приложения для нахождения тех, что в той или иной мере доступны внешнему пользователю. Тут каждому своё: ffuf, wfuzz, gobuster, Burp Intruder, ...; Ну а мне тепло полюбился feroxbuster – за красоту и гибкость.
  • Перебор параметров: Перебор параметров для выявления неочевидной функциональности или проверки уязвимости приложения к Mass Assignment. Можно осуществить как с помощью инструментов, перечисленных в секции инструментов для перебора путей, так и с помощью непревзойдённого в этом деле x8.
  • Сканирование: Сюда включаю все инструменты, рассчитанные на первичное сканирование цели. Главный среди них – Nuclei, осуществляющий сканирование по шаблонам. Примечательно, что Github переполнен всевозможными шаблонами для Nuclei и, следовательно, каждый сможет найти шаблон под свои нужды. А если и не найдёт – оказалось, что уже придумали инструмент на основе ИИ для генерации шаблонов Nuclei – Nuclei AI.
  • Комбайны: Существуют инструменты, вобравшие в себя все вышеперечисленные пункты с целью проводить энумерацию красиво и централизовано. Примеры: Rengine, reconFTW и scan4all.

Плагины для Burp Suite 😮‍💨

В выборе расширений для Burp Suite стоит отталкиваться от конкретных условий задачи и специфики веб-приложения. Малый список тех плагинов, которые вероятнее всего будут полезны:

  1. Active Scan++ – плагин, обеспечивающий большее число активных и пассивных проверок при запуске активного сканирования цели: отслеживание трансформации ввода, слепые инъекции кода, атаки на заголовок запроса Host, ...; С ним стоит быть аккуратным, как и с любым активным сканером.
  2. Burp Bounty – тот самый комбайн, да ещё и специально для багбаунтеров, но внутри Burp Suite. Ещё более активный плагин, чем Active Scan++, со своей отдельной вкладкой, пассивным и активным сканированием и возможностью прогонять проверки над конкретным запросом или запросами. Разнообразие проверок – колоссальное, причём каждая функция проверки соотносится с конкретным типом атаки и потому интуитивно ясна благодаря названию.
  3. Autorize – расширение для проверки нарушений логики разграничения прав. Повторяет перехваченные запросы с заменой заголовков, отвечающих за авторизацию (заменяемые значения устанавливаются вручную пользователем) и сравнивает ответы приложения на оригинальный, модифицированный и неавторизованный запрос.
  4. Param Miner – инструмент для перебора параметров прямо внутри Burp Suite.
  5. 403 Bypasser – плагин для автоматизации обхода ошибки 403 Forbidden. Аналогичные инструменты за пределами Burp Suite: Bypass-403 и Bypass URL Parser.
  6. Hackvector – навороченный Burp Decoder. Увеличенное число функций для обработки данных, включая даже всякие математические и криптографические. Может быть дополнен и использован, например, для декодирования параметра PaReq в ходе анализа механизма онлайн-платежей, который задействует протокол 3-D Secure. Вызов функций происходит через оборачивание строк в XML-подобные теги с возможностью вложения одного тега в другой.

Словари 📖

🧱 Изучайте структуру

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

Так, например:

// Прим: Понимание → Выгода из понимания;

+ Технологический стек → Потенциальные CVE, особенности взаимодействия, существующие пути;

+ Решение WAF → Известные методы обхода этого конкретного WAF;

+ Структура ролевой модели → Задуманное разграничение доступов, особая функциональность;

+ Стиль наименования методов / параметров / пользователей / ... → Определённый формат для перебора;

+ Вид идентификаторов → Технологический стек, предсказуемость, перебираемость;

+ ...
Структуризация откроет дверь в мир уязвимостей, которые основаны на взаимодействии компонентов и комбинации особенностей поведения.

+ Эти знания помогут качественнее гуглить! В частности, поиск векторов можно начать со специальных сборников:

⚙️ Отмечайте функциональность

Подмечайте для себя ту функциональность, которую стоит проанализировать в первую очередь. Выделяю 4 категории, стоящие пристального внимания: любимая / старая / новая / закрытая функциональность;

1) Любимая функциональность

Любимая функциональность – всё то, что вам интереснее или проще всего анализировать.

Кто-то первым делом прощупывает Client-Side, а кто-то – логику и ролевую модель. Здесь всё зависит от личных предпочтений и опыта, нужно лишь найти и отметить подходящую под Ваш запрос функциональность.


2) Старая функциональность

Старая функциональность – то, что существует давно и уже было протестировано ранее.

Анализ такой функциональности – это, по большей части, предварительное скрупулёзное изучение опыта прошлых лет: раскрытых отчётов, журнала изменений, новостей об исследуемой компании, связанных с безопасностью, и, конечно, утечек.

Благодаря описанному анализу выясняется:

- Тенденции к уязвимостям: Какие уязвимости склонны допускать разработчики данного приложения?

- Уязвимые места: Какой тип функциональности оказывался наиболее подвержен атакам?

- Возможность обойти заплатки: Качественно ли были устранены уязвимости?

- Информация о технологическом стеке: Какие СУБД использовались (например, исходя из отчётов об SQLi)? Какие шаблонизаторы использовались (например, исходя из отчётов об SSTI)? ...

- Информация о пользователях (+ корпоративных): Какие пользователи существуют в приложении? Какой формат имён пользователей / паролей?

- Модель рисков: Отчёты о каких уязвимостях были (/не) приняты и (/не) вознаграждены?

3) Новая функциональность

Новая функциональность – то, что ещё совсем свежее.

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

– Нововведения: Какая функциональность ещё не успела подвергнуться внешнему анализу? Как эта функциональность связана с / влияет на старую функциональность?

– Обещанные функции: Присутствуют ли задатки функции в текущей версии приложения? Возможно ли получить доступ к обещанной функции (подача заявки, прямое обращение к эндпоинту, ...)?

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


4) Закрытая функциональность

Закрытая функциональность – та, для получения доступа к которой необходимо, образно говоря, "переступить порог".

Это функциональность, доступ к которой предполагает выполнение ряда действий с деньгами, документами или реальными людьми (не социальная инженерия!!), и потому это – непаханое поле для поиска уязвимостей для тех, кто готов рисковать.

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

📝 Оставляйте заметки

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

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

📐 Делайте шаг назад

После очередной "поставленной точки" – делайте условный "шаг назад", чтобы осмотреться и подумать. Под этим я подразумеваю оценку текущего этапа, имеющихся зацепок и заветных находок:

  • Оцените, какие тесты Вы провели и какой объём функциональности был Вами протестирован. Отметьте плодотворность деятельности и направление, куда хотели бы двигаться в следующую очередь.
  • Распишите, проговорите вслух или обдумайте имеющиеся находки, даже если не собираетесь писать отчёт. Как минимум, это поможет со структуризацией, оценкой импакта или разработкой вектора.
  • Если начали писать отчёт, задумайтесь о вечном: борьбе бизнеса и технарей. Оправдывает ли цель (устранение уязвимости) средства (деньги и человеко-часы, которые бизнес потратит на устранение уязвимости)? К большому сожалению, далеко не каждая уязвимость будет устранена по причине этой самой неоправданности. Докажите себе и им, что уязвимость того стоит.

🧠 Продолжайте жить

Вне зависимости от результатов: позволяйте себе отвлекаться и отдыхать, вкусно кушайте и stay hydrated. Живите дальше и не загоняйтесь по пустякам. Вон лучше, посмотрите злободневное видео и поулыбайтесь:

🔞 Источник: t.me/memekatz/7
Report content on this page

Report Page

Please submit your DMCA takedown request to dmca@telegram.org