DNS spoofing

Работа DNS напоминает справочную службу: пользователь знает доменное имя (запоминающийся для людей идентификатор компьютера в интернете), например example.org, отправляет его в виде запроса в интернет, а система DNS преобразует его в соответствующий IP-адрес, например адрес формата IPv4 — 192.0.2.42 или адрес IPv6 — 2001:db8:85a3:8d3:1319:8a2e:370:7347, тем самым позволяя установить соединение с нужным устройством. Если DNS-сервер не знает требуемого соответствия, он перенаправляет запрос другому серверу — процесс продолжается рекурсивно. Для повышения производительности полученные сопоставления серверы хранят определённое время в своём кэше: если поступает идентичный запрос, сервер может ответить из кэша без обращения к другим серверам.

Если DNS-сервер получает неверное сопоставление и сохраняет его в кэше, такая ситуация называется отравлением кэша (англ. poisoned cache). Сервер будет возвращать ошибочную информацию и другим пользователям, что приведёт к их перенаправлению, например, на ресурс злоумышленника^[1].

В данном варианте DNS spoofing злоумышленник посредством IP-спуфинга выдаёт себя за легитимный DNS-сервер и отправляет на запрос жертвы поддельный ответ. Для успешности атаки поддельный ответ должен прибыть к резолверу жертвы раньше, чем легитимный, либо рабочий сервер имён должен быть выведен из строя, например с помощью атаки типа «отказ в обслуживании» (DoS). Кроме того, параметры ответа должны соответствовать исходному запросу — в том числе последовательный 16-битный номер транзакции. Если злоумышленник находится в локальной сети, он может проследить номер транзакции с помощью сниффера. В противном случае номер приходится подбирать наугад — в среднем потребуется ${\displaystyle {\frac {2^{16}}{2}}=32\,768}$ попыток. Для увеличения шансов злоумышленник может отправить сразу множество поддельных ответов, однако это увеличивает затраты на ресурсы.

Из-за ряда уязвимостей предсказать номер транзакции бывает проще. В BIND версии 8 генератор псевдослучайных чисел был небезопасен, поэтому такие номера можно было вычислить с минимальными затратами. Если атакуемый резолвер отправляет несколько идентичных запросов с разными номерами транзакции, вероятность успешной подделки существенно возрастает за счёт парадокса дней рождения.

Обычно компьютер, подключённый к интернету, использует DNS-сервер своего провайдера либо корпоративной сети. В организациях такие серверы применяются для ускорения разрешения имён за счёт кэширования предыдущих запросов. Атаки через отравление DNS-кэша могут выполняться напрямую (на атакуемом сервере) или опосредованно — через вышестоящие серверы, к которым сервер обращается с запросами.

Для проведения атаки на DNS-кэш злоумышленник, как правило, использует программные уязвимости — так называемые эксплойты. Корректная реализация должна валидировать происхождение данных, например с помощью DNSSEC, чтобы гарантировать их достоверность; иначе сервер может сохранить ложные данные в локальный кэш и далее подставлять их уже при новых запросах других пользователей.

В нижеперечисленных вариантах атаки с помощью отравления DNS-кэша происходит подмена записей для сервера ns.target.example: пользователь перенаправляется на сервер злоумышленника w.x.y.z. Предпосылкой является то, что для зоны target.example сервером авторизации является именно ns.target.example.

Для успешной реализации атаки злоумышленнику требуется вызвать у DNS-сервера запрос к домену, контроль над которым принадлежит атакующему.

В первом сценарии атаки злоумышленник переназначает DNS-сервер своей доменной зоны на сервер целевого домена, а затем присваивает последнему выбранный IP-адрес.

Запрос от DNS-сервера: Какие адреса соответствуют subdomain.attacker.example?

subdomain.attacker.example. IN A

Ответ злоумышленника:

Answer:
(нет ответа)

Authority section:
attacker.example. 3600 IN NS ns.target.example.

Additional section:
ns.target.example. IN A w.x.y.z

Уязвимый DNS-сервер сохранит дополнительную A-запись (IP-адрес) для ns.target.example в кэше, и злоумышленник сможет подставлять свои ответы для всей зоны target.example.

Второй вариант отравления кэша состоит в том, что злоумышленник перенаправляет указатель сервера имён (NS) сторонней — не связанной с запросом пользователя — зоны на выбранный им IP-адрес.

Запрос от DNS-сервера: Какие адреса соответствуют subdomain.attacker.example?

subdomain.attacker.example. IN A

Ответ злоумышленника:

Answer:
(нет ответа)

Authority section:
target.example. 3600 IN NS ns.attacker.example.

Additional section:
ns.attacker.example. IN A w.x.y.z

Уязвимый сервер закэширует нерелевантные авторитетные данные для NS-записи зоны target.example, в результате чего атакующий сможет подставлять свои ответы для целой зоны target.example.

Исторически одним из методов отравления DNS-кэша было внедрение дополнительных поддельных DNS-записей в легитимные ответы DNS. Если запрашивающая сторона принимает вложенные ресурсные записи без проверки, атакующий может внедрить поддельные записи для любых имён, которые будут помещены в кэш.

В публичной DNS-иерархии каждый сервер отвечает только за свою часть пространства имён (является авторитетным лишь в зоне делегирования). Если DNS-серверу поступает запрос по адресу вне его зоны ответственности, он может перенаправить его другому серверу. Однако для снижения нагрузки ответы других серверов кэшируются локально. Если запрос вышеописанного типа повторится, дополнительное обращение не требуется: ответ возьмётся из кэша. Запрашивающая сторона зачастую принимает не только основной ответ, но и дополнительные (правомерные) данные (glue-записи), кэширующиеся вместе с ними. Суть атаки — внедрить в эти дополнительные данные одну или несколько поддельных ресурсных записей.

Более конкретно: в authority-секции (Authority Section) ответа подставляется подменяемое имя (например, de.wikipedia.org) в качестве мнимого сервера DNS, а в additional-секции (Additional Section) — IP-адрес (например, 1.2.3.4) контролируемого злоумышленником узла.

1. Злоумышленник получает контроль над сервером имён XX. Он настраивает сервер так, чтобы при любом запросе к зоне example.com дополнительно к основному ответу добавлялась поддельная запись de.wikipedia.org 192.0.2.1.
2. Общественный DNS-сервер YY пытается разрешить имя test.example.com и направляет запрос серверу XX. Управляемый злоумышленником сервер возвращает корректный IP к имени, но добавляет поддельную запись de.wikipedia.org 192.0.2.1, которая без проверки попадает в кэш YY.
3. Позднее пользователь обращается к имени de.wikipedia.org у сервера YY. Сервер обнаруживает (поддельную) запись в кэше и честно возвращает IP 192.0.2.1.
4. Пользователь пытается зайти на de.wikipedia.org, но незаметно для себя попадает на сторонний веб-сайт по адресу 192.0.2.1.

Данная уязвимость была закрыта в DNS-сервере BIND в июне 1997 года: сервер стал игнорировать ресурсные записи, присланные без запроса, — допускаются только записи из соответствующей зоны (англ. in-bailiwick, по-русски: «в своей зоне ответственности»). Современные сервера DNS реализуют аналогичную проверку до помещения записи в кэш.

Вскоре после обнаружения этой уязвимости Юджин Кашпуров провёл широкий кэш-отравляющий рейд против уязвимых серверов BIND, за что впоследствии был приговорён к условному сроку.

В июле 2008 года Дэн Камински представил новый вариант атаки, позволяющий обойти кеширование корректных ответов и существенно ускоряющий проведение подделки^[2]. Путём подбора несуществующих доменных имён можно многократно повторять попытки — если не удалось угадать номер транзакции среди поддельных ответов. Поддельный ответ содержит делегирование — NS-запись и glue-запись, указывающие на сервер злоумышленника; таким образом становится возможной полная подмена glue-записей внутри доверенной зоны^[3].

В ряде стран DNS spoofing применяется для реализации интернет-цензуры. При возврате поддельных ответов резолверами, речь также идёт о DNS-угоне, это была предложенная схема для блокировки сайтов в Германии.

Вариант атаки «человек посередине» от сетевого оператора получил название DNS-injection. Оператор с помощью глубокой инспекции пакетов выявляет доменные имена в DNS-запросах и сравнивает их с чёрным списком. При совпадении оператор задаёт поддельный DNS-ответ. Так как анализируются все DNS-запросы в сети, блокировка применяется даже если пользователь не использует DNS-серверы провайдера.

DNS-injection активно используется в Китае в рамках проекта «Золотой щит». При этом поддельные ответы могут получать и зарубежные пользователи, если их DNS-запрос проходит через китайские сети^[4].

Защита от DNS spoofing или направлена на увеличение числа случайных параметров в DNS-сообщениях, которые должен угадать злоумышленник, или на криптографическую аутентификацию передаваемых данных.

Многие атаки на кэш DNS можно предотвратить, если доверять только данным, относящимся к конкретному запросу, и игнорировать остальные сведения. Например, начиная с версии BIND 9.5.0-P1 реализована проверка: запрос отправляется с произвольно выбранного порта и номером, полученным с помощью криптографически стойкого генератора, что усложняет подбор пар «порт — nonce» при атаке гонки (race condition).

Однако если роутеры, файрволы, прокси и другие устройства выполняют Преобразование сетевых адресов (NAT), а точнее — трансляцию портов, им приходится подменять исходный порт для отслеживания состояния соединения, что может нивелировать эффект случайности.

Расширения безопасности DNS (DNSSEC) реализуют криптографическую подпись ресурсных записей, что делает атаки через отравление кэша неработающими.

Такие атаки также могут быть нейтрализованы на транспортном и прикладном уровне с помощью end-to-end валидации после установления соединения — например, с использованием TLS, цифровых подписей, или HTTPS. Это позволяет проверить подлинность цифрового сертификата и подтверждает принадлежность сайта его владельцу.

После раскрытия атаки Камински все распространённые DNS-серверы реализуют randomization of the source port (рандомизацию исходного порта), причём djbdns и PowerDNS внедрили это ранее^[5]. В данном случае вместе с номером транзакции случайно выбирается и порт отправителя в UDP-заголовке DNS-запроса. В зависимости от реализации это даёт дополнительно 11-16 бит случайности, обязательных для угадывания злоумышленником — в среднем понадобится ${\displaystyle {\frac {2^{16}\cdot 2^{16}}{2}}=2\,147\,483\,648}$ попыток.

Ещё один способ усложнить подбор — 0x20-bit encoding (рандомизация регистра буквы в доменном имени), например, dE.WiKiPedia.ORG. Для разрешения имён в DNS регистр букв несущественен, однако согласно RFC 1034^[6] ответ должен повторять регистр запроса. Количество добавленных бит случайности соответствует числу букв в имени: для de.wikipedia.org — 14 бит.

Общая черта всех этих методов — отсутствие необходимости изменения формата DNS-сообщений, обеспечивающая высокую совместимость с инфраструктурой. DNS spoofing всё ещё возможен, но за счёт увеличения случайности вероятность успеха для удалённого атакующего снижается. Однако ни один метод рандомизации не защищает от атакующего, способного перехватить DNS-запрос на лету (on-path attacker).

К другой категории методов защиты относятся расширения формата DNS-пакетов за счёт внедрения цифровых подписей или кодов аутентификации сообщений (MAC), создаваемых и проверяемых с использованием криптографии. Злоумышленник может создать поддельный DNS-ответ, но не обладает секретными ключами для подписи.

Наиболее известная технология — DNSSEC (расширения безопасности системы доменных имён), в которой записи подписываются с помощью асимметричных ключей. DNSSEC уже частично используется на практике, хотя большая часть трафика DNS до сих пор им не защищена^[7].

Альтернативным подходом к DNSSEC является DNSCurve, где защищается криптографически не запись, а весь канал обмена между резолвером и сервером имён (сочетание асимметричной и симметричной криптографии). Адаптация DNSCurve — DNSCrypt — используется, например, OpenDNS для защиты связи между конечными пользователями и резолверами.

TSIG (Transaction Signature) также обеспечивает защищённую связь между двумя DNS-участниками, используя HMAC и заранее согласованные симметричные ключи.

Ещё один подход — DNS over HTTPS (DoH), в котором DNS-запросы шифруются по протоколу HTTPS.