Поделиться через

Предотвращение "висячих" записей 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). Доступ к ним может получить любой поддомен. Злоумышленники могут использовать захват поддоменов, чтобы создать похожую веб-страницу и обмануть ничего не подозревающих пользователей, чтобы они посетили ее, и собрать файлы 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 клиента.

Услуга Тип FQDN-свойство Пример
Azure Front Door (облачное сетевое решение от Microsoft) microsoft.network/frontdoors properties.cИмя 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

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

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

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

Если вы являетесь глобальным администратором клиента вашей организации, следуйте инструкциям в статье "Повышение доступа" для управления всеми подписками 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, в зависшие поддомены или если конфиденциальная информация передается этим поддоменам, существует возможность того, что эти данные могут быть раскрыты третьим лицам.

  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 в статье Введение в Microsoft Defender для App Service.

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

Записи псевдонимов Azure DNS предотвращают появление "висячих" ссылок, связывая жизненный цикл записи DNS с ресурсом Azure. Например, рассмотрим запись DNS, которая квалифицирована как запись-псевдоним и указывает на общедоступный IP-адрес или профиль диспетчера трафика. Если удалить эти базовые ресурсы, запись псевдонима 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. Этот сценарий получает сведения о конечной точке 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
  • Лунный пряник - chinacloudapp.cn
  • Фэрфакс - 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, которые можно использовать для защиты от захвата поддоменов, см. на следующих страницах.

  • Last updated on