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

  • Статья

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

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

Захват поддоменов — распространенная и серьезная угроза для организаций, которые регулярно создают и удаляют множество ресурсов. Захват поддомена может произойти в том случае, если у вас присутствует запись DNS, указывающая на отозванный ресурс Azure. Такие записи 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 с "dangling".

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

  3. ЗАХВАТ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Service Тип FQDNproperty Пример
Azure Front Door microsoft.network/frontdoors properties.cName abc.azurefd.net
Хранилище BLOB-объектов Azure microsoft.storage/storageaccounts properties.primaryEndpoints.blob abc.blob.core.windows.net
Azure CDN microsoft.cdn/profiles/endpoints properties.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

Необходимые компоненты

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

  • как минимум доступ на чтение к подпискам Azure
  • доступ на чтение к графу ресурсов Azure

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

Совет

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

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

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

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

Дополнительные сведения о скрипте PowerShell Get-DanglingDnsRecords.ps1 и его загрузке с сайта GitHub приведены здесь: https://aka.ms/Get-DanglingDnsRecords.

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

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

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

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

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

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

    Если логика приложения приводит к секретам, таким как учетные данные OAuth, отправляется в поддомены dangling или если конфиденциальные данные конфиденциальной информации передаются этим поддоменам, существует возможность предоставления этих данных третьим лицам.

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

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

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

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

Настройка Microsoft Defender для Службы приложений

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

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

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

Дополнительные сведения об этих и других преимуществах планов Microsoft Defender см. в статье Защита веб-приложений и API-интерфейсов.

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

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

  • Azure Front Door
  • Профили диспетчера трафика
  • Конечные точки сети (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. Этот сценарий получает сведения о конечной точке FQDN ресурсов, к которым у вас есть доступ, и выводит их в CSV-файл. Если у вас есть доступ ко всем подпискам для клиента, сценарий учитывает все эти подписки, как показано в следующем примере сценария. Чтобы ограничить результаты конкретным набором подписок, измените сценарий, как показано ниже.

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

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

Очистка указателей DNS или повторная заявка DNS

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

  • Общедоступная — cloudapp.net
  • Mooncake - chinacloudapp.cn
  • Fairfax - usgovcloudapp.net
  • BlackForest - azurecloudapp.de

Например, размещенная служба в общедоступном имени "test" будет иметь DNS "test.cloudapp.net"

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

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

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