Политика одинакового источника Same-Origin Policy (SOP) долгое время считалась надёжным барьером, защищающим пользователей от несанкционированного взаимодействия между сайтами. Однако атака DNS Rebinding демонстрирует, как можно обойти эту защиту, эксплуатируя особенности работы DNS-резолверов и доверие браузера к неизменности IP-адреса за доменным именем.
Был период, когда мне длительное время приходилось собирать материалы для написания одной из своих научных работ и переходить по множеству ссылок, в том числе из непроверенных (во всех смыслах) источников. Тогда я ещё не был интегрирован в сферу ИБ, и, тем не менее, именно необходимость постоянно взаимодействовать с внешними ресурсами побудила меня задуматься о потенциальных рисках, которые несет в себе обычный переход по URL-адресу. И DNS Rebinding – как раз та атака, которая может превратить одно такое нажатие в прямой доступ к локальным сервисам
Эта атака эксплуатирует особенности разрешения DNS-имён и поведение браузеров с целью обохода механизма SOP и получения доступа к ресурсам, которые должны быть недоступны извне – к веб-интерфейсам локальных сервисов, IoT-устройств или внутренних административных панелей.
В данной статье мы не только разберём теоретическую основу атаки, но и на практике воспроизведём её в контролируемой среде, чтобы наглядно показать, как внешний сайт может "перетянуть" браузер жертвы на localhost.
Именно такие исследования помогают трезво оценивать реальные риски. Поэтому инженеры Security Vision внимательно изучают анатомию подобных атак и адаптируют под них наши решения для защиты инфраструктуры.
Теоретическая основа
Цель DNS Rebinding состоит в том, чтобы заставить браузер жертвы выполнять запросы не только к внешнему веб-сайту, подконтрольному злоумышленнику, но и к каким-либо внутренним ресурсам: локальным веб-сервисам, сетевым устройствам или даже приложениям в приватной сети жертвы. Атака возможна благодаря особенности, заложенной в самой архитектуре DNS и доверии браузера к доменному имени как к неизменному идентификатору источника. На практике IP-адрес, скрывающийся за одним и тем же доменом, может меняться между запросами, но браузер продолжает считать, что обращается к прежнему источнику, а потому разрешает скриптам взаимодействовать с новым адресом.
Классическая схема атаки выглядит так:
Злоумышленник регистрирует домен (например, evil[.]example) и настраивает собственный DNS-сервер, полностью контролирующий разрешение имён для этого домена.
Для DNS-записей настраивается минимальное время жизни (TTL), часто – на несколько секунд. Это препятствует кэшированию ответа как на стороне машины, с которой поступает запрос, так и на промежуточных резолверах, заставляя браузер запрашивать новый IP-адрес при каждом новом обращении (или после короткой паузы).
Жертва посещает вредоносный сайт по адресу http://evil[.]example. На первом этапе DNS-сервер отвечает публичным IP-адресом, на котором размещён веб-сервер злоумышленника. Браузер загружает HTML-страницу с встроенным JavaScript-кодом.
Этот скрипт инициирует повторные запросы к тому же домену (evil[.]example). Поскольку источник (домен) не изменился, SOP разрешает такие запросы.
К моменту повторного запроса TTL истёк, и браузер делает новый DNS-запрос. Теперь DNS-сервер отвечает не публичным IP, а, например, 127.0.0.1 или 192.168.1.100 – адресом внутреннего сервиса. Браузер, не замечая подмены, направляет HTTP-запрос уже на локальный сервис, считая его тем же сайтом.
Принцип реализации атаки DNS Rebinding представлен на рисунке 1.
В результате внешний ресурс обходит сетевой периметр и получает несанкционированный доступ к скрытым от публичной сети сервисам: веб-интерфейсам маршрутизаторов, локальным API и средам разработки.
Практическая реализация атаки
Чтобы наглядно продемонстрировать механизм DNS Rebinding, была построена контролируемая лабораторная среда из двух виртуальных машин:
атакующая машина (ATTACKER_IP, 192.168.1.128) – управляет DNS и веб-сервером злоумышленника;
машина жертвы (VICTIM_IP, например, 192.168.1.105) – пользователь, чей браузер будет использован для обращения к локальному веб-сервису.
Настройка DNS-сервера на стороне атакующего
На атакующей машине реализован простой UDP-сервер на порту 53 (dns.py), имитирующий поведение зловредного DNS-резолвера (рис. 3):
при первых N запросах от клиента (в текущей реализации, после 3-х запросов) сервер отвечает публичным IP-адресом атакующего (ATTACKER_IP);
начиная с (N+1)-го запроса, он возвращает 127.0.0.1, направляя трафик на локальный интерфейс жертвы;
ответы не кэшируются благодаря нулевому TTL (в нашем случае реализована симуляция через счётчик запросов по IP-адресу клиента);
На рисунке 2 представлен код настройки вредоносного DNS-сервера.
Настраиваем DNS на машине жертвы. Сейчас она обращается к 127.0.0.1, а требуется перенаправление запросов на атакующую машину (ATTACKER_IP). В экспериментальных целях указываем IP атакующей машины в /etc/resolv.conf. После этого отправляем DNS-запрос (рис. 3):
Вывод текущих перенаправлений после запуска вредоносного скрипта на машине представлен на рисунке 4:
Создадим на атакующей машине простой HTTP-сервер на порту 80, положим рядом index.html с идентификатором «атакующая машина» (рис. 5), запустим сервер с привязкой к 0.0.0.0 и зафиксируем его работу.
Создаём скрипт web.py (используем стандартный http.server, рис. 6).
Запускаем сервер. Сначала проверяем страницу локально (на атакующей машине). На рисунке 7 представлен вывод curl, на котором видно, что сервер возвращает страницу «Атакующая машина».
Настроим DNS-жертвы так, чтобы её системный резолвер указывал на ATTACKER_IP (в изолированной среде), перезапустим сетевой сервис. Далее создадим локальный index.html на жертве («Машина жертвы», рис. 8) и поднимем локальный HTTP-сервер на 80-м порту (рис. 9).
Важно понимать, что в демонстрационных целях используется простой HTML-док, но в реальности эту роль может выполнять вредоносный JS-код, нацеленный на эксплуатацию критически важных внутренних ресурсов, таких как уязвимые IoT-устройства или корпоративные веб-приложения.
Проверяем доступ к страницам из браузера/терминала. На рисунке 10 представлен вывод curl на машине-жертве, отображающий локальную страницу «Машина жертвы».
С машины-жертвы для демонстрации DNS Rebinding-симуляции делаем запрос по имени домена, чтобы разрешение шло на ATTACKER_IP. После переключения DNS на loopback (127.0.0.1) последующие обращения начинают показывать содержимое локальной жертвы (локальный HTTP-сервер запущен). На рисунке 11 представлен результат обращения к example.com после переключения DNS на loopback.
Браузер, считая источник неизменным, направляет запрос уже на локальный HTTP-сервер жертвы и отображает соответствующую HTML-страницу, хотя пользователь по-прежнему думает, что обращается к внешнему сайту. Таким образом, внешний сайт через DNS-подмену получил доступ к локальному веб-сервису, минуя политику одинакового источника.
Рекомендации по защите
Основная мера защиты от DNS Rebinding – это валидация служебного заголовка Host на стороне веб-сервиса. Сервер должен отклонять запросы, в которых значение Host не соответствует ожидаемому (например, разрешены только localhost, 127.0.0.1 или внутренние домены). Это предотвращает обработку запросов, пришедших от внешних доменов, даже если они технически достигли сервиса через перенаправление DNS.
Также рекомендуется использовать HTTPS (TLS-сертификат не совпадёт с подконтрольным злоумышленнику доменом, и соединение оборвётся); всегда требовать аутентификацию, даже для локальных сервисов; избегать развёртывания веб-интерфейсов без контроля доступа на 0.0.0.0, особенно на стандартных портах.
Заключение
Итак, в ходе простой симуляции атаки DNS Rebinding в контролируемой среде было показано, как браузер продолжает считать домен единым, даже когда его IP-адрес меняется с публичного на 127.0.0.1. Это наглядно иллюстрирует главную опасность DNS Rebinding: локальные сервисы, не предназначенные для публичного доступа, могут быть скомпрометированы через внешний сайт, если они не защищены какими-либо дополнительными механизмами (проверка заголовка Host, использование HTTPS, аутентификация).
Главная опасность этой атаки заключается в том, что она обходит фундаментальную политику Same-Origin Policy, не эксплуатируя баги в коде. Злоумышленники используют саму архитектуру взаимодействия DNS и браузера, что делает угрозу крайне скрытной; от нее могут пострадать любые корпоративные активы с незащищенными веб-интерфейсами. Поэтому закладывать механизмы защиты нужно еще на этапе проектирования, даже если сервис предназначен исключительно для внутреннего использования. Решение SPC (Security Profile Compliance) компании Security Vision позволяет создавать и применять эталонные профили безопасности, в том числе включающие специализированные проверки для выявления уязвимых веб-сервисов, и автоматически приводить их конфигурацию в соответствие с безопасными настройками. В контексте данной статьи, такой подход особенно актуален для сред, где локальные интерфейсы часто развёртываются без должной защиты; выявление незащищённых HTTP-серверов позволяет заблаговременно устранить условия, при которых становится возможной эксплуатация атак, способных нанести серьёзный ущерб вашей организации.
Истинная безопасность состоит в умении предотвратить саму возможность атаки. Важно всегда действовать на опережение. Строгий контроль конфигураций и автоматизация проверок помогут выстроить надежную инфраструктуру и изначально лишить злоумышленников любых шансов на успех.