Рекон как помощник багхантера в поиске скрытых активов

Наверняка вы замечали, что одни багхантеры находят уязвимости одну за другой, а многим это дается с бо́льшим (или даже больши́м) трудом. Хусейн Дахер, известный под ником hussein98d, считает, что дело не в технических навыках. Все решает рекон.

Хусейн Дахер — основатель и CEO компании Web Immunify, родом из Ливана. В багбаунти он больше десяти лет: за это время он нашел и зарепортил более тысячи уязвимостей на разных платформах. Хусейн также входит в топ исследователей на площадке Standoff Bug Bounty.

Один из самых громких результатов — первое место в программе Fidelity National Information Services меньше чем за полгода. Сам Хусейн объясняет это не удачей, а умением находить активы, до которых не добираются другие. С ним можно связаться на webimmunify.com и daherhussein.com.

В этой статье мы расскажем четыре реальные истории из его практики, когда Хусейну удавалось находить уязвимости там, где, казалось бы, уже все исследовано вдоль и поперек. В одной из них «мертвый» IP-адрес, который все обходили стороной, оказался приложением с захватом аккаунта в один клик. В другой старая сборка Android-приложения отдала ключи ко всей инфраструктуре компании. А еще был домен, который находился только через одну поисковую систему, и открыл доступ к базе данных. Чтобы подробнее разобрать каждый кейс - читайте дальше!

Статья носит исключительно информационный характер и не является инструкцией или призывом к совершению противоправных действий. Ее цель — исключительно образовательная: рассказать о существующих уязвимостях, которыми могут воспользоваться злоумышленники, предостеречь пользователей и дать рекомендации по защите. Автор не несет ответственности за неправомерное использование опубликованной информации.

Почему одного списка поддоменов бывает недостаточно

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

Хусейн Дахер считает, что дело не только в технических навыках, но и в выборе цели. Можно отлично разбираться в уязвимостях и потратить несколько дней на актив, который до тебя проверили десятки исследователей. Глубокий рекон помогает расширить карту разрешенного периметра и найти части инфраструктуры, которым уделяли меньше внимания. Для каждого найденного актива нужно задать только один вопрос: находил ли это кто-нибудь раньше? Если ответ отрицательный, шансы найти уязвимость заметно повышаются.

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

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

Дело техники

Рекон начинается с набора базовых техник. Мы пройдемся по ним еще раз, чтобы освежить материал для начинающих и не очень исследователей.

Перечисление поддоменов

Перечисление поддоменов — это первый слой, на котором большинство и останавливается. Один запуск Subfinder дает тот же список, что и у всех. Хусейн советует использовать два-три инструмента и не забывать про BBOT: по его опыту, тот вытаскивает на 25–50% больше поддоменов.

Причем глубина здесь важнее ширины, то есть количества. Намного выгоднее рекурсивно брутфорсить поддомены, погружаясь все дальше внутрь сети. Большинство инструментов находят поддомены второго уровня, то есть что-то.domain.com, и дальше почти никто не идет. Хусейн советует копать до третьего и четвертого уровня, искать хосты вида dev.admin.domain.com. Именно там часто находится поверхность атаки с минимальной конкуренцией.

Поиск виртуальных хостов

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

Намного выигрышнее брать сырые IP-адреса из ASN и брутфорсить заголовки Host. Поддомены из списка проверяются по каждому IP-адресу. Для этого подойдут ffuf, Burp Suite Intruder или похожие инструменты. Правильный Host на правильном IP-адресе — это приложение, которое обычно не видно из интернета напрямую. Эту технику можно использовать и для поиска реального IP-адреса приложения за Cloudflare, Akamai или другим WAF.

Важно помнить: сброс соединения не означает, что хост «мертв». Причина может быть в файрволах, прокси-настройках или отсутствующем заголовке Host. И такое действительно не редкость, когда исследователь находит правильный заголовок, отправляет запрос и попадает в приложение, до которого раньше никто не добирался.

Картирование ASN

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

Схема, по которой работает Хусейн, выглядит так:

• он получает информацию о том, какие диапазоны IP-адресов принадлежат организации, то есть BGP-данные;

• затем выводит все IP-адреса внутри этих диапазонов через prips;

• после этого запускает ffuf в режиме поиска виртуальных хостов по всем адресам.

Один ASN может превратиться в тысячи IP-адресов и сотни нетронутых виртуальных хостов. Bing тоже помогает: в нем есть поиск по IP-адресу с помощью оператора ip:. Google такого не умеет. Еще один полезный прием — сверка диапазонов через Shodan с использованием SSL-запросов по названию организации. Это может показать IP-адреса без публичных имен хостов.

Словарь под конкретную цель

Четвертая техника — создание словаря под конкретную цель. Универсальные словари находят универсальные пути. Если два исследователя используют один и тот же список, они приходят к одним и тем же результатам.

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

Для сбора данных подойдут Katana, Wayback Machine и gau. Они помогают автоматически обойти страницы сайта и собрать все найденные ссылки. Затем данные разбиваются на отдельные слова:

• список делится по строкам и специальным символам;

• результат сортируется и очищается от дубликатов;

• остаются только уникальные значения.

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

Доркинг в разных поисковых системах

Доркинг хорошо дополняет остальные способы рекона. Запросы с операторами site, intitle и inurl помогают обнаруживать старые страницы, документы и поддомены. Такие находки часто не попадают в список активов, который собрали другими инструментами.

Выдача сильно зависит от поисковой системы. Страница может отсутствовать в Google, но при этом сохраниться в индексе Bing, Yahoo, DuckDuckGo или Yandex. Поэтому один и тот же набор запросов имеет смысл повторить в нескольких поисковиках и сравнить результаты.

У Bing есть свои особенности работы с операторами. Например, запрос site:*.atlassian. может показать страницы сразу на atlassian.net, atlassian.io и atlassian.dev. Иногда помогают поиск по IP-адресу и запросы с inbody:login. Перед дальнейшей проверкой найденный ресурс нужно сверить со скоупом программы.

Массовое тестирование без дубликатов

Вручную открыть сто или тысячу поддоменов невозможно, но и спамить nuclei бессмысленно: получишь те же дубликаты, что и все. Хусейн передает все активы — поддомены, IP-адреса, виртуальные хосты — в Burp Suite Intruder с одним payload и смотрит различия визуально.

Ответы можно сортировать по статус-коду, длине и количеству строк. Так намного проще видеть различия между большим количеством активов. Одна ошибка конфигурации Apache раскрыла Хусейну внутренние SSH-баннеры. Главный вопрос звучит так: что вы делаете иначе, чего не делают остальные сто багхантеров?

Майнинг и брутфорс параметров

Страница кажется тупиком только до тех пор, пока не обнаружены скрытые параметры. Для поиска подойдут Arjun и Param Miner — их лучше запускать оба, потому что находят они разное.

Когда параметры найдены, стоит проверить, принимает ли приложение XML. Иногда достаточно заменить JSON на XML и поменять Content-Type. Многие приложения это распарсят, и именно там находится XXE. Все тестируют видимые параметры, а скрытые остаются без внимания. На активах, обнаруженных в ходе глубокой разведки, стоит заново проводить полное тестирование. Лучшие баги часто находятся там, где никто не ждет немедленного ответа.

Рекон по фавиконам

Компании часто используют один и тот же фавикон (теперь вы знаете, как называется иконка на вкладке браузера!) на поддоменах и связанных хостах. Хусейн применяет для этого платформу Profundis. Она находит уникальные хеши фавиконов и сравнивает иконки визуально, а не только по точному хешу.

Такой подход полезен и для рекона, и для анализа. Хеш в Profundis — собственный визуальный хеш, а не mmh3 из Shodan, который в нашем случае ничего не вернет.

Reverse DNS по всему ASN

Reverse DNS, пожалуй, последний слой, о котором стоит помнить. Исследователь уже вывел все IP-адреса в диапазоне организации, теперь нужно сделать PTR-запрос по каждому, то есть сопоставить их IP-адреса с именем хоста в обратной зоне DNS. Эти имена могут раскрыть хосты, которые никогда не публиковались в прямой зоне.

Работа с обратной зоной DNS включает несколько шагов. Сначала берутся размеченные IP-адреса из ASN, затем по каждому адресу выполняются PTR-запросы через prips и dnsx. В результате для каждого адреса получается reverse IP hostname.

Так можно найти скрытые имена и имена внутренних хостов. Имена вроде bastion, vpn или jenkins часто оказываются очень интересными для проверки. У некоторых IP-адресов есть PTR-запись, но нет прямой A-записи. Обычное перечисление через прямые DNS-запросы их никогда не увидит. Reverse DNS — единственный способ до них добраться. Каждое найденное имя также нужно добавлять в словарь и использовать для брутфорса виртуальных хостов.

Реальные кейсы

Техники хороши сами по себе, но лучше всего раскрываются на практике. Хусейн разбирает четыре кейса из своей работы, и каждая история показывает, как в ходе рекона одна находка цепляется за другую, пока не складывается цепочка атаки.

Кейс 1. «Мертвый» IP-адрес и скрытое приложение

Первый кейс можно описать как путь от «мертвого» IP-адреса к скрытому приложению. В программе с большим периметром он картировал ASN и проверял каждый IP-адрес. Все они входили в программу, так что тестирование было разрешено ее правилами.

Большинство пропускают адреса, которые сбрасывают соединение, — в браузере такой IP-адрес просто не работает, и его помечают как неактивный. Однако сброс соединения обычно говорит о наличии фильтра, а не о пустом сервере. То есть сам хост существует, просто запрос идет без нужного заголовка и сбрасывается. Что, если пойти дальше и попробовать перебрать поддомены организации через заголовок Host на этом адресе?

Для этого подойдут такие инструменты, как ffuf или Burp Suite Intruder. В общем виде атака выглядит так: исследователь передает словарь поддоменов и IP-адрес и указывает, что фаззить нужно значение внутри заголовка Host. Валидные хосты возвращают настоящие ответы, невалидные уходят в тайм-аут — полезный сигнал заметен сразу.

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

Верность этого подхода Хусейн подтвердил на практике, когда нашел в сети одной компании несколько тщательно скрытых поддоменов и IP-адресов, которые не отвечали напрямую. Когда он указал найденный брутфорсом заголовок Host, оказалось, что через перенаправление пользователей (open redirect) можно захватывать аккаунты одной ссылкой. В результате уязвимость получила высокий уровень опасности, а исследователь заработал 1200 $.

Кейс 2. Старая сборка приложения и утекшие учетные данные

Второй кейс связан со старой сборкой приложения и утекшими учетными данными. Иногда при исследовании организации находится API-поддомен, который отдает APK-файлы. Такие файлы также встречаются в Google Play и на других маркетплейсах. В одном случае рекурсивное перечисление поддоменов обнаружило хост вида api.target.com, который разрешено было тестировать в рамках программы багбаунти.

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

Обычно там можно найти разные секреты, например данные о скрытых внутренних доменах, поддоменах или IP-адресах. Этот хост появился только после брутфорса поддоменов. Именно на третьем уровне часто скрываются тихие, малозаметные активы. Хусейн вставил заголовок страницы в Google и Bing и нашел то же приложение на другом поддомене, но с более старой датой.

Конкретный пример связан с находкой APK-сборки одного приложения. Исследователь извлек ее содержимое и обнаружил файлы properties, через которые удалось получить доступ к ключам Okta и SMS. Это привело к полному захвату аккаунта без какого-либо взаимодействия с пользователем.

Кейс 3. Сто тысяч доменов и удаленный доступ

Следующий кейс стал результатом участия в программе Fidelity National Information Services на Bugcrowd. Одна из попыток поиска домена по данным владельца в сети (известна также под названием Reversed Whois lookup) организации вернула около ста тысяч доменов — проверять такой объем вручную невозможно, что и отпугнуло большинство других исследователей. А значит, поверхность атаки осталась почти без конкуренции — тем более что процесс можно автоматизировать.

Однако нет готового дорк-инструмента, который нормально обработает сто тысяч запросов. Мешают капчи, rate limit и другие ограничения, поэтому пришлось потратить время и написать собственный инструмент для доркинга с обходом этих ограничений.

Когда все было готово, он взял полный список доменных имен и запустил по ним доркинг, а затем использовал перестановки с терминами вроде login, signup, upload и admin. Когда появлялись результаты, он отправлял их обратно в Katana и повторял цикл, пока поверхность атаки увеличивалась.

Один из дорков через Bing привел к файлу documentation/branch-archive.zip. Вскрытие Распаковка показала, что внутри находится MSI-установщик для Windows. После его запуска и декомпиляции удалось получить часть исходного кода из библиотеки DLL.

Внутри оказались учетные данные client_upload_svc и localhost-эндпойнты ASMX. Путь к веб-сервису и утекшие данные Хусейн перебрал по всем хостам, пока не нашёл тот, который ответил. Усилия не оказались напрасными — в итоге нашелся конкретный домен, который принимал запросы к веб-сервису.

Так учетные данные client_approved_svc позволили получить данные компании — фактически это был удаленный доступ, к которому привел ZIP-файл, найденный через дорк. Иными словами, разрушительный потенциал этой уязвимости почти такой же, как у RCE.

Кейс 4. Домен, известный только Bing, и SQL-инъекция

Четвертый кейс — разрыв между поисковыми системами и SQL-инъекция. Все началось с домена, который входил в скоуп программы и был разрешен к тестированию. О нем знал только поисковик Bing, а Хусейн считает себя фанатом доркинга именно в нем. Там можно использовать дорк с копирайтом организации и годом в кавычках.

Так было найдено новое приложение, о котором не знали другие багхантеры. Дальше возник вопрос: какой самый простой и слабый input стоит проверить первым? Разные поисковые системы индексируют разные участки интернета. Никем не тестируемый домен — это тот, о котором знает только один поисковик.

Оказалось, что в этом приложении никто не проверил куки. Обычный тест на задержку ответа сервера заставил базу данных «заснуть», что подтвердило временную SQL-инъекцию. А если WAF блокирует инъекцию, можно запускать sqlmap с tamper-скриптами и другими обходами.

Таким образом, домен, который был проиндексирован только одной поисковой системой, превратился в доступ к базе данных.

Заключение

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

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

Несколько выводов из опыта Хусейна:

• поверхность атаки часто появляется не сразу, а только на третьем и следующих циклах рекона;

• результаты рекона лучше сохранять и регулярно сравнивать;

• помните, что connection reset не означает, что хост «мертв»;

• идите туда, куда не доходит краулер: в Bing, Yandex, cookie, старые версии Android-приложения;

• полезная информация может находиться в документации, PDF-файлах и страницах, которые пропускают краулеры;

• критически опасные уязвимости обычно обнаруживаются на том активе, который до вас никто не находил.

Проще говоря — запускайте, повторяйте, краульте, фаззьте и снова краульте!