微软修复不力 谷歌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 。

查看评论
created by ceallan