dns-rebinding-attacks

О dns-rebinding-attacks

Руководство по атакам с перенаправлением DNS, посвящённое методу на стороне клиента, позволяющему обойти политику «одного источника» браузера путём изменения IP-адреса, стоящего за именем хоста, которое жертва уже загрузила. Основная идея заключается в том, что политика «одного источника» проверяет строку имени хоста, а не разрешённый IP-адрес: злоумышленник, контролирующий авторитетный DNS-сервер для своего домена, может подать вредоносный JavaScript при первом разрешении (IP-адрес злоумышленника), а затем повторно разрешить то же имя хоста на внутренний IP-адрес, благодаря чему браузер будет рассматривать запросы к внутреннему сервису как запросы из одного источника, и скрипт сможет считывать ответы.

В статье разъясняется различие от SSRF, поскольку перепривязка DNS является клиентским аналогом, а также подробно описываются практические препятствия и способы их обхода. Поскольку браузеры ведут собственный DNS-кеш, игнорирующий значения TTL с малым сроком действия (примерно 60 секунд в Chrome, Edge и Firefox), в статье описаны стратегии обхода, включая ожидание обновления кеша, ответы с несколькими записями A с блокировкой IP-адреса злоумышленника для принудительного перехода на резервный вариант, затопление поддоменов для получения новых резолюций и задержки сервис-работников. Варианты атак включают классическое перенаправление HTTP, перенаправление WebSocket, гибридную атаку TOCTOU на стороне сервера и быстрый подход с использованием нескольких записей A.

Используйте его при тестировании приложений, которые полагаются на DNS для проверки происхождения или выполняют клиентские запросы fetch/XHR на домены, контролируемые злоумышленником, особенно в тех случаях, когда SSRF на стороне сервера невозможен. В таблице целей высокой ценности перечислены метаданные облачных сервисов (169.254.169.254), API Docker и Kubernetes, внутренние панели администрирования, Elasticsearch, Redis и Consul/etcd, с примечанием о том, что требование к токенам в IMDSv2 препятствует перепривязке, поскольку в режиме no-cors нелегко установить пользовательские заголовки. Список инструментов включает Singularity, не требующий настройки сервис rbndr.us (с форматом поддомена «шестнадцатеричный-IP»), whonow и минималистичные DNS-серверы на Python, а также содержит перекрёстные ссылки на навыки по SSRF и неправильной настройке CORS.

Часто задаваемые вопросы

Чем перепривязка DNS отличается от SSRF?

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

Почему TTL, равный 0, не срабатывает сразу?

Браузеры ведут собственный кэш DNS, который игнорирует низкие значения TTL (около 60 секунд в Chrome, Edge и Firefox), поэтому в этом навыке рассматриваются такие способы обхода, как ожидание, использование нескольких записей A с резервными вариантами, наводнение субдоменов и задержки сервис-работников.

Каковы наиболее ценные внутренние цели?

Метаданные облака по адресу 169.254.169.254, API Docker, API Kubernetes, внутренние панели администрирования, Elasticsearch на порту 9200, Redis на порту 6379, а также Consul/etcd.

Можно ли с помощью перепривязки похитить учетные данные AWS из IMDSv2?

Не так просто. IMDSv2 требует наличия заголовка X-aws-ec2-metadata-token в запросе PUT, а при повторной привязке в режиме no-cors сложно установить пользовательские заголовки в первоначальном запросе на токен. IMDSv1 более уязвим.

Какие инструменты рекомендуются?

Singularity (полнофункциональный фреймворк), rbndr.us (не требующий настройки, использующий субдомены в формате «шестнадцатеричный код-IP»), whonow (динамический сервер перепривязки) и минималистичные пользовательские DNS-серверы на Python.