谷歌研究员称 CVE-2020-1509 的补丁不完整，详情和 PoC 已发布
CVE-2020-1509 可导致已经获取 Windows 账户凭据的攻击者向 Windows 本地安全认证子系统服务 (LSASS)发送特殊构造的认证请求，提升权限。
谷歌对该漏洞的评级为“中危”，而微软的评级为“重要”。当用户登录到由 Active Directory 管理的 Windows PC 时，LSASS 是认证用户的关键流程。LSASS 曾被高级黑客用于转储内存凭据在网络横向移动。该 bug 影响所有受支持的 Windows 10 版本，包括最新的2004版在内。
在本例中，鉴于谷歌认为微软的补丁是完整的且据此发布了漏洞详情和 PoC，因此拒绝延迟披露日期的声明可能只是走一个形式。
当地时间周二，Forshaw 将漏洞状态修改为“已修复”，不过几小时后表示，“审计后发现并未完全修复”。谷歌在2020年的漏洞披露策略中表示，“修复方案不完整的详情将告知厂商，并增加到现有报告（可能已公开）中且不再接受新的披露最后期限请求。”
Forshaw 表示，LSASS 并未正确地执行“EnterpriseAuthentication 能力”，从而导致封装在 WindowsAppContainer 沙箱中的任意 UWP 应用（无论来自微软应用商店还是自定义企业 app）通过单点登录方式以用户凭据执行网络认证。
微软在文档中指出，但需要安装业务线应用程序的组织机构认证到网络代理时，会有一个规则例外，但ForShaw 认为这个例外存在问题，“如果目标是一个代理，那么就认证流程通过，即使在并未指定 EnterpriseAuthentication 能力的情况下也不例外。问题在于，即使 LsaplsTargetProxy返回 False，认证也可继续执行，但会设置一个额外标记表示这一状况。我并未发现检查该标记的代码，尽管目前尚不清楚它是否来自 TLS 块，因此难以追踪用途。这意味着 AppContainer 只要为InitializeSecurityContext 指定了合法目标名称，那么就能执行 NetworkAuthentication，而不管该网络地址是否是已注册代理。这可能不是设计使然，但这一行为仅在几行注释中一笔带过，并未详细说明它应如何行动。可能就是设计的原因。”
由于攻击者能够指定任意名称，“只要应用程序用于实际上并未被限制的网络访问能力，就能向面向网络的资源认证”。Forshaw还指出，“另外，因为可以指定任意目标名称，而且正在进行认证，因此服务器保护措施如 SPN检查和 SMB Signing是无意义的。”
谷歌曾在7月末延期了漏洞披露的最后期限，应该是为了让微软在8月更新中提供完整补丁。
具体可见：
https://bugs.chromium.org/p/project-zero/issues/detail?id=2039#c4
题图：Pixabay License
本文由奇安信代码卫士编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 www.codesafe.cn”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的
产品线。