Руководства по безопасности
Захват поддомена (висящая DNS-запись): как забытая запись DNS позволяет атакующим использовать ваш домен
Удалите облачный ресурс, но оставьте CNAME — и любой сможет занять этот поддомен, не трогая ваших серверов. Почему утекают сессионные cookie, почему сертификат не защищает и какой порядок удаления это предотвращает.
Однажды один из ваших поддоменов начинает показывать содержимое атакующего — хотя ваши серверы никто не трогал. Обновления, аутентификация и мониторинг здесь не помогают. Причина — не проникновение, а то, что вы забыли удалить.
Что происходит на самом деле (три этапа)
1. Создание
Вы создаёте облачный ресурс с полным доменным именем (app-xxxx.<домен провайдера>) и добавляете в свою зону запись CNAME, чтобыsub.example.comвёл на него.2. Удаление (наполовину)
Ресурс удаляют, когда он больше не нужен. В этот момент нужно удалить и CNAME дляsub.example.com, но этого не делают. Домен по-прежнему объявлен как рабочий, но ведёт в никуда: это висящая запись DNS.3. Захват
Атакующий находит висящий поддомен и создаёт ресурс с тем же FQDN, который раньше контролировали вы. С этого момента трафик наsub.example.comприходит на его ресурс, а содержимое решает он.
Ваша зона DNS (без изменений)
sub.example.com CNAME→ app-xxxx.provider.example
↓ удалили только цель
Облачный ресурс: удалён
имя снова может занять кто угодно
↓ атакующий создаёт ресурс с тем же именем
Ресурс атакующего (его аккаунт)
он решает, что показывает sub.example.com. Ваши серверы никто не трогал
CNAME — слабое место, потому что указывает на имя
В отличие от записи A, которая указывает на адрес, CNAME указывает на имя, а во многих облачных сервисах это имя достаётся тому, кто займёт его первым. Как только вы его отпустили, его может забрать кто-то другой. Документация говорит, что записи CNAME «особенно уязвимы для этой угрозы». Та же логика применима к записям MX: там последствие в том, что почту, адресованную этому поддомену, может получать кто-то другой.
Ущерб — не только поддельная страница
- Потеря контроля над поддоменом
- С вашего домена показывается содержимое, которым вы не управляете, — ущерб бренду и потеря доверия
- Сбор cookie
- Веб-приложения часто открывают сессионные cookie для поддоменов через шаблон (
*.example.com), и тогда к ним может обратиться любой поддомен. Убедительная страница на захваченном поддомене может собирать их у посетителей — включая cookie с пометкой Secure - Использование для фишинга
- Поскольку домен выглядит подлинным, фишинг с него гораздо убедительнее
Главное заблуждение: «у нас HTTPS, есть сертификат»
Документация называет это распространённым заблуждением и опровергает его: атакующий, владеющий захваченным поддоменом, может запросить и получить для него действительный сертификат. Сертификат с проверкой домена проверяет, что запрашивающий контролирует имя в этот момент, поэтому смену контроля он не замечает.
В итоге действительный сертификат работает на атакующего: замок отображается, cookie с пометкой Secure по-прежнему отправляются, а поддельный сайт выглядит более, а не менее законным. Читайте сертификат как «кто владеет этим именем», а не «с кем я говорю».
Как предотвратить: сделать удаление записи DNS первым шагом процедуры
Причина не в технической сложности, а в порядке шагов при выводе из эксплуатации. Если сначала удалить ресурс, а DNS потом, в промежутке поддомен можно захватить.
Порядок, который приводит к инцидентам
Удалить ресурс → DNS потом → забыть
Тем временем DNS продолжает объявлять рабочий законный поддомен. Мониторинг не сообщит, что сервер упал, — потому что ничего не упало.
Безопасный порядок
Сначала удалить запись DNS → затем удалить ресурс
Документация рекомендует ставить блокировки удаления на ресурсы с собственной записью DNS, потому что сама блокировка напоминает, что соответствие нужно удалить до удаления ресурса, — и отмечает, что такие меры работают только вместе с обучением сотрудников.
Включите «удалить запись DNS» в чек-лист вывода из эксплуатации
Это первый шаг предотвращения в документации: включить его в список обязательных проверок при выводе сервиса из эксплуатации и научить разработчиков удалять записи DNS при каждом удалении ресурса. Смысл в том, чтобы порядок не зависел от чьей-то памяти.
Свяжите жизненный цикл записи с ресурсом
Некоторые провайдеры предлагают типы записей, привязанные к самому ресурсу (alias-записи и подобные). При удалении ресурса запись становится пустой, поэтому запись, указывающая в никуда, не может остаться. Поддерживаются только некоторые сервисы, но используйте это везде, где возможно: так забытые записи предотвращаются устройством системы, а не процедурой.
Требуйте подтверждения владения
Некоторые сервисы позволяют опубликовать TXT-запись для подтверждения владения собственным доменом. Если она есть, никакая другая подписка не сможет подтвердить этот домен или захватить его. Это не мешает создать ресурс с тем же именем, но без возможности подтвердить владение ваш трафик не получить. Имя может использовать только тот, кто докажет владение, а не тот, кто занял его первым.
Регулярно проверяйте зоны DNS: существует ли цель и ваша ли она?
Документация называет две проверки: существует ли цель и принадлежит ли она вам. Вторая важнее, потому что «отвечает — значит, всё в порядке» не проверка: ответ от чужого ресурса — это и есть атака. Ведите каталог сервисов, связывающий FQDN с владельцами, и регулярно выгружайте его в рамках инвентаризации активов.
Обнаружив висящую запись, не ограничивайтесь её удалением
Шаги устранения идут дальше: обновить устаревшие ссылки на поддомен в коде приложения, выяснить, был ли взлом, и разобраться, почему запись не удалили при выводе из эксплуатации, чтобы это не повторилось. В частности, если логика приложения отправляла на этот висящий поддомен секреты (например, учётные данные OAuth) или чувствительные персональные данные, эти данные могли попасть к третьему лицу.
Взгляд этого сайта: уязвимости чаще возникают из того, чем перестали пользоваться, чем из того, что строят
Разговоры о безопасности обычно крутятся вокруг того, что строится, а проникновения чаще начинаются с того, что вывели из работы и оставили. Поддомен, которым никто не пользуется, аккаунт уволившегося коллеги, тестовая среда, поднятая для одного эксперимента, данные участников, сохранённые после отмены подписки, — у всех одно общее: «мы этим больше не пользуемся» незаметно выводит их из-под мониторинга и проверок. То, чем вы перестали пользоваться, остаётся активом, пока его не удалили. Поэтому мы предлагаем распространять инвентаризацию на всё, что вы когда-либо создавали, а не только на то, что сейчас работает. Люди, которые оказались затронуты утечкой у провайдера уже после отказа от его услуг, — пример той же проблемы (что делать, если взломали ваш хостинг-провайдер).
Источники (первичные)
- Microsoft, «Prevent dangling DNS entries and avoid subdomain takeover» (Microsoft Learn / Azure security fundamentals) — learn.microsoft.com (три этапа, почему CNAME особенно уязвимы, сбор cookie и записи MX, опровержение заблуждения о сертификате, а также шаги предотвращения и устранения — блокировки удаления, alias-записи, подтверждение владения, регулярные проверки — взяты из этого документа)
Что прочитать дальше
- Инвентаризация: чек-лист инвентаризации активов (распространите её на всё, что вы когда-либо создавали)
- Размещение: публичные бакеты (та же форма — «утекает из-за настройки»)
- Глоссарий: что такое фишинг / что такое XSS / что такое CSRF
FAQ
QЗахват поддомена означает, что мои серверы взломали?
Нет, и именно это делает ситуацию неудобной. Захватывают то, куда указывает DNS, а не ваш сервер. Если вы удалили облачный ресурс, но оставили запись CNAME в своей зоне DNS, третьему лицу достаточно создать в своей подписке ресурс с тем же полным доменным именем, и трафик, направленный на ваш поддомен, придёт к нему. Обновления, аутентификация и мониторинг здесь не помогают, потому что ни одно из них не участвует.
QРазве HTTPS этого не предотвращает? Сертификат же делает всё безопасным?
Не делает, и документация Microsoft прямо называет это распространённым заблуждением: тот, кто владеет захваченным поддоменом, может запросить и получить для него действительный сертификат. Сертификат с проверкой домена доказывает только то, что владелец сейчас контролирует это имя, — он ничего не говорит о том, кто этот владелец, и не замечает смены контроля. Действительный сертификат даже работает на атакующего, делая поддельный сайт более убедительным.
QЕсли это влияет только на внешний вид, ущерб ведь ограничен?
Утекают сессии. Веб-приложения часто открывают сессионные cookie для поддоменов через шаблон (*.example.com), и тогда их может прочитать любой поддомен. Если пользователей удастся направить на захваченный поддомен, у атакующего могут оказаться даже cookie с пометкой Secure. А висящая запись MX означает, что почту, адресованную этому поддомену, может получать кто-то другой.
QКак это реально предотвратить?
Сделайте порядок удаления процедурой и механизмом, а не тем, что нужно помнить. Документация рекомендует включить «удалить запись DNS» в обязательный чек-лист вывода сервиса из эксплуатации, ставить блокировки удаления на ресурсы с собственной записью DNS, чтобы сама блокировка напоминала, что сначала нужно удалить DNS, использовать типы записей, жизненный цикл которых связан с ресурсом, где они доступны, и регулярно проверять зоны DNS: существует ли цель и принадлежит ли она вам.