CVE-2020-0601：微軟核心加密庫漏洞學習心得

• 2020 年 3 月 17 日
• 筆記

本文作者：jack.zhou（Timeline Sec交流群成員）

本文共2076字，閱讀大約需要6~7分鐘

聲明：請勿用作非法途徑，否則後果自負

0x01 簡介

沒接觸過公鑰簽名信任體系的可能不太好理解這個漏洞。我們就撇開具體算法和PKI公鑰體系，先來簡單說說證書的信任關係是如何建立的。

現實生活中人和人的信任關係，公司與公司的信任關係一開始都是不存在的。人或者公司一開始是通過互相認識交往才彼此建立信任，但這種方法的缺點是人或者公司不可能認識所有其他人或者公司，這時候怎樣才能在不認識的人或者公司之間建立信任關係呢？中心化信任體系是現在比較常見的，比如經過一個雙方都信任的第三方人或者公司介紹來建立信任關係。

同樣在數字世界中，CA證書就擔任着這個第三方角色。當一個受信任CA證書籤名的文件，系統就可以放心的使用該文件；當一個服務器傳遞給客戶端的證書是客戶端信任的CA證書所簽發的，那麼客戶端就信任服務器並和該服務器建立連接。下圖所示的就是不受信任CA簽發證書的網站，訪問時瀏覽器會提示異常，這類網站在網上還是很多的，建議大家訪問的時候小心仔細，不要忽視瀏覽器的提示，bypass訪問。

如下圖：

接下來的問題是操作系統怎樣才確認一個CA證書是可信任的呢？在應用軟件或者操作系統中都有一個信用證書列表，裏面保存着世界上現今公認的權威CA機構所發佈的CA證書。同樣瀏覽器里也有證書管理列表，如下圖。

因此當應用軟件或者系統驗證文件或者服務器證書的簽名時，如果簽名的CA證書在這個列表裏面，那麼軟件或系統就選擇信任該文件或者服務器。大部分瀏覽器都會在信用列表中包含這些權威CA證書，所以如果服務器擁有權威CA證書所簽發的證書，我們的瀏覽器能放心訪問它，比如百度。

0x02 漏洞概述

受CVE2020-0601漏洞影響的系統，在驗證證書籤名時，在證書信用列表中查找受信任CA證書時出現烏龍。偽造的ECC CA證書可以被誤認為可信任的證書，導致該偽造證書籤名的文件能被系統信任。比如，win10中證書MicrosoftECCProductRootCertificateAuthority.pem是在受信任的證書列表中。現在我們根據漏洞，利用算法公式製造出與該證書具有相同公鑰和曲線參數的，除基點G不同的另外一個證書spoofed.pem。操作系統在驗證簽名時會將spoofed.pem證書認為是信任列表中的MicrosoftECCProductRootCertificateAuthority.pem證書，那麼spoofed.pem簽署的文件，系統自然就信任。

0x03 影響版本

目前，支持使用帶有指定參數的ECC密鑰的證書的Microsoft Windows版本會受到影響，包括了Windows 10、Windows Server 2016/2019以及依賴於Windows CryptoAPI的應用程序。

0x04 環境搭建

Windows 10

0x05 漏洞復現

第一類應用應該就是文件簽名這一部分，平時工作中使用的較少，前面基礎部分已經介紹，所以這裡就不再過多描述細節。

第二類應用SSL/TLS，這個是我平時工作相關也是比較感興趣的部分，下面詳細操作一下。

1、到win10開始菜單中輸入certmgr，並打開。

2、在證書信任列表中找到ECC證書MicrosoftECCProductRootCertificateAuthority（理論上其他受信任的ECC證書也行）並導出。

3、將導出的證書傳到自己的kali linux系統中，同時下載poc程序。下載地址：

https://github.com/ollypwn/CurveBall

4、執行poc程序。該程序從導出的ECC證書中獲取公鑰值，然後生成私鑰是1，G就是該公鑰值的私鑰文件。

對比一下證書和生成私鑰文件內容能更好理解。

ECC證書中的公鑰信息：

生成的私鑰文件：

私鑰值是1，對應的公鑰值，G值和ECC證書中的公鑰值是一樣的。

5、 利用生成的私鑰文件生成一個自簽名CA證書，然後簽發一個下級服務證書。

下級證書的私鑰可以隨意。

6、把生成的下級證書cert.crt，其私鑰文件cert.key和我們的ca文件spoofed_ca.crt一起放到HTTP服務器上，配置啟用SSL。這裡是使用的CentOS系統里的Apache，其他服務器軟件應該也是沒問題的。這個比較簡單，就不詳細說明了。

7、在客戶機Win10下的hosts文件里添加配置，將自己服務器地址和域名配對。

作用大家都懂，有條件的可以自己搭建DNS服務器實現。

8、使用Win10的Microsoft Edge瀏覽器訪問我們的HTTP服務器，記得用HTTPS訪問。

我們的私下搭建的服務器騙過了系統的瀏覽器，讓其認為我們的服務器上的證書是系統信任的MicrosoftECCProductRootCertificateAuthority所簽發的，所以信任該服務器站點。不小心的用戶登錄這個網站，不仔細查看證書的話，可能就相信這就是google站點了，因為瀏覽器並沒有報警提示服務器使用的是不可信證書，存在被攻擊的風險。

第三類應用是中間人攻擊。提一點思路，當大家使用Burp Suite代理訪問網站的時候其實就是一種中間人方式。只不過Burp是自己架設的，默認了其行為。如果是攻擊者在中間，那是很危險的。

HTTPS能夠比較好的緩解中間人攻擊，因為中間人沒有服務器的證書，就算中間人偽造了服務器證書，也很難獲取到權威CA證書來簽發。因此當瀏覽器提示CA證書無效時，就有可能存在中間人攻擊。比如，我們使用Burp代理訪問HTTPS網站時，瀏覽器一般都會提示異常，查看證書可以發現是Burp提供的證書，而並非網站自身的證書。當Burp上導入我們上面偽造的spoofed_ca.crt證書時，相信在漏洞的影響下，瀏覽器將不會提示異常。該漏洞將極大的發揮中間人攻擊的作用。

0x05 修復方式

微軟已發佈補丁，更新即可

參考鏈接：

https://news.ycombinator.com/item?id=22048619

https://github.com/ollypwn/CurveBall

https://www.freebuf.com/vuls/225524.html