🔎 Перечисление поддоменов: как расширить поверхность атаки с помощью активных и пассивных методов

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

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

⭐️ Описанное ниже особенно полезно, когда в скоупе багбаунти-программы есть DNS-записи wildcard (*.domain.tld).

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

➡️ Пассивный сбор поддоменов: вы не взаимодействуете с целевым узлом и получаете информацию из открытых источников (DNS-записи, логи сертификатов SSL и TLS или веб-архивы).

Примеры используемых инструментов:

🟢 Censys, Shodan, SecurityTrails, DNSDumpster и другие онлайн-сервисы.

🟢 Инструменты вроде subfinder, amass или waybackurls, которые сами опросят множество публичных баз данных и выведут результат в удобном для вас формате (останется только добавить API-ключи):

$ subfinder -d example.com -oJ domains-example.com.json
или
$ amass enum -d example.com -o domains-amass.example.com.txt -timeout 12 -v

🟢 Google-дорки — это база:

site:*.example.com -site:www.example.com

➡️ Активный сбор поддоменов включает поиск любых поддоменов, которые не проиндексированы публично, но активно используются. Разберемся с ключевыми методами:

🟢 Брутфорс DNS — перебор поддоменов по словарю, который должен быть составлен отдельно исходя из полученных в ходе разведки данных. Про общедоступные словари тоже не стоит забывать (SecLists, fuzzdb, Assetnote Wordlists). Важно не останавливаться на доменах 3-го уровня, а искать дальше. В этом поможет инструмент mksub, с помощью которого можно сгенерировать дополнительные вариации поддоменов:

$ gobuster dns -d example.com -w wordlist.txt
$ mksub -d example.com -l 2 -w dns-wordlist.txt

🟢 Фаззинг виртуальных хостов (vhosts), которые имеют тот же IP-адрес, что и другой домен на веб-сервере. Полезные инструменты для работы — ffuf и wfuzz.

$ ffuf -c -r -u 'https://www.example.com/' -H 'Host: FUZZ.example.com' -w dns-wordlist.txt

🟢 Reverse DNS (rDNS): преобразует IP-адрес в связанное с ним доменное имя. Этот способ особенно полезен при исследовании диапазона целевых IP-адресов. На помощь придут инструменты Linux (dig, host) или общеизвестный dnsx.

$ dig -x 8.8.4.4 +short
$ cat ips.txt | dnsx -ptr -resp-only

➡️ Веб-краулинг с помощью Burp Suite или других инструментов: просто укажите кастомный скоуп, ходите по ссылкам и отслеживайте новые поддомены.

.*\.example\.com$

⭐️ Последняя задача — определить активные веб-узлы и избавиться от фолзов. Самый простой способ — использовать httpx или httprobe. Собираем поддомены в отдельный файл и выполняем:

$ cat domains.txt | httpx -o domains-webserver.txt 
или
$ cat domains.txt | httprobe >> domains-webserver.txt

💡 Хотите еще сильнее упростить себе жизнь? Используйте anew для добавления уникальных строк в файл из stdin. Инструмент выводит новые строки в stdout, что делает его немного похожим на команду tee -a.

P. S. При подготовке вдохновлялись статьей от багбаунти-площадки YesWeHack.

🚀 Простые, но действенные методы разведки для багхантера

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

Почему разведка важна? Дело в том, что каждое веб-приложение по-своему уникально, поэтому подход «в лоб» вряд ли сработает. Мы собрали несколько недооцененных методов, которые можно использовать прямо сейчас и получить профит. При подготовке поста частично использованы материалы статьи Intigriti.

1️⃣ Использование таргетированных словарей для брута неиспользуемых и скрытых хостов, эндпойнтов API, роутов приложения или входных параметров

Собирать словарь под проект может быть важно, потому что каждый разработчик пишет код и называет эндпойнты в своем стиле. У кого-то может быть /users, а у кого-то /show-all-users. Первый путь встретишь в любом словаре, а вот второй — нет. Однако он может встретиться в ходе разведки.

➡️ Алгоритм простой:

• Собираем все домены, пути и параметры с помощью любимых инструментов (katana, URLFinder, waybackurls, LinkFinder, gau) и/или Burp Suite, сохраняем в файл.

• Используем unfurl для парсинга уникальных ключевых данных из stdin:

$ cat urls.txt | unfurl paths
/users
/orgs
/about

• Анализируем результат и обогащаем другими данными.

💡 CeWL также поможет спарсить ключевые слова с целевого ресурса для составления кастомного словаря.

2️⃣ Фаззинг API с использованием различных методов HTTP

Некоторые приложения принимают только определенные HTTP-методы, да и описание API не всегда под рукой. Упростите себе жизнь с помощью следующей команды:

$ ffuf -u https://api.example.com/PATH -X METHOD -w /path/to/wordlist:PATH -w /path/to/http_methods:METHOD

3️⃣ Сканирование с различными заголовками User-Agent

При сканировании или перехвате запросов используйте User-Agent, специфичный для мобильных устройств, а также попытайтесь обнаружить различия в ответах сервера и скрытые фичи приложения. Настроить прокси в Burp сможет даже новичок. В качестве альтернативы можно использовать gospider:

gospider -s "https://app.example.com" -c 3 --depth 3 --no-redirect --user-agent "Mozilla/5.0 (iPhone; CPU iPhone OS 15_1_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 EdgiOS/46.3.30 Mobile/15E148 Safari/605.1.15" -0 mobile_endpoints. txt

4️⃣ Использование хешей фавиконов для поиска связанных активов

Если ваша цель — небольшая компания, у нее может не быть зарезервированного пула IP-адресов или она регулярно развертывает приложения в облачных сервисах. В этом случае мы все равно можем идентифицировать хосты, которые принадлежат цели, используя хеш фавикона:

• Получаем хеш из URL с помощью Favicon hash generator.

• Используем Shodan для поиска по хешу:

http.favicon.hash:<hash>

5️⃣ Поиск устаревших версий JavaScript-файлов

Анализируя интересный JS-файл, всегда просматривайте любые ранее заархивированные версии этого файла с помощью Wayback Machine или CLI-инструментов.

6️⃣ Мониторинг JavaScript-файлов

Если не хотите получить дубликат, отслеживайте изменения в JS-файлах и ищите баги в новом функционале первым. Вам помогут JSMon, Notify и другие инструменты.

7️⃣ Обнаружение скрытых параметров

Скрытые параметры могут позволить управлять поведением приложения и привести к успешной реализации различных сценариев атак. Для выполнения этой задачи помогут: Arjun, ParamSpider, Param-Miner, x8, ParamPamPam.

🤑 Эксплуатация IDOR через Path Traversal

Наткнулись на API-эндпойнт, как на первом скрине? Не проходите мимо: вполне вероятно, что перед вами IDOR.

Иногда вместо числового ID разработчики используют ключевые слова вроде me или current. API принимает оба варианта: и current, и 1234. Это делает IDOR-уязвимость менее заметной — но не менее опасной.

☑️ Что пробуем

1. Подставляем вместо current свой ID, например 1234.
2. Запрос проходит? Отлично.
3. Теперь вставляем ID другого пользователя.
4. Если эл. почта чужого аккаунта меняется — уязвимость подтверждена.

🧠 Более сложный пример

В больших проектах часто два API-сервера:
• фронтенд — для клиента;
• бэкенд — для внутренней логики.

Проблема в том, что права доступа проверяются только на фронтенде.

🚀 Подключаем Path Traversal

1. Отправляем /users/current/../1234/profile/email.
2. Фронтенд распознает current как ID пользователя и отправляет запрос на бэкенд.
3. Бэкенд получает путь /users/1234.
4. Проверки нет — можно менять чужие данные.

🎯 Что получаем

Возможность изменить эл. почту другого пользователя или получить доступ к его данным. Это полноценная IDOR-уязвимость, усиленная Path Traversal.

🧩 Вывод

Если API позволяет подставлять ID через ../, me, current (и т. п.) — это повод проверить на IDOR. Особенно если бэкенд не валидирует входные данные.