最后更新于2023年12月27日星期三15:11:19 GMT

3月9日之前, 2023, Microsoft Defender for Cloud错误地将一些Azure虚拟机标记为具有安全的管理端口，包括SSH(端口22/TCP), RDP(端口3389/TCP)和WINRM(端口5985/TCP), 而实际上，这些端口中的一个或多个暴露给了Internet. 当与虚拟机关联的网络安全组(NSG)包含允许从IPv4范围“0”访问这些端口之一的规则时，就会发生这种情况.0.0.0/0”. 只有当端口规则中的源被设置为“Any”的字面别名时，Cloud卫士才会检测开放的管理端口。. 尽管cidr表示的“/0”网络通常被视为“Any”的同义词,“它们在《pg电子游戏试玩》中并不等同于Cloud的逻辑.

请注意，在撰写本文时, 当使用IPv6范围“::/0”作为“any”的同义词时，也会出现同样的问题，微软尚未修复此版本的漏洞.

产品描述

Microsoft Defender for Cloud是一种云安全态势管理(CSPM)解决方案，提供了多种安全功能, 包括在Azure和多云环境中检测错误配置的能力. 云的防御器详细描述在 供应商的网站.

安全组是存在于Azure和Amazon Web 服务 (AWS)云环境中的一个概念. 类似于防火墙, 安全组允许您创建规则，限制哪些IP地址/范围可以访问云环境中一个或多个虚拟机上的哪些端口.

信贷

这个问题是由Rapid7云产品集成高级经理亚伦Sawitsky发现的. 它是按照 Rapid7的漏洞披露策略.

剥削

如果Azure虚拟机与具有“管理端口”的网络安全组相关联，例如RDP(端口3389/TCP上的远程桌面协议)或SSH(端口22/TCP上的安全壳协议)暴露于“Source”的“Any”伪类,“Microsoft Defender for Cloud将创建一个安全建议，以突出管理端口对互联网开放, 这样管理员就可以很容易地识别出他们的环境中存在一个或多个过度暴露的服务器管理端口的虚拟机.

然而, 3月9日之前, 如果将网络安全组配置为将RDP或SSH等“管理端口”暴露为“0”.0.0.0/0,作为源(这是所有可能地址的整个IPv4范围)，没有创建安全建议，并且配置被错误地标记为“健康”.”

效果如下图所示:

因为这个网络范围混乱, Azure用户很容易意外地将管理端口暴露给整个互联网，并逃避Defender for Cloud的检测.

我们怀疑其他用于检查入侵测试“任意性”的Defender for Cloud功能也会受到类似影响, 但我们还没有全面测试这个问题的其他表现.

影响

我们可以想象在两种情况下，Defender for Cloud中的这种意外行为可能对攻击者有用. 第一个, 管理员很可能没有意识到“any”和“0”之间的实际语义差异.0.0.0/0”或“::/0”，因为这些术语在其他网络产品中经常互换使用, 最明显的是, 与配置AWS安全组时一样. 结果是, 合法管理员可能会意外地应用此错误配置, 但仍未被负责监控Defender的云安全建议的人员或流程发现. 这是大多数管理员最可能面临的情况.

更多的恶意, 已经破坏了虚拟azure托管机器的攻击者可以利用这种混淆来避免云防御者的攻击后检测. 这使得重复, 对于更复杂的攻击者来说，从几个不同的来源进行漏洞利用后访问要容易得多. 在这种情况下, “攻击者”通常是内部人员，他们只是为了表面上的美德而颠覆自己的IT安全组织, just-get-it-done原因, 比如在生产环境中测试配置, 但忘记重新限制暴露.

Note that more exotic combinations of subnets could be used to achieve the same effect; for example, 管理员可以定义“0”.0.0.0/1”和“128”.0.0.1/1”和1“0”的效果是一样的.0.0.0/0”源规则. Or, 更聪明的是, 定义一组子网，它们加起来等于“几乎任意”,“这足以让一个深思熟虑的攻击者确保继续, 机警的接触. 然而, 这种配置极不可能偶然实现(如第一种情况所述)。, 因此, 几乎肯定超出了云卫士用例的合理范围. 毕竟, Defender for Cloud旨在捕获常见的错误配置, 不一定是故意让人困惑的构型.

修复

因为Defender for Cloud是一个基于云的解决方案, 用户不需要做任何特别的事情来享受微软更新的好处. 话虽如此, 客户应该记住，当使用IPV6范围::/0作为“any”的同义词时，更新并没有解决问题.结果是, 客户应该在他们的Azure环境中搜索任何配置为允许从“::/0”源进入的安全组，并认真考虑重新配置这些规则，使其更具限制性. 除了, 客户应该定期对他们的云基础设施进行审计和渗透测试，以验证他们的CSPM实际上捕获了常见的错误配置. 我们已经验证了这个问题不会影响Rapid7的InsightCloudSec CSPM解决方案. 除了, 以前在其安全组规则中使用“/0”CIDR符号的Defender for Cloud客户应该检查访问日志，以确保恶意行为者没有逃避Defender for Cloud提供的假定检测功能.

披露时间表

2023年1月:Rapid7云安全研究人员发现了这个问题 亚伦Sawitsky
2023年1月11日，星期三:向微软初步披露
2023年1月12日星期四:供应商进一步解释和验证细节
2023年2月6日，周一:供应商计划修复
2023年3月9日星期四:修复“0”.0.0.由Rapid7确认
2023年3月14日星期二:这一披露