谷歌旗下的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 。