共计 2810 个字符，预计需要花费 8 分钟才能阅读完成。
2024 年末，Unit 42 的研究人员发现 Azure OpenAI 的域名系统（DNS）解析逻辑存在一个潜在风险，可能导致跨租户数据泄露和中间人（MitM）攻击。这一问题源于 Azure OpenAI API 与用户界面（UI）在处理域名分配时的配置不一致。
尽管 UI 要求每个 OpenAI 实例使用唯一的自定义域名，但 API 并未强制执行这一要求。这导致多个租户可以共享相同的自定义域名，可能解析到一个不受信任的外部 IP 地址。
这种行为带来的风险包括潜在的数据拦截和服务中断。该配置错误可能使攻击者将原本指向 Azure OpenAI 端点的 API 调用、敏感数据和凭证重定向到 Azure 网络外的攻击者控制服务器。
微软已修复此问题。受影响的域名现在解析到合法的 Azure 资源或无法解析。
这一发现强调了持续监控云配置、验证 DNS 解析并仔细检查 API 驱动的工作流程的重要性。安全团队应定期审计托管服务的配置错误，以防止即使是常规设置也可能引入不可预见的风险。
组织可以通过 Unit 42 云安全评估 获得帮助，评估其云安全状况。
背景
在以往的研究中，Unit 42 经常专注于发现高影响力的漏洞和安全问题。但有时，像被忽视的配置错误这样简单的事情也可能威胁整个云环境。这项具体研究涉及 Azure 的 OpenAI 实现。根据 文档，“通过 Azure OpenAI，客户可以获得 Microsoft Azure 的安全功能，同时运行与 OpenAI 相同的模型。Azure OpenAI 提供私有网络、区域可用性和负责任的 AI 内容过滤。”
本文描述了他们在 Azure OpenAI 的 DNS 解析逻辑中发现的一个微妙但影响重大的缺陷——该缺陷可能导致跨租户数据泄露和 MitM 攻击。
他们发现，自定义域名的强制要求（确保账户使用唯一的域名）在特定条件下失效，DNS 查找解析到 Azure 控制之外的不受信任的 IP 地址。这一发现之所以引人注目，不是因为其严重性，而是因为它的存在本身。
该缺陷可能使攻击者无需破坏单个租户账户即可拦截 API 调用、凭证和敏感数据。
UI 与 API：目标相同，规则不同
在创建 Azure OpenAI 服务时，UI 要求用户指定唯一的自定义域名，如 margol.openai.azure[.]com。如果该名称已被使用，Azure 会拒绝请求并返回错误消息，表明该名称已被使用，如图 2 所示。
尽管从门户 UI 创建账户时需要自定义域名，但通过 API 创建的账户并不需要自定义域名。如果通过 API 创建账户时未指定自定义域名，则可以通过默认域名 `
跨租户 DNS 解析问题：当 DNS 指向 Azure 外部
有一个特定的自定义域名可以应用于多个 Azure OpenAI 实例：test**.**openai.azure[.]com。该缺陷允许多个服务共享相同的自定义域名，可能影响所有 Azure 租户。
他们发现，解析 test.openai.azure[.]com URL 会指向一个特定的 IP 地址 66.66.66[.]66。如图 4 所示，每个 DNS 提供商都将该域名解析到该特定 IP 地址。这不是一个 Azure IP 地址。它属于一个外部的、非 Azure 的互联网服务提供商（ISP）。
这带来了安全风险，因为将敏感数据（如 API 调用、数据文件和 API 密钥）发送到具有该自定义域名的 OpenAI 端点时，这些数据可能会暴露给不受信任的实体。解析到非 Azure IP 地址还可能在威胁行为者监听该 IP 地址的 HTTP 调用时，导致 MitM 攻击的潜在漏洞。成功的 MitM 攻击将对所有使用 test.openai.azure[.]com 自定义域名的 OpenAI 端点的 Azure 租户构成威胁。
微软的回应
在收到初始报告后的几天内，微软解决了与 test.openai.azure[.]com 域名相关的 DNS 解析问题，并采取了纠正措施。具体而言，他们删除了指向 66.66.66[.]66 的 DNS A 记录，该记录曾用于内部活动。
微软对报告的回应称，“……身份验证机制在其系统中始终得到执行，以防止未经授权的访问。”此外，该域名现在要么解析到合法的生产 API 管理实例，要么无法解析，消除了滥用的可能性。
披露时间表
- 2024 年 10 月 28 日 – 向微软安全研究中心（MSRC）提交初始报告
- 2024 年 10 月 29 日 – 微软确认报告并开启案例（MSRC 92222）
- 2024 年 10 月 30 日 – Palo Alto Networks 研究团队观察到配置错误已得到解决
- 2024 年 11 月 22 日 – MSRC 关闭案例并表示问题已解决
安全研究人员的启示
默认 DNS 设置和域名强制策略等基本设置可能产生重大影响，无意中将多个租户暴露在共享风险中。这些基本领域的缺陷可能演变为重大安全问题，影响依赖共享基础设施的所有租户。
作为云安全研究人员，他们应系统地检查这些配置的每个方面，无论它们看起来多么常规。这有助于在影响更广泛环境之前识别和缓解隐藏风险。这种尽职调查确保了互联系统的安全性和完整性。
安全从业者的启示
虽然共享基础设施的风险通常较低，但它们确实存在。对云服务提供商（CSP）逻辑缺陷或托管资源漏洞等风险的认识至关重要。
本文展示了即使组织遵循最佳实践，安全问题仍可能出现。在这种情况下，跨租户缺乏唯一域名以及“测试”案例的 DNS 解析冲突可能危及云托管资源。
定期监控和验证云资源的 DNS 解析，确保关联的 IP 地址属于 CSP。不要假设所有托管资源都是安全的。仔细检查 API 驱动的工作流程。
结论
随着云服务支撑关键业务运营，他们的 Azure OpenAI 发现突显了保护共享基础设施免受配置错误影响的更广泛挑战。微软迅速修复他们发现的问题，展示了行业防止攻击者利用新发现的漏洞和安全问题的承诺。
这一发现强化了主动安全实践的重要性，如持续监控、API 行为审计和 DNS 解析验证。安全从业者必须保持警惕，因为即使是配置逻辑中的微小差距也可能在多个租户之间产生连锁风险。启示：信任但需验证。在云安全中，假设可能代价高昂。
Palo Alto Networks 的缓解措施
组织可以通过 Unit 42 云安全评估 获得帮助，评估其云安全状况。
如果认为可能已受到威胁或有紧急事项，请联系 Unit 42 事件响应团队 或拨打：
- 北美：免费电话：+1 (866) 486-4842 (866.4.UNIT42)
- 英国：+44.20.3743.3660
- 欧洲和中东：+31.20.299.3130
- 亚洲：+65.6983.8730
- 日本：+81.50.1790.0200
- 澳大利亚：+61.2.4062.7950
- 印度：00080005045107
Palo Alto Networks 已与网络威胁联盟（CTA）成员分享了这些发现。CTA 成员利用这一情报快速部署对其客户的保护，并系统地破坏恶意网络行为者。了解更多关于 网络威胁联盟 的信息。
其他资源
- Azure 虚拟网络中资源的名称解析 – Microsoft Learn
