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