Azure 网络服务标签的指南改进

概要

Microsoft Security Response Center (MSRC) 于2024年1月收到行业合作伙伴Tenable的通知，指出使用服务标签功能可能导致Web资源的跨租户访问风险。Microsoft感谢Tenable强调服务标签的使用方式和预期目的容易被误解，为Azure社区做出了宝贵贡献。Microsoft最初确认了此漏洞并向Tenable支付了奖金，但进一步调查Tenable的报告后发现，服务标签按设计工作，需要通过服务文档明确传达最佳实践，正如与Tenable后续沟通中所传达的。

跨租户访问通过身份验证防止，因此仅在没有使用身份验证时才会出现问题。然而，此案例突显了使用服务标签作为检查入站网络流量机制的内在风险。服务标签不应被视为安全边界，而应仅作为与验证控制结合的路由机制使用。服务标签的滥用或恶用尚未由第三方报告，Microsoft的调查也未确认。

一如既往，强烈建议对资源使用多层安全措施，如网络流量监控和身份验证。响应Tenable的报告，Microsoft更新了文档以通知客户服务标签的功能。

此服务标签文档更新的目的是加深客户对服务标签及其功能的理解。因此，客户无需采取行动，Azure门户也不会提供额外消息。但Microsoft强烈建议积极审查服务标签的使用，并验证安全措施以仅对服务标签的可信网络流量进行身份验证。

技术细节

服务标签是表示许多Azure服务IP地址块的便捷方法。资源可以使用服务标签在防火墙规则中引用Azure服务，例如允许特定服务的流量访问资源。

其中一些服务允许通过服务标签的入站流量，并包括控制Web请求部分（如URL路径、目标主机等）的功能。如果配置为允许服务标签的流量且未进行其他身份验证，租户A的攻击者可能使用Web请求访问租户B的资源。

在这种情况下，影响部分取决于以下因素：

• 受攻击服务自身是否进行身份验证
• 攻击者可以控制的请求体量
• 攻击者是否可以查看响应内容

示例：Azure Monitor 可用性测试

例如，Azure Monitor 可用性测试服务具有ApplicationInsightsAvailability服务标签，用户可以通过防火墙配置Web测试以访问服务端点并执行综合监控。这些Web测试使用共享基础设施中的相同公共IP地址调用用户的服务端点，因此用户可以从其他Azure Monitor 可用性测试订阅配置Web请求以访问服务端点。此行为使得恶意行为者可能向其他用户的服务端点发送Web请求，并在以下情况下应用程序处理意外Web请求：

• 恶意行为者可以访问启用了ApplicationInsightsAvailability服务标签的租户，且
• 目标服务端点不执行自己的身份验证检查

客户指南

服务标签表示特定Azure服务的IP地址范围，用于防火墙过滤器、网络安全组（NSG）、用户定义路由（UDR）等网络配置。服务标签的此功能对于允许Azure服务与用户服务端点之间的网络流量至关重要。考虑到服务标签的灵活用例，客户需要评估跨租户网络流量和服务的特定场景。

服务标签不是保护入站流量的完整方法，也不能替代防止Web请求相关漏洞的输入验证。输入验证用于确保流量来源和发送者。为实现分层网络安全方法，需要实施额外的身份验证和授权检查。

强烈建议Azure客户审查虚拟网络服务标签的使用，并评估是否需要采取额外措施保护Azure租户间的网络流量。客户在审查服务标签使用后，可以执行以下操作：

• 查看新的服务标签最佳实践文章，并遵循服务提供的特定指南（如有）。
• 审查Azure安全基础文档，确保Azure平台和基础设施考虑并设置了通用安全最佳实践。
• 查看Azure Monitor文档，确保Azure平台和基础设施启用了适合系统事件收集、分析和响应的监控控制。

示例：使用身份验证检查的Azure Monitor 可用性测试

Azure Monitor 可用性测试为客户提供监控资源正常运行时间的手段。客户应在资源监控策略中考虑这一点。将Azure Monitor 可用性测试与相关服务标签结合使用，可确保遵循标准监控策略。

为防止ApplicationInsightsAvailability服务标签向服务端点发送不必要的网络流量，可以创建令牌并将其作为HTTP头添加到可用性测试中。然后，服务可以验证传入请求的HTTP头，以认证流量来自可用性测试。因此，所有其他没有自定义HTTP头的请求将被拒绝并丢弃。有关Azure Monitor 可用性测试的此应用层安全控制的详细信息，请参阅此处。

此外，客户可能遇到以下场景：公司A向多个行业合作伙伴提供API，供其服务和应用程序使用。这些合作伙伴可能希望通过Azure Monitor 可用性测试监控公司A的API正常运行时间。因此，公司A需要确定其API的资源监控策略以及向行业合作伙伴传达该策略的方式。

遵循安全设计原则，公司A可以实施HTTP头验证检查。公司A的资源监控策略可确保仅具有自定义头的行业合作伙伴可以访问，保证安全协作。或者，公司A可能不要求自定义头，而是使用自己的身份验证方法，允许任何人使用Azure Monitor 可用性测试监控API。

Microsoft的响应和时间线

Microsoft在收到此问题后采取了以下措施：

• 执行了此问题的全面变体调查、遥测调查和工程评审，影响了缓解措施。
• 更新了具有入站服务标签的Azure服务的文档，以包含有关服务标签用例和审查网络流量的指南信息。
• 在Azure中，将服务标签的最佳实践文档化为通用文章。

提供了与此问题相关的主要事件时间线，强调了为增加客户可用的文档以防止此问题的方法：

• 2024年1月24日：Tenable通过MSRC研究员门户报告了潜在安全漏洞。
• 2024年1月31日：MSRC确认了观察到的漏洞，并向Tenable授予了奖金。
• 2024年2月2日：Microsoft确认了此问题，并开始执行全面变体调查、遥测调查和工程评审以确定缓解措施。
• 2024年2月26日：Microsoft宣布了解决此问题的客户披露策略和增强Azure服务的服务标签文档。
• 2024年3月6日：Microsoft和Tenable就此问题达成协调披露协议。
• 2024年3月31日：Microsoft完成了此问题的全面变体调查、遥测调查和工程评审。
• 2024年4月3日：Microsoft书面反馈Tenable此问题不是SSRF漏洞。
• 2024年5月3日：Microsoft书面反馈Tenable此问题不是防火墙绕过漏洞。
• 2024年5月10日：Microsoft在Microsoft Learn上发布了服务标签文档的更改。
• 2024年6月3日：Microsoft和Tenable公开此问题。

致谢

感谢Tenable提供调查此报告的机会，并感谢根据Microsoft漏洞奖励计划条款进行安全安全调查。建议所有研究者在协调漏洞披露（CVD）下与供应商合作，并遵守渗透测试的参与规则，以确保安全调查期间不影响客户数据。

Microsoft与第三方研究者和安全社区人员合作有着悠久历史，这反映在安全未来倡议（SFI）中，进一步提高了与安全研究者合作方式以及应对产品和平台服务相关风险的透明度。Microsoft承诺分享分析研究者主张的结果，并向客户和社区提供建议。

参考

• 如有疑问，请在Azure门户中通过aka.ms/azsupt开设支持案例。
• 有关Azure虚拟网络服务标签的详细信息，请参阅“Azure服务标签概述 | Microsoft Learn”。
• 有关Azure安全基础的详细信息，请参阅“Azure安全基础文档”。
• 有关Azure Monitor的详细信息，请参阅“Azure Monitor文档 | Microsoft Learn”。