Перевод: Поиск уязвимостей P1: Инструменты и ресурсы
@Ent_TranslateIBВторая часть статьи "Поиск уязвимостей P1: Пошаговое руководство". В этой части более подробно рассказывается о том, что нужно делать на реальных этапах, а не о концепциях.
Я решил сделать еще одну часть в основном потому, что было несколько вопросов по первой статье, а также потому, что я хотел предоставить дополнительную информацию о лучших практиках и инструментах для использования на каждом этапе. Если вы еще этого не сделали, обязательно прочитайте первую статью →
https://medium.com/the-gray-area/finding-p1-vulnerabilities-a-step-by-step-guide-b88521195204
Это поможет вам понять некоторые шаги, на которые я ссылаюсь в этой статье, но это не обязательно.
Я предполагаю, что сейчас вы просто ищете шаги по тестированию сайта, который вы обнаружили и вы пришли в нужное место. Мы пропустим шаг 1, который заключался в определении того, хотите ли вы проводить ручное тестирование сайта, и выяснении того, может ли он быть уязвимым из-за устаревших библиотек или не реализованного принципа наименьших привилегий.
Шаг 2: Первоначальная разведка сайта и низкоуровневые уязвимости →
Именно здесь вы найдете уязвимости низкого уровня и сможете глубже изучить определенные аспекты сайтов, такие уязвимости, как многофакторная аутентификация, открытое перенаправление и тому подобное. Вот несколько инструментов, которые можно использовать -
https://github.com/projectdiscovery/nuclei
Это несколько отличных ресурсов, которые можно использовать для поиска низкоуровневых, более простых ошибок. Эти ошибки могут быть P5 (информационные) или P4 (низкие). За P5 обычно не полагается денежное вознаграждение, но вы все равно сможете получить за это признание. Вы будете сканировать поддомены с помощью Gau, а затем использовать некоторые шаблоны nuclei (которые есть на Github, так как люди обычно разрабатывают свои собственные) для проверки этих поддоменов на наличие уязвимостей или конфиденциальной информации. Запишите, если вы нашли что-то на этом шаге, так как конфиденциальная информация может позволить нам тестировать дальше.
Шаг 3: if (уязвимость || секретные данные == true) {dig deeper = true} else {step4()}→.
Если вы нашли что-то на предыдущем шаге, воспользуйтесь этим здесь. Именно здесь вы будете проводить настоящее тестирование. Глубокое сканирование и ручные проверки являются здесь ключевыми, и вам придется потрудиться, если вы хотите получить вознаграждение. Профессиональным хакерам требуются дни, а иногда и недели, чтобы найти качественные уязвимости P1. Вы наверняка захотите использовать некоторые из приведенных ниже инструментов:
https://github.com/SNGWN/Burp-Suite
https://github.com/gzemel/WebHeckScanner
Эти два способа будут наиболее полезны для автоматизации, но ключевым моментом здесь является ручное тестирование сайта. Выполняются ли небезопасные запросы? Есть ли возможные уязвимости формы входа? Есть ли у вас больше доступа или информации, чем нужно обычному аутентифицированному клиенту? Все эти вопросы необходимо задать при ручном тестировании. Полезно воспользоваться программой Burpsuite, которая сканирует каждый отправляемый вами запрос в браузере (если используется прокси-сервер), а также он автоматически обнаружит уязвимости в конкретном запросе или сайте.
Шаг 4: Прибыль $$$ →
Это важный шаг, поэтому не пропускайте его. Если вы уже нашли уязвимость - отлично. Вы уже использовали эту уязвимость? Еще лучше. Однако не останавливайтесь на достигнутом и просто отправьте найденную уязвимость P3 или P2, или даже P1. Проведите больше тестирований, перепроверьте свои ручные запросы и посмотрите, нет ли еще чего-нибудь, что вы могли бы использовать для создания цепочки уязвимостей.
Объединение ошибок вместе может создать еще более опасный эксплойт, который может принести более высокую награду. Для этого не существует инструмента, поскольку все проверяется вручную, и ни один из инструментов, которые я нашел, не будет сканировать каждый запрос и устанавливать связи между уязвимостями. Однако я приложил несколько полезных статей о цепочке уязвимостей:
https://blog.orange.tw/2018/08/how-i-chained-4-bugs-features-into-rce-on-amazon.html
https://www.techwell.com/techwell-insights/2013/01/what-bug-chaining
Если вы уверены, что нашли все возможное в приложении или на сайте, вот шаблон для отчета об ошибке от HackerOne (который я немного изменил).
## Название:
[Название ошибки, т.е. "[тип ошибки] на [домен], приводящий к [перечислить возможные последствия]]]
## Резюме:
[добавить краткое описание уязвимости, чем она может навредить компании/веб-сайту/приложению].
## Шаги по воспроизведению:
[добавьте детали того, как другие могут воспроизвести проблему. Чем лучше вы это сделаете, тем быстрее вы сможете получить награду, и это свидетельствует о профессионализме].
1. [добавьте шаг]
2. [добавьте шаг]
3. [добавьте шаг]
## Вспомогательный материал/Ссылки:
[перечислить любые дополнительные материалы (например, скриншоты, журналы, запросы/ответы Burpsuite и т.д.)]
* [вложение / ссылка]
##IP-адрес:
[IP-адрес для идентификации вашего трафика]
##Временная метка:
[Дата и время тестирования]
Используйте этот шаблон для отправки уязвимостей, и вас будут уважать проверяющие этой программы, и, возможно, вы получите большие деньги за свои находки.
Спасибо, что прочитали о некоторых инструментах и ресурсах, и я надеюсь, что вы смогли чему-то научиться и/или воспользоваться одним из них. Если вы любите информатику или хакерство, посмотрите другие посты из The Gray Area. Если вы еще не являетесь пользователем Medium и хотите поддержать меня, не стесняйтесь зарегистрироваться, воспользовавшись моим рефералом. Спасибо!
https://grahamzemel.medium.com/membership
Оригинал статьи - здесь.
Поддержите автора хлопками на Medium.
Перевод статьи был выполнен проектом перевод энтузиаста:
- 📚 @Ent_TranslateIB - Телеграмм канал с тематикой информационной безопасности
- 🔥 @Ent_Translate - Инстаграм проекта