Amazon S3 остается одним из самых популярных и широко используемых сервисов для хранения объектов в облаке. Каждый день миллионы компаний и пользователей загружают файлы в бакеты S3, которые часто становятся целью исследований безопасности, пентестов и баг-баунти программ. Обнаружение существующих бакетов может помочь специалистам выявить недочеты в конфигурации, найти уязвимости или просто уточнить инфраструктуру цели. Традиционно для поиска бакетов использовался метод перебора с помощью HTTP-запросов, который, несмотря на свою простоту, оказывается очень медленным. В чем же причина и как можно значительно ускорить этот процесс? Открывается совершенно новая перспектива благодаря использованию возможностей DNS-протокола и хитрым приемам с анализом CNAME-записей, связанных с регионом размещения бакета.
Проблемы традиционного метода обнаружения Обычно для обнаружения S3-бакета постучаться по HTTP-эндпоинту вида s3.amazonaws.com/<имя_бакета> и посмотреть, какой статус вернёт сервер: существует ли такой бакет. Но HTTP работает поверх TCP — это означает, что для каждого запроса происходит трехстороннее рукопожатие TCP, что затягивает время выполнения. Даже при быстрых интернет-каналах и современном оборудовании этот подход сильно ограничен скоростью обработки запросов.
По оценкам, используя популярные инструменты типа ffuf, можно обработать порядка 50 000 запросов за 18 секунд, а это примерно 2800 запросов в секунду — неплохо, но для масштабной разведки этого может быть мало. Преимущества DNS-запросов для обнаружения DNS работает поверх UDP — это протокол без установления соединения. Благодаря этому можно отправлять миллионные потоки запросов практически без задержек, не дожидаясь подтверждения от сервера. Этот нюанс существенно увеличивает пропускную способность и снижает нагрузку. На практике специализированные утилиты, например pugdns, способны обрабатывать около 180 000 запросов в секунду, что в десятки раз быстрее традиционного HTTP-подхода.
Ускорение не в два-три раза, а больше чем в 60 раз – результат впечатляющий. Почему нельзя просто проверять через DNS существование бакета по его имени На первый взгляд логично просто сделать DNS-запрос к имени bucketname.s3.amazonaws.com, и если в ответ возвращается адрес, то бакет существует, а если нет – нет.
Однако в случае с Amazon S3 ситуация иная. AWS отвечает кодом NOERROR на большинство DNS-запросов, вне зависимости от того, существует бакет или нет. Это можно проверить примером для реально существующего бакета и случайного выдуманного: оба возвращают NOERROR, а значит обычный аналог HTTP-статуса в DNS не действует. При таком раскладе нужно искать иной способ получения информации о существовании. Трюк с регионально специфическими CNAME-записями Интересная особенность заключается в том, что большинство бакетов, размещенных в регионах кроме стандартного us-east-1, отвечают DNS-записями с CNAME, в которых четко указано название региона.
Например, бакет с именем ifood, расположенный в регионе sa-east-1 (Сан-Паулу), при DNS-запросе вернёт CNAME с названием s3-sa-east-1-w.amazonaws.com. Это своего рода подсказка о том, что бакет существует, и где он расположен. В тоже время несуществующие бакеты или бакеты в регионе по умолчанию отвечают просто generic-имя, например s3-1-w.
amazonaws.com, что не содержит части с указанием региона. По сути, региональное имя выступает фильтром для отделения существующих бакетов от несуществующих, превосходя чистую скорость и точность обычных запросов. Ограничения для региона us-east-1 Главный недостаток описанного метода в том, что для бакетов, расположенных именно в регионе us-east-1, информация с CNAME не позволяет определённо сказать, существует бакет или нет. Причина в том, что ns-записи для несуществующего бакета и для бакета в us-east-1 выглядят одинаково: они ссылаются на generic s3-w.
us-east-1.amazonaws.com. Для таких бакетов необходимо использовать дополнительные методы подтверждения существования, например интеграцию с HTTP-запросами или иные приемы. Автоматизация масштабного поиска бакетов с помощью pugdns Понимание теории – лишь первый шаг.
Практическое применение требует инструментов, которые смогут быстро перебрать сотни тысяч имен и применить DNS-проверки по изложенной логике. Программа pugdns создана именно для таких целей. С помощью нее можно подготовить список потенциальных имен бакетов (словарь), добавить к ним доменную зону s3.amazonaws.com.
после чего массово проводить DNS A-запросы с высоким уровнем параллелизма. В итоге инструмент выдаст JSONL-файл с результатами, где достаточно отфильтровать записи с присутствием региональных CNAME для выявления существующих бакетов. Такая методика позволяет искать в сотнях тысяч строк всего за пару минут и выявлять реальное количество бакетов, а не множество ложных срабатываний. Преимущества подхода в реальных сценариях Использование DNS-методики для поиска бакетов оптимально не только с точки зрения скорости, но и с точки зрения незаметности. HTTP-запросы генерируют больше сетевого трафика, подвергая пользователя риску быть замеченным как сканер или потенциальный атакующий.
DNS-запросы выглядят гораздо менее подозрительно и разбросаны по времени и пространству, что упрощает скрытное исследование. Особенно ценно это для специалистов по безопасности и баг-баунти, которым важно минимизировать шум и нагрузку. Перспективы развития и другие возможные приемы Хоть метод с региональными CNAME очень хорош, он не решает всех задач. Целью исследователей зачастую становится также получение информации о бакетах в us-east-1 и других сценариях, где DNS-информация не дает однозначных ответов. Для таких случаев можно сочетать подходы – DNS как быстрый фильтр существования, а HTTP-запросы для оставшихся кандидатов для подтверждения и получения детальной информации.
Дальше развитие техники может включать машинное обучение для фильтрации имен из списков, предварительную обработку и использование распределенных систем для максимального масштабирования. Заключение Метод сверхбыстрого обнаружения существующих бакетов Amazon S3 с помощью DNS-запросов и анализа региональных CNAME-записей открыл новые возможности для специалистов по безопасности и исследователей. В отличие от классических подходов через HTTP, этот способ работает намного быстрее и эффективнее, позволяя обрабатывать сотни тысяч имен за считаные секунды. Несмотря на некоторые ограничения в регионе us-east-1, метод является мощным инструментом при быстром этапе разведки и значительно снижает технические и сетевые издержки. В информационной безопасности такие «тонкие» приемы показывают, насколько много можно узнать, внимательно изучая скрытые детали стандартных протоколов и их поведение.
Следуя этим рекомендациям и используя современные утилиты, вы сможете вывести процесс обнаружения бакетов на новый уровень и получить преимущество в работе с облачными сервисами.
