Предотвращение "висячих" записей DNS и захвата поддоменов

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

Что такое захват поддомена?

Захваты субдоменов — это распространённая, высокосерьёзная угроза для организаций, которые регулярно создают и удаляют множество ресурсов. Захват поддомена может произойти в том случае, если у вас присутствует запись DNS, указывающая на отозванный ресурс Azure. Такие записи DNS также известны как «зависшие» записи DNS. Записи CNAME особенно уязвимы перед этой угрозой. Захват поддоменов позволяет злоумышленникам перенаправлять трафик, предназначенный для домена организации, на сайт, выполняющий вредоносную деятельность.

Распространенный сценарий для захвата поддомена:

  1. СОЗДАНИЕ:

    1. Вы подготавливаете ресурс Azure с полным доменным именем (FQDN) app-contogreat-dev-001.azurewebsites.net.

    2. Вы назначаете запись CNAME в зоне DNS с поддоменом greatapp.contoso.com, который направляет трафик к ресурсу Azure.

  2. ДЕКОНФИГУРИРОВАНИЕ:

    1. Ресурс Azure выводится из эксплуатации или удаляется, когда он больше не нужен.

      На этом этапе запись CNAME greatapp.contoso.comнеобходимо удалить из зоны DNS. Если запись CNAME не удалить, она объявляется в качестве активного домена, но не направляет трафик в активный ресурс Azure. Теперь у вас есть "подвешенная" запись DNS.

    2. Подвешенный поддомен greatapp.contoso.com теперь уязвим и может быть захвачен при назначении на ресурс другой подписки Azure.

  3. ЗАХВАТ:

    1. Используя общедоступные методы и средства, злоумышленник обнаруживает "висячий" поддомен.

    2. Злоумышленник подготавливает ресурс Azure с тем же полным доменным именем ранее управляемого вами ресурса. В этом примере — app-contogreat-dev-001.azurewebsites.net.

    3. Трафик, отправленный в субдомен greatapp.contoso.com , теперь направляется на ресурс злоумышленника, где он контролирует содержимость.

Захват поддомена с отозванного веб-сайта

Риски захвата поддоменов

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

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

  • Потеря контроля над содержанием поддомена: негативная пресса о неспособности вашей организации обеспечить безопасность контента, ущерб бренду и потерю доверия.

  • Сбор файлов cookie от ничего не подозревающих посетителей: Веб-приложения часто открывают сессионные cookie на поддоменах (*.contoso.com). Доступ к ним может получить любой поддомен. Злоумышленники могут использовать захват субдоменов для создания аутентичной страницы, обманывать ничего не подозревающих пользователей, чтобы они её посещали, и собирать их cookies (даже защищённые куки). Распространённое заблуждение — что SSL-сертификаты защищают ваш сайт и ваши файлы cookie от захвата. Однако злоумышленник может использовать захваченный поддомен для применения и получения действительного SSL-сертификата. Действительные SSL-сертификаты предоставляют им доступ к защищенным файлам cookie и могут дополнительно повысить мнимую законность вредоносного сайта.

  • Фишинговые кампании: злоумышленники часто используют в фишинговых кампаниях поддомены, выглядящие как подлинные. Риск распространяется как на вредоносные сайты, так и на записи MX. MX-записи могут позволить злоумышленникам получать письма, адресованные на легитимные субдомены, связанные с надёжными брендами.

  • Дополнительные риски: Вредоносные сайты могут перерасти в классические атаки, такие как XSS, CSRF, CORS BYPASS и другие.

Обнаружение "висячих" записей DNS

Чтобы найти в организации записи DNS, которые могут быть "висячими", используйте инструменты PowerShell, размещённые в GitHub "Get-DanglingDnsRecords".

Этот инструмент помогает перечислить все домены с CNAME, связанным с существующим ресурсом Azure, созданным в ваших подписках или арендаторах.

Если ваши записи CNAME указаны в других службах DNS и указывают на ресурсы Azure, укажите записи CNAME во входном файле программного инструмента.

Этот инструмент поддерживает ресурсы Azure, перечисленные в следующей таблице. Инструмент извлекает или принимает в качестве входных данных все записи CNAME клиента.

Услуга Тип Свойство FQDN Пример
Azure Front Door (облачное сетевое решение от Microsoft) microsoft.network/frontdoors properties.cName abc.azurefd.net
Хранилище BLOB-объектов Azure майкрософт.хранилище/хранилищныеучетныезаписи properties.primaryEndpoints.blob abc.blob.core.windows.net
Azure CDN microsoft.cdn/profiles/endpoints свойства.hostName abc.azureedge.net
общедоступные IP-адреса; microsoft.network/publicipaddresses properties.dnsSettings.fqdn abc.EastUs.cloudapp.azure.com
Диспетчер трафика Azure microsoft.network/trafficmanagerprofiles properties.dnsConfig.fqdn abc.trafficmanager.net
Экземпляр контейнера Azure microsoft.containerinstance/containergroups properties.ipAddress.fqdn abc.EastUs.azurecontainer.io
Управление API Azure microsoft.apimanagement/service properties.hostnameConfigurations.hostName abc.azure-api.net
Служба приложений Azure microsoft.web/sites properties.defaultHostName abc.azurewebsites.net
Служба приложений Azure — слоты microsoft.web/sites/slots properties.defaultHostName abc-def.azurewebsites.net

Предварительные условия

Выполните запрос от имени пользователя, который имеет:

  • По крайней мере, ролевой доступ Reader к подпискам Azure.
  • Доступ на чтение к Azure Resource Graph.

Если вы глобальный администратор арендатора вашей организации, следуйте рекомендациям в Elevate access, чтобы управлять всеми подписками и группами управления Azure и получать доступ ко всем подпискам вашей организации.

Совет

Учитывайте ограничения на частоту запросов и постраничный вывод в Azure Resource Graph, если у вас крупная среда Azure.

Узнайте подробные сведения о работе с большими наборами данных ресурса Azure.

Чтобы избежать этих ограничений, в инструменте используется пакетная подписка.

Выполнение скрипта

Для получения дополнительной информации о скрипте PowerShell см. Get-DanglingDnsRecords.ps1.

Устранение "висячих" записей DNS

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

  1. Из зоны DNS удалите все записи CNAME, указывающие на полные доменные имена ресурсов, которые больше не нужны.

  2. Чтобы направить трафик к ресурсам, которыми вы управляете, подготовьте дополнительные ресурсы с FQDN, указанными в записях CNAME висячих поддоменов.

  3. Проверьте код приложения на наличие ссылок на конкретные поддомены и обновите неправильные или устаревшие ссылки на поддомены.

  4. Проверьте, произошёл ли какой-либо компромисс, и примите меры в соответствии с процедурами реагирования на инциденты вашей организации. Советы и лучшие практики для расследования:

    Если логика вашего приложения приводит к передаче секретов, таких как учетные данные OAuth, в поддомены или если информация, чувствительная к конфиденциальности, передаётся в эти поддомены, эти данные могут быть раскрыты третьим лицам.

  5. Поймите, почему запись CNAME не была удалена из вашей DNS-зоны при удалении ресурса, и предпринимайте шаги для правильного обновления DNS-записей при удалении ресурсов Azure в будущем.

Защита от появления "висячих" записей DNS

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

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

Включение Microsoft Defender для Службы приложений

интегрированная платформа защиты облачных рабочих нагрузок (CWPP) Microsoft Defender для облака предлагает ряд планов по защите ресурсов и рабочих нагрузок Azure, гибридных и многооблачных ресурсов и рабочих нагрузок.

План Microsoft Defender для Службы приложений включает обнаружение "висячих" записей DNS. Когда вы включите этот план, вы получаете оповещения о безопасности, если отключите сайт App Service, но не удаляете его пользовательский домен из вашего DNS-регистратора.

Защита DNS от Microsoft Defender для облака доступна независимо от того, управляете ли вы доменами через Azure DNS или через внешний регистратор доменов, а также применяется к App Service как на Windows, так и на Linux.

Для получения дополнительной информации об этой функции и других преимуществах этих планов Microsoft Defender см. раздел «Введение в Microsoft Defender for App Service».

Использование записей псевдонимов Azure DNS

Azure DNS alias records может предотвратить зависающие ссылки, связывая жизненный цикл DNS-записи с ресурсом Azure. Например, рассмотрим запись DNS, которая квалифицирована как запись-псевдоним и указывает на общедоступный IP-адрес или профиль диспетчера трафика. Если удалить эти базовые ресурсы, запись псевдонима DNS станет пустым набором записей. Запись псевдонимов DNS больше не ссылается на удалённый ресурс. Алиасные записи имеют ограничения в том, что они могут защищать. В настоящее время список ограничен следующим образом:

  • Azure Front Door (облачное сетевое решение от Microsoft)
  • Профили диспетчера трафика
  • Конечные точки сети (CDN) доставки содержимого Azure
  • Общедоступные IP-адреса

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

Дополнительные сведения см. в статье Возможности записей-псевдонимов Azure DNS.

Используйте проверку пользовательского домена в Службе приложений Azure.

При создании DNS-записей для Служба приложений Azure создайте asuid.{subdomain} запись TXT с идентификатором верификации домена. Когда такая запись TXT существует, ни одна другая подписка Azure не может проверить пользовательский домен или взять его под контроль.

Эти записи не мешают кому-либо создать экземпляр Служба приложений Azure с тем же именем, что и в вашей записи CNAME. Без возможности доказать право собственности на доменное имя злоумышленники не могут получать трафик или контролировать контент.

Для получения дополнительной информации см. Сопоставление существующего пользовательского DNS-имени с Служба приложений Azure.

Создание и автоматизация процессов для устранения угрозы

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

  • Чтобы создать процедуры для предотвращения:

    • Обучите разработчиков приложений перенаправлять адреса при удалении ресурсов.

    • Добавьте задачу "Удалить запись DNS" в списке обязательных проверок при выводе службы из эксплуатации.

      • Добавьте блокировки удаления для всех ресурсов, у которых есть настраиваемая запись DNS. "Блокировка на удаление служит индикатором того, что сопоставление должно быть удалено до аннулирования ресурса." Такие меры работают только в сочетании с внутренними образовательными программами.

  • Создание процедур для обнаружения:

    • Регулярно просматривайте свои записи DNS, чтобы убедиться, что поддомены сопоставлены с ресурсами Azure, а также что:

      • Наличие: Проверьте свои зоны DNS на наличие ресурсов, указывающих на поддомены Azure, такие как *.azurewebsites.net или *.cloudapp.azure.com (см. справочный список доменов Azure).
      • Вы владеете: Подтвердите, что вы владеете всеми ресурсами, на которые нацелены ваши DNS-поддомены.

    • Поддерживайте каталог услуг конечных точек полного доменного имени (FQDN) Azure и владельцев приложений. Используйте Azure Resource Graph, портал Azure или другой процесс инвентаризации активов, чтобы регулярно экспортировать информацию о конечных точках FQDN для доступных ресурсов. Если у вас есть доступ ко всем подпискам в вашем арендаторе, включите все подписки в инвентарь. Если нет, задокументируйте, какие подписки покрывает инвентарь.

  • Создайте процедуры для исправления:

    • Когда ваша команда обнаруживает висячие DNS-записи, проверьте, не произошла ли какая-либо компрометация.
    • Выясните, почему адрес не был перенаправлен при удалении ресурса.
    • Удалите запись DNS, если она больше не используется, или укажите на правильный ресурс Azure (FQDN), принадлежащий вашей организации.

Очистите указатели DNS или вернуте DNS

При удалении классического облачного сервиса Azure сохраняет соответствующее DNS-имя в соответствии с политикой Azure DNS. В период резервирования повторно использовать это DNS-имя могут только подписки, принадлежащие арендатору Microsoft Entra той подписки, которой это DNS-имя изначально принадлежало. После истечения срока бронирования любая подписка Azure может претендовать на DNS-имя. Резервирование DNS даёт вам время очистить ассоциации или указания на имя DNS, либо вернуть имя DNS в Azure. Удаляйте нежелательные DNS-записи как можно скорее. Вы можете получить зарезервированное DNS-имя, добавив имя облачного сервиса в DNS-зону этого облака.

  • Общедоступно: cloudapp.net
  • Лунный кекс: chinacloudapp.cn
  • Фэрфакс: usgovcloudapp.net
  • Черный лес: azurecloudapp.de

Например, размещённый сервис в Public с именем test имеет DNS-имя test.cloudapp.net.

Пример: подписки A и B являются единственными подписками, относящимися к арендатору Microsoft Entra AB. Подписка A содержит классический облачный сервис с именем test и DNS-именем test.cloudapp.net. Когда вы удаляете облачный сервис, Azure сохраняет DNS-имя test.cloudapp.net. В период бронирования только подписка A или подписка B может претендовать на DNS-имя test.cloudapp.net , создав классический облачный сервис под названием test. Никакие другие подписки не могут получить это. После окончания периода резервирования любая подписка Azure может воспользоваться test.cloudapp.net.

Следующие шаги

Дополнительные сведения о связанных службах и функциях Azure, которые можно использовать для защиты от захвата поддоменов, см. на следующих страницах.

  • Last updated on