谷歌Project Zero再次披露Windows严重漏洞

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

　　过去几年，Project Zero 团队已经曝光过影响Windows10 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 。