CVE-2018-17612漏洞报告

背景

Trusted Root CA证书存储区是向TLS服务器或软件发布商发布证书的实体，是特定客户端系统信任的，其证书也是本地系统接受和认可的。一般来说，分别有浏览器或操作系统厂商来维护Trusted Root CA证书存储区。

虽然可信系统依赖其中的证书自动管理，但管理员和用户还是可以在系统的Trusted Root CA证书存储区中删除或增加证书。因此，应该经常检查和控制存储区的证书。

研究人员分析发现了一个重要的实现漏洞，即攻击者可以轻易的获取加密植入的根证书的加密签名密钥。然后可以对技术上可信的证书进行签名和发布。受该实现bug影响的用户会成为证书伪造的受害者，攻击者可以发送一个经过可信签名的软件，并伪装成Sennheiser授权的证书管理机构。

Sennheiser情况

Sennheiser HeadSetup SDK支持通过浏览器中的基于web的软件电话来使用本地连接的耳机，通过HTTPS从服务器网站加载。HeadSetup是通过打开本地安全web socket（WSS）来支持该应用场景的。Sennheiser称，浏览器必须能够通过可信的HTTPS连接访问本地web socket以绕过相关浏览器的CORS（跨域资源共享Cross-origin resource sharing）限制。因此，HeadSetup SDK需要本地可信的TLS服务器证书发布给localhost IP address (127.0.0.1)和相关的私钥。

HeadSetup行为

老版本

HeadSetup 7.3使用一个单独的私钥/公钥对和相关的证书，所有软件的安装都是相同的。私钥SennComCCKey.pem保存在文件中，证书保存在SennComCCCert.pem文件中，这两个文件都在HeadSetup的安装文件夹中，如图1所示。

证书是自签名的，证书使用包含常用名组件127.0.0.1的发行者和主题名，并且以标准证书扩展BasicConstraints标记为CA证书，如图2和图3所示。有效期至2027年1月13日。

图1 老版本中的证书和key文件

图2 老版本证书的主题和发行者名

图3 老版本证书的BasicConstraints扩展

虽然指定了CA证书，但HeadSetup软件会把它作为本次安全web socket的TLS服务器证书。为了将其变成可信凭证， HeadSetup安装器会将证书推到本地机器操作系统的trusted root certificate store中。

注：HeadSetup安装器必须以本地管理员权限运行。一旦安装用户确认了软件的安装，就不会有系统弹窗来提示将证书加入trusted root store中，并展示证书的指纹。

新版本

HeadSetup新版本（7.4之后版本）使用两种证书：

· 使用CN SenncomRootCA自签名的CA证书，有效期被标记为2023年7月28日，并被保存在HeadSetup安装文件夹的SenncomRootCA.cert.pem文件中。厂商会保存与该证书相关的私钥。

· 使用SenncomRootCA发行的CN 127.0.0.1的TLS服务器证书，有效期至2018年12月22日，并在HeadSetup安装目录中保存一个名为127.0.0.1.crt.pem的文件夹。相关的私钥保存在HeadSetup安装目录的127.0.0.1.key.pem文件中。

这些证书和相关的密钥对私有安装的软件都是相同的。

HeadSetup软件会将后者的证书作为TLS服务器证书的本地安全web socket。为了将它变成可信凭证，HeadSetup安装器会将SenncomRootCA CA证书推进本地机器Windows系统的trusted root certificate store中。

注：HeadSetup安装器也要以本地管理员权限运行，一旦安装用户确认了软件安装，就不会有系统弹窗来提示将证书加入trusted root store中，并展示证书的指纹。

更新或移除软件

老版本升级到新版本后，HeadSetup安装目录中老版本的证书和密钥会被删除并被新版本的的证书和密钥所替代。在HeadSetup软件的移除过程中，整个HeadSetup安装目录包括证书和密钥文件都会被删除。但CA证书在安装或升级过程的移除过程中都不会加入到本地机器trusted root store中。

PoC利用

本节描述如何在eadSetup 7.3中利用漏洞来进行POC。

提取私钥

SennComCCCert.pem文件含有老版本软件的CA证书，格式是直接可用的OpenSSL PEM。但SennComCCKey.pem并不是直接可用的OpenSSL RSA key。研究人员检查发现这明显是base64编码的。用字符Salted_解码二进制文件，文件前缀说明该文件是用OpenSSL对称加密的。

为了解密文件，需要知道厂商用来加密的加密算法和key。研究人员首先猜测厂商使用的是AES加密算法，128位密钥和CBC模式。在HeadSetup安装目录中，只有一段含有SennComCCKey.pem文件的可执行代码和一个名为WBCCListener.dll的DLL文件。研究人员在该DLL中搜索字符串AES，结果如图4所示。

研究人员发现厂商用于加密的key明文保存在代码中。AES解密后，SennComCCKey.pem文件会变成标准OpenSSL PEM格式的私钥文件，私钥会用其他的密码来保护。研究人员发现密码在配置文件WBCCServer.properties中指定了，如图5所示。

了解了解密OpenSSL私钥文件的AES key和访问私钥的密码后，可用使用标准的OpenSSL命令行来提取CA证书和私钥到PKCS#12文件中。

图4 WBCCListener.dll中的字符串

图5 WBCCServer.properties中的配置设置

创建伪造的可信服务器证书

研究人员将PKCS#12文件和老版本的HeadSetup key和证书导入到CA软件中，然后创建一个新的密钥对，并使用伪造的CA来发行Google、Sennheiser等域名的主机通配符 TLS服务器证书，如图6所示。

图6 伪造的证书

使用的工具

为了完成漏洞利用POC，研究人员将CA证书和相关的私钥导入到一个中间人攻击工具中，这里使用的是mitmproxy。发起ARP欺骗攻击来重定向受害者流量到攻击者代理。在访问TLS安全网站时，受害者浏览器会报告连接是安全的，如图7所示，攻击者就可用嗅探和修改整个连接。

图7 浏览器接受攻击者证书