微软修复不力 谷歌 Project Zero 再次披露 Windows 中的一个严重漏洞

谷歌旗下的 Project Zero 安全团队，以查找自家和其它公司开发的软件中的漏洞而被人们所熟知。理论上，在 90 天的宽限期内，接到通报的厂商有相对充裕的时间来完成修复。然而在现实生活中，偶尔也会有一些例外情况。比如近日，Project Zero 团队就因为微软修复不力，而选择在 90 天后公开披露 Windows 中的一个严重漏洞。

（来自：Google Project Zero）

过去几年，Project Zero 团队已经曝光过影响 Windows 10 S、macOS 内核、iOS 等平台的严重漏洞。

然而在昨日的“星期二补丁”中，研究人员声称微软未能提供一个完整的修复程序，于是决定公开一个影响各版本 Windows 的“中等”严重性漏洞。

据悉，Project Zero 于 2020 年 5 月 5 日首次将一个身份验证漏洞汇报给了微软 —— 即使应用程序不具备此功能，也可通过用户凭据来绕过网络身份验证。

在对枯燥的技术术语进行抽丝剥茧后，可知问题主要出在旧版 Windows 应用容器可通过单点登录、对用户授予企业身份验证的访问权限（这本该是个受限的敏感功能）。

虽然具有此类缺陷的应用程序不会通过 Windows Store 的审核，但许多企业仍在使用基于侧载的部署方案，因而该漏洞仍需要 Windows 用户提高警惕。

Project Zero 安全研究员 James Forshaw 指出：当应用程序向网络代理提起身份验证时，UWP 网络会错误地将之视作一个例外。

这意味着，只要为 InitializeSecurityContext 指定了有效的目标名称，AppContainer 便可执行网络身份验证，而无论网络地址是否已经代理注册。

结果就是，只要你的应用程序具有不受实际限制的网络访问功能，用户便可指定任意目标名称，对面向网络的资源进行身份验证。

同样的，由于你可指定任意目标名称、并且正在执行实际的身份验证，那注入 SPN 检查和 SMB 签名之类的服务器防护手段都将变得毫无意义。

从理论上来讲，由于防火墙 API 中存在后门，本地攻击者可借助经典版 Edge 浏览器访问本地主机服务、然后找到需要转义的系统服务，从而达到漏洞利用的目的。

更糟糕的是，这只是该漏洞缺陷的一部分。因为即便代理没有正确地处理网络地址，它仍可被绕过。

因其调用了 DsCrackSpn2，将服务类 / 实例：端口 / 服务名形式的网络目标名称划分成了各个组件。

Project Zero 团队甚至附上了概念验证（PoC）的代码，以展示应用程序是如何绕过企业身份验证、以获得更高的特权的。

PoC 尝试列出了 Windows Server 消息块（SMB）的共享，即使操作系统不允许此类访问，本地共享上仍会将它列出。

遗憾的是，尽管 Project Zero 团队为微软提供了标准的 90 天的缓冲、并于 7 月 31 日再次延展了宽限期，以便该公司可在 8 月 Patch Tuesday 推出该修复程序，但微软最终还是让我们感到失望。

该公司确实在昨日发布了 CVE-2020-1509 的修复程序，并对 James Forshaw 的发现表示了感谢，但 Project Zero 团队声称该公司并未彻底修复该缺陷，因其并未纠正 DsDrackSpn2 目标名称解析漏洞。

最终 Project Zero 决定在今日公布这个复杂的漏洞详情，即便普通的“脚本小子”无法轻易利用，但特权提升（即使是本地特权提升）也是相当危险的。

更具微软的安全公告，该问题影响多个 Windows 操作系统版本，包括 Windows Server 2012 / 2016 / 2019、Windows 8.1 / RT 8.1、以及直到 Version 2004 的 Windows 10 。