Subdomain takeover: чем опасны забытые DNS-записи

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

Как возникает риск

Представьте, что для подключения promo.example.uz к внешнему конструктору лендингов вы создали запись CNAME на имя example-promo.builder.example.net. Акция закончилась, проект в конструкторе удалили, а DNS-запись осталась. Теперь поддомен указывает на ресурс, который никому не принадлежит.

Во многих облачных сервисах имя проекта или подключённый домен достаётся первому, кто его запросит, и владение дополнительно не проверяется. Если злоумышленник создаст в том же сервисе проект с тем же именем или привяжет promo.example.uz к своему аккаунту, поддомен полностью перейдёт под его управление. Посетитель видит в браузере ваш домен, но содержимое страницы определяет посторонний.

То же самое бывает с записями A. Когда вы отказываетесь от облачного сервера, его IP возвращается провайдеру и позже может достаться другому клиенту. Если test.example.uz всё ещё указывает на этот адрес, новый владелец случайно или намеренно покажет контент на вашем поддомене. Аналогичная ситуация возникает, если делегировать поддомен NS-записью в другой DNS-сервис, а затем удалить там зону.

Почему это серьёзно

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

Кроме того, если основной сайт устанавливает cookie на весь домен, то есть на уровне .example.uz, захваченный поддомен может их читать или изменять. Это угрожает пользовательским сессиям. А если с захваченного поддомена будут распространяться спам или вредоносные файлы, репутация всего домена пострадает в чёрных списках.

Пример: приёмная кампания университета

Частный университет каждый год в сезон приёма открывал отдельный лендинг по адресу qabul.example.uz. Страница была собрана во внешнем конструкторе, а поддомен подключён через CNAME. После окончания сезона отдел маркетинга отменил подписку на конструктор, так как на следующий год решили использовать другой инструмент. Удалить DNS-запись при этом не было ни в чьём списке задач.

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

Как найти уязвимые записи

Первый шаг — получить полный список записей зоны, проще всего экспортом из панели управления DNS. Затем нужно проверить, существует ли ещё цель каждой записи CNAME. Простой shell-скрипт автоматизирует эту работу:

#!/bin/sh
# Список проверяемых поддоменов
for sub in www shop qabul promo blog test help; do
  host="$sub.example.uz"
  target=$(dig +short CNAME "$host")
  [ -z "$target" ] && continue
  status=$(dig "$target" A | grep -o 'status: [A-Z]*')
  echo "$host -> $target ($status)"
done

Если в какой-то строке выводится status: NXDOMAIN, запись указывает на несуществующее имя, и её надо срочно разобрать. Даже если имя цели существует, полезно открыть страницу в браузере или через curl. Сервисы часто отвечают сообщением вроде «проект не найден» или «домен не привязан ни к одному аккаунту», и это тоже признак опасного состояния:

curl -sI https://promo.example.uz/ | head -n 5
curl -s https://promo.example.uz/ | grep -iE "not found|no such|not configured"

Для записей A проверьте в панели хостинга или облака, что каждый IP всё ещё принадлежит вашему серверу. Автоматизировать это сложнее, поэтому практичнее вести список для ручной проверки.

Правила предотвращения

Главное правило — правильный порядок отключения сервиса: сначала удаляется DNS-запись, затем внешний ресурс. В обратном порядке появляется промежуток, когда ресурса уже нет, а запись осталась, и именно им пользуются атакующие. Это правило должны знать все ответственные сотрудники, включая отделы маркетинга и дизайна, ведь внешние сервисы чаще всего подключают именно они.

Фиксируйте для каждого поддомена, кто за него отвечает и зачем он создан.
Если внешний сервис позволяет подтвердить владение доменом через TXT-запись, обязательно используйте это.
Раз в квартал пересматривайте зону и удаляйте неиспользуемые записи.
Привязывайте cookie основного сайта к конкретному имени хоста, а не ко всему домену.
Перед удалением облачных серверов найдите и уберите все указывающие на них записи A и AAAA.

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