防止悬空的 DNS 记录，并避免子域名接管

本文介绍了子域名接管的常见安全威胁以及你可以采取的缓解措施。

什么是子域接管？

子域接管是那些经常创建和删除大量资源的组织常见且严重的威胁。 当 DNS 记录指向已解除预配的 Azure 资源时，可能会发生子域名接管。 这类 DNS 记录也称为“悬空 DNS”记录。 CNAME 记录特别容易受到此威胁的攻击。 子域接管使恶意操作者能够将专用于某组织的域的流量重定向到一个执行恶意活动的站点。

子域名接管的常见场景：

  1. 创建：

    1. 你预配了一个完全限定域名 (FQDN) 为 app-contogreat-dev-001.chinacloudsites.cn 的 Azure 资源。

    2. 你在 DNS 区域中为子域 greatapp.contoso.com 分配一条 CNAME 记录，将流量路由到你的 Azure 资源。

  2. 取消预配：

    1. Azure资源在不再需要后会被取消或删除。

      此时，应从 DNS 区域删除 CNAME 记录 greatapp.contoso.com。 如果未删除 CNAME 记录，则该记录将播发为活动域，但不会将流量路由到活动的 Azure 资源。 现在你有一个“悬空”的 DNS 记录。

    2. 悬空子域名 greatapp.contoso.com 现已存在被接管的风险，可通过将其分配给另一个 Azure 订阅中的资源来实现接管。

  3. 接管：

    1. 威胁行为者使用常见的方法和工具发现了悬空子域名。

    2. 威胁行为者预配了一个 Azure 资源，该资源具有与你先前控制的资源相同的 FQDN。 在本示例中为 app-contogreat-dev-001.chinacloudsites.cn。

    3. 发送到子域 greatapp.contoso.com 的流量现在会被路由到恶意行为者的资源，在那里他们控制内容。

来自已停用网站的子域名接管

子域接管造成的风险

当 DNS 记录指向不可用的资源时，记录本身应从 DNS 区域中移除。 如果不删除该记录，它就会成为“悬空 DNS”记录，从而可能引发子域名接管。

悬空的 DNS 记录可能使威胁行为者能够接管相关的 DNS 名称，并用于托管恶意网站或服务。 组织子域中的恶意页面和服务可能导致以下结果：

  • 失去对子域名内容的控制：关于贵组织无法保护内容的负面新闻、品牌损害以及信任丧失。

  • 从缺乏戒备心的访问者处获取 Cookie 信息：Web 应用通常会向子域 (*.contoso.com) 公开会话 Cookie。 任何子域都可以访问它们。 威胁行为者可以通过子域名接管来构建看起来真实的页面，欺骗毫无防备的用户访问，并收集他们的Cookie（甚至包括安全Cookie）。 一个常见的误解是，SSL 证书可以保护你的网站和用户的 Cookie 免受接管。 然后，威胁操纵者可能会使用劫持的子域来申请和接收有效的 SSL 证书。 有效的 SSL 证书使他们能够访问安全 Cookie，而且可进一步使恶意网站看起来更合法。

  • 钓鱼活动：恶意行为者常利用看起来真实的子域名进行钓鱼活动。 风险不仅适用于恶意网站，也涉及MX记录。 MX记录可能使威胁行为者接收指向与可信品牌关联的合法子域名的邮件。

  • 进一步风险：恶意网站可能升级为其他经典攻击，如 XSS、CSRF、CORS 绕过等。

识别悬空的 DNS 条目

若要识别组织中可能处于悬空状态的 DNS 记录，请使用 Microsoft 托管在 GitHub 上的 PowerShell 工具 "Get-DanglingDnsRecords"。

这个工具可以帮助你列出所有带有 CNAME 的域名，这些域名与你在订阅或租户中创建的现有 Azure 资源关联。

如果您的 CNAME 记录位于其他 DNS 服务中并指向 Azure 资源，请在输入文件中向该工具提供这些 CNAME 记录。

该工具支持下表中列出的 Azure 资源。 该工具会提取所有租户的 CNAME 或将其作为输入。

服务 类型 FQDN 属性 示例
Azure Front Door microsoft.network/frontdoors properties.cName abc.azurefd.net
Azure Blob 存储 microsoft.storage/storageaccounts properties.primaryEndpoints.blob abc.blob.core.chinacloudapi.cn
Azure CDN microsoft.cdn/profiles/endpoints properties.hostName abc.azureedge.net
公共 IP 地址 microsoft.network/publicipaddresses properties.dnsSettings.fqdn abc.chinanorth2.chinacloudapp.cn
Azure 流量管理器 microsoft.network/trafficmanagerprofiles properties.dnsConfig.fqdn abc.trafficmanager.cn
Azure 容器实例 microsoft.containerinstance/containergroups properties.ipAddress.fqdn abc.chinanorth2.azurecontainer.io
Azure API 管理 microsoft.apimanagement/service properties.hostnameConfigurations.hostName abc.azure-api.net
Azure App 服务 microsoft.web/sites properties.defaultHostName abc.chinacloudsites.cn
Azure 应用服务 - 部署槽 microsoft.web/sites/slots properties.defaultHostName abc-def.chinacloudsites.cn

先决条件

以具有下列权限的用户身份运行查询：

  • 至少具有对 Azure 订阅的 Reader 角色访问权限。
  • 可对 Azure Resource Graph 进行读取访问。

如果你是组织租户的全局管理员，请按照Elevate Access中的指导管理所有Azure订阅和管理组，从而获得组织所有订阅的访问权限。

提示

如果你有大型 Azure 环境，考虑 Azure Resource Graph 的限速和分页限制。

详细了解如何使用大型 Azure 资源数据集。

该工具使用订阅批处理来避免这些限制。

运行脚本

关于PowerShell脚本的更多信息，请参见 Get-DanglingDnsRecords.ps1。

修复悬空的 DNS 记录

查看 DNS 区域，并识别悬空或被接管的 CNAME 记录。 如果你发现悬浮或被接管的子域名，请移除易受影响的子域名，并通过以下步骤降低风险：

  1. 在 DNS 区域中，删除所有指向不再预配的资源的 FQDN 的 CNAME 记录。

  2. 为了使流量能够路由到你控制的资源，请使用悬空子域的 CNAME 记录中指定的 FQDN 来预配更多资源。

  3. 查看应用程序代码中对特定子域的引用，并更新所有错误或过期的子域引用。

  4. 调查是否发生了任何泄露，并根据贵组织的事件响应程序采取行动。 关于调查的技巧和最佳实践：

    如果你的应用逻辑导致秘密（如OAuth凭证）被发送到悬浮子域，或者隐私敏感信息被传输到这些子域，这些数据可能会暴露给第三方。

  5. 了解为什么在你取消配置资源时，CNAME记录没有从你的DNS区域移除，并采取措施确保未来Azure资源被取消配置时，DNS记录能得到适当更新。

防止悬空的 DNS 记录

将用于防止悬空 DNS 记录及其导致的子域名接管的流程作为安全计划的关键组成部分。

以下章节介绍了Azure服务的功能，这些功能有助于制定预防措施。 通过组织的最佳实践或标准操作程序，建立其他防止此类问题的方法。

启用 Microsoft Defender 以保护应用服务

Microsoft Defender for Cloud 的集成云工作负载保护平台 (CWPP) 提供了一系列计划来保护 Azure、混合和多云资源和工作负载。

适用于应用服务的 Microsoft Defender 计划包括无关联的 DNS 检测。 启用该计划后，如果你关闭了 App Service 网站但没有从你的 DNS 注册商中移除其自定义域名，就会收到安全警报。

无论你是用Azure DNS还是外部域名注册商管理域名，Microsoft Defender for Cloud的悬挂式DNS保护都适用，并且适用于Windows和Linux上的App Service。

有关此功能及这些 Microsoft Defender 计划的其他优势的更多信息，请参见《Microsoft Defender for App Service 介绍》。

使用 Azure DNS 别名记录

Azure DNS别名记录可以通过将DNS记录的生命周期与Azure资源耦合，防止悬挂引用。 例如，考虑这样一条 DNS 记录：它被指定为别名记录，用于指向公用 IP 地址或流量管理器配置文件。 如果删除这些基础资源，DNS 别名记录会变成空的记录集。 DNS别名记录不再引用已删除的资源。 别名记录可保护的内容有限。 目前名单仅限于：

  • Azure Front Door
  • 流量管理器配置文件
  • Azure 内容分发网络 (CDN) 终结点
  • 公共 IP

尽管目前服务有限，但尽可能使用别名记录来防御子域名被侵占。

欲了解更多信息，请参见 Azure DNS 别名记录功能。

使用 Azure 应用服务的自定义域验证

当你为 Azure 应用服务 创建 DNS 条目时，asuid.{subdomain}创建一个带有域验证 ID 的 TXT 记录。 当存在这样的TXT记录时，其他Azure订阅无法验证或接管该自定义域名。

这些记录并不妨碍有人创建与你CNAME条目中名称相同的Azure 应用服务实例。 如果无法证明域名所有权，恶意分子就无法接收流量或控制内容。

更多信息请参见“将现有自定义 DNS 名称映射到 Azure 应用服务。

建立并自动执行缓解威胁的流程

开发者和运营团队应运行清理流程，以避免存在悬而未决的DNS威胁。 以下做法有助于您的组织避免这一威胁。

  • 创建预防过程：

    • 训练应用程序开发人员在每次删除资源时都重新路由地址。

    • 将“删除 DNS 项”放入停用服务时需进行的检查的列表中。

      • 给任何有自定义DNS条目的资源添加 删除锁 。 删除锁表明，在取消预配资源之前，必须先删除映射。 这类措施只有与内部教育项目结合时才有效。

  • 创建发现过程：

    • 定期查看 DNS 记录，确保所有子域都映射到以下 Azure 资源：

      • 存在：查询 DNS 区域以获取指向Azure子域（如 *.chinacloudsites.cn 或 *.chinacloudapp.cn）的资源。
      • 你拥有：确认你拥有所有你的DNS子域名所针对的资源。

    • 维护包含 Azure 完全限定的域名 (FQDN) 终结点和应用程序所有者的服务目录。 使用Azure Resource Graph、Azure门户或其他资产清单流程，定期导出FQDN端点信息，以获取可访问资源。 如果你能访问租户中的所有订阅，请将所有订阅纳入库存。 如果没有，记下库存涵盖的订阅内容。

  • 创建修正过程：

    • 当你的团队发现悬而未决的DNS条目时，调查是否发生了任何入侵。
    • 调查停用资源时未重新路由地址的原因。
    • 如果不再使用 DNS 记录，请将其删除，或将其指向贵组织所拥有的正确 Azure 资源 (FQDN)。

清理DNS指针或重新夺回DNS。

当你删除经典的云服务资源时，Azure会根据Azure DNS策略保留对应的DNS名称。 在保留期内，只有属于最初拥有该 DNS 名称的订阅所属的 Microsoft Entra 租户的订阅，才能重用该 DNS 名称。 预留期满后，任何 Azure 订阅都可以申领该 DNS 名称。 DNS 预留可让你有时间清理与该 DNS 名称相关的关联关系或引用，或者在 Azure 中重新取得该 DNS 名称。 尽快删除不需要的DNS条目。 你可以通过将云服务名称附加到该云的DNS区域来推导出保留DNS名称。

  • 月饼： chinacloudapp.cn

例如，名为 test Mooncake 的托管服务具有 DNS 名称 test.chinacloudapp.cn。

示例：订阅 A 和 B 是仅有的属于 Microsoft Entra 租户 AB 的订阅。 订阅 A 包含一个名为 test 的经典云服务，其 DNS 名称为 test.chinacloudapp.cn。 当你删除云服务时，Azure会保留DNS名称test.chinacloudapp.cn。 在保留期内，只有订阅 A 或订阅 B 可以通过创建名为 test.chinacloudapp.cn 的经典云服务来声明 DNS 名称 test。 其他订阅均无法申领。 预留期结束后，任何 Azure 订阅都可以申领 test.chinacloudapp.cn。

后续步骤

若要详细了解可用于防止子域接管的相关服务和 Azure 功能，请参阅以下页面。

  • Last updated on