Атаки на внутренние DNS-резолверы: отравление кэша, DNS rebinding и перехват трафика через подмену записей в корпоративной сети
Изображение: recraft
Внутренний DNS-сервер – один из ключевых элементов корпоративной инфраструктуры. Через него проходят обращения к веб-сервисам, почте, системам обновлений, каталогам, EDR, SSO и другим внутренним ресурсам. Поэтому компрометация DNS-сервера нередко приводит не к локальному сбою, а к перенаправлению трафика, MITM-атакам, отказу в обслуживании и обходу прикладных защит.
Новое руководство NIST прямо рассматривает протокол DNS как базовый слой безопасности предприятия, рекомендует разделять роли authoritative/recursive, выделять DNS в отдельные узлы и жестко ограничивать, кто может задавать рекурсивные запросы и куда клиенты могут отправлять DNS-запросы (NIST SP 800-81 Rev. 3, март 2026).
Отравление кэша DNS (DNS Cache Poisoning)
Классические атаки на кэш DNS не исчезли после 2008 года. После доклада Дэна Каминского и координированного выпуска патчей по CVE-2008-1447 (a.k.a Kaminsky bug) отраслевые вендоры усилили энтропию при генерации запросов на резолв (случайность ID транзакции – TXID и портов-источников), однако сама поверхность атаки не была нейтрализована. Это подтвердили три источника:
- исследования SAD DNS, которые снова сделали практичными удалённые атаки на отравление кэша без перехвата трафика за счёт побочных каналов в сетевом стеке;
- атака MaginotDNS, показавшая опасность комбинированных ролей forwarder/recursive (CDNS);
- достаточно свежий репорт NLnet Labs Unbound CVE-2025-11411 о захвате домена (domain hijack) через некорректную обработку authority section.
Подводя итог, можно сказать, что патчи, применяемые для закрытия класса атак, обозначенных в CVE-2008-1447, не помогают полностью обезопасить себя, а лишь сводят происходящее к тому, что атаки стали зависеть от качества реализации, конфигурации и сетевой среды.
Исторически подобные атаки основывались на слабой защите DNS-транзакций. Основными факторами риска были короткий 16-битный идентификатор запроса (TXID), фиксированный либо недостаточно случайный исходный UDP-порт, слабая проверка записей в секциях authority и additional, а также возможность вынуждать DNS-сервер многократно выполнять запросы к случайным поддоменам, отсутствующим в кэше. Именно этот класс уязвимостей описывался в известных публикациях и исследовании Дэна Каминского. Позднее RFC 5452 зафиксировал основные рекомендации по повышению устойчивости DNS к поддельным ответам.
После 2008 года базовыми защитными мерами стали случайный выбор исходного порта, более строгая проверка DNS-ответов, техника случайного изменения регистра символов в имени запроса (0x20 case randomization), а позднее – механизм DNS Cookies. Однако современные исследования показали, что атаки без прямого доступа к трафику по-прежнему возможны. Они могут использовать побочные каналы операционной системы (SAD DNS), ошибки в логике взаимодействия между DNS-форвардером и резолвером, а также некорректную обработку записей authority, как это отмечалось в примечании по CVE-2025-11411. Для атаки на кэш обычно нужны как минимум четыре условия: резолвер выполняет рекурсию/форвардинг для жертвы; атакующий может заставить его делать cache miss; есть слабость/ослабление энтропии или логики проверки ответа; TTL отравленного RR достаточно велик, чтобы влияние было заметным.
Механизм атаки
Задача атакующего – воспользоваться коротким временным интервалом между отправкой запроса резолвером и получением легитимного ответа. В этот момент злоумышленник пытается направить на внутренний DNS-сервер поддельный DNS-ответ, который будет выглядеть как сообщение от авторитетного сервера. Если резолвер примет такой ответ как корректный, ложная запись будет помещена в DNS-кэш и начнет использоваться при последующих запросах клиентов. Основная цель – угадать параметры активного DNS-запроса, прежде всего идентификатор транзакции (TXID), а в ряде случаев также исходный порт запроса. Для повышения вероятности успеха злоумышленник массово перебирает возможные значения, отправляя поток ложных ответов с различными идентификаторами.
DNS rebinding
Rebinding-атака использует короткий TTL и повторный резолв того же доменного имени, чтобы привязать уже загруженный из браузера origin сначала к внешнему серверу злоумышленника, а затем к внутреннему адресу – 10.10.10.120, 127.0.0.1, 0.0.0.0 – эквиваленту на некоторых платформах или веб-интерфейсу маршрутизатора. Ключевая причина в том, что модель browser same-origin policy проверяет origin как комбинацию scheme + host + port, при этом IP-адрес не входит в проверку. Поэтому после смены A-запис JavaScript, загруженный с http://rebind.test:8080, все еще считается тем же origin, даже если фактический IP уже сменился на внутренний.
Современные браузеры ответили на это механизмами PNA и CORS. Google Chrome еще с ранних фаз PNA ограничил доступ к приватным сетям из небезопасного контекста. Локальный IP-адрес считается более конфиденциальным, чем частный IP-адрес. Частный IP-адрес, в свою очередь, считается более конфиденциальным, чем публичный IP-адрес.. Однако исследователи и практики показывают важную деталь: rebinding не умер, он просто стал зависеть от деталей реализации браузера, сетевого стека, адресного пространства и того, как ведет себя целевой сервис.
CORS (Cross-Origin Resource Sharing) – браузерный механизм безопасности, который регулирует доступ веб-страниц к ресурсам с другого origin. Он позволяет серверу явно указать, какие внешние сайты могут выполнять кросс-доменные запросы и какие методы или заголовки для этого разрешены.
PNA (Private Network Access) – расширение браузерной модели безопасности, предназначенное для защиты внутренних и локальных сетей пользователя. Технология ограничивает обращения сайтов из публичного интернета к ресурсам в частных сетях и требует явного разрешения со стороны целевого сервиса.
Механизм атаки
Злоумышленник предварительно разворачивает собственный DNS-сервер и размещает запись для домена web.attacker.test. Ключевым элементом является предельно малое значение TTL, например, 1 секунда. Это вынуждает клиентскую систему регулярно повторно выполнять DNS-разрешение имени вместо использования кэшированной записи.
На начальном этапе доменное имя разрешается во внешний IP-адрес инфраструктуры атакующего, например, где размещена стартовая веб-страница с вредоносным JS. В заранее выбранный момент DNS-сервер злоумышленника изменяет A-запись, и то же доменное имя начинает указывать уже на внутренний корпоративный узел, который недоступен из сети Интернет. Для браузера такая активность не считается аномальной, поскольку ограничения Same-Origin Policy не нарушается, и запрос выполняется к новому IP-адресу без дополнительных предупреждений пользователю.
Подмена записей и перехват трафика в корпоративной сети
В отличие от off-path poisoning, этот класс атак в корпоративной сети чаще реализуется злоумышленником, который находится на пути передачи трафика (on-path) или в непосредственной близости к нему (nearpath). Атакующий оказывается внутри L2-сегмента, подменяет ARP-соответствия между клиентом и шлюзом, перехватывает трафик и затем либо отдает фальшивые DNS-ответы сам, либо перенаправляет HTTP через промежуточный прокси-сервер (transparent proxy) для анализа и модификации данных. Здесь не нужно угадывать TXID, достаточно стать посредником. ARP как протокол изначально решает задачу сопоставления IPv4 и MAC-адресов, но не вводит криптографической проверки подлинности сообщений. Из конструкции протокола следует, что на плоском L2 он остается удобной MITM-поверхностью.
В Windows-среде проблему усиливают fallback-механизмы локального разрешения имен, которые используются, если обычный DNS-запрос не дал результата. RFC 4795 прямо предупреждает, что LLMNR представляет собой одноранговый механизм разрешения имён внутри локального сегмента сети. Устройства самостоятельно отвечают друг другу на широковещательные запросы, из-за чего как локальные атакующие в той же сети, так и удалённые злоумышленники при определённых условиях могут использовать этот механизм в своих целях. Microsoft давно рекомендует отключать multicast name resolution через Group Policy. Поэтому Responder стал настолько полезен в pentest-практике: он не ломает DNS напрямую, а эксплуатирует «дыру по соседству» – неправильный fallback от DNS к LLMNR/NBT-NS/mDNS.
К этому добавляются rogue DNS и split-horizon issues. Под split-horizon обычно понимают схему, при которой один и тот же домен возвращает разные DNS-ответы в зависимости от источника запроса: внутренние пользователи получают внутренние IP-адреса сервисов, а внешние — публичные. Ошибки в такой архитектуре могут приводить к тому, что клиентам выдаются неверные записи, внутренние адреса становятся доступны извне или внешние ответы начинают использоваться внутри сети. Если пользователи могут напрямую обращаться к внешним DoH/DoT-провайдерам, обход корпоративных DNS-политик становится крайне простым. Split DNS также может быть настроен через общий кэш для разных зон доверия, неразделённые представления клиентов (views) и единые политики обработки запросов, либо через смешение ролей forwarder и recursive resolver на одном сервере. В таких случаях ответы, предназначенные для одной группы клиентов, могут попасть к другой, внутренние записи – утечь наружу, а кэш DNS-сервера – заполниться данными из неподходящего контекста. Microsoft DNS Policy и BIND views как раз существуют, чтобы давать разные ответы разным клиентам без хаотической ручной магии.
Механизм атаки
На первом этапе злоумышленник выполняет ARP-spoofing, заставляя рабочую станцию жертвы и сетевой шлюз считать его устройство промежуточным узлом. После этого часть сетевого трафика начинает проходить через хост атакующего.
На втором этапе атакующий перехватывает DNS-запросы пользователя и отправляет поддельные ответы быстрее легитимного DNS-сервера либо полностью проксирует запросы через себя, изменяя только интересующие доменные записи.
Заключение
Практический вывод для специалистов по ИБ и ИТ достаточно прост: защиту DNS необходимо выстраивать по многоуровневому принципу. Недостаточно одной меры, требуется комплексный подход. Следует использовать DNS-резолверы с проверкой подлинности ответов и поддержку DNSSEC там, где это возможно. Необходимо применять случайный выбор исходных портов и исключать предсказуемые параметры генерации запросов. Полезно использовать механизмы DNS Cookies, снижать риски фрагментации пакетов, а при необходимости переходить на TCP. Дополнительно рекомендуется внедрять защитные DNS-политики, ограничивать исходящие DNS-запросы, а также контролировать использование зашифрованного DNS-трафика.
Авторы: старший аналитик Вячеслав Титенко и инженер Тимур Фарзалиев, УЦСБ SOC
