CVE-2020-0601：微软核心加密库漏洞学习心得

本文作者：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