當前位置:
首頁 > 新聞 > CVE-2018-17612漏洞報告

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 瀏覽器接受攻擊者證書


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 嘶吼RoarTalk 的精彩文章:

WordPress殭屍網路攻擊WordPress網站
CVE-2018-19788:UID大於INT_MAX的Linux用戶任意代碼執行漏洞

TAG:嘶吼RoarTalk |