利用CVE-2018-0950漏洞自動竊取Windows密碼

i春秋做家：淺安

0×00 前言

記得還在2016年的時候，個人一個同事那時還在使用CERT BFF(自動化模糊測試工具)，他向我詢問到如何將微軟辦公軟件中看起來可利用的漏洞轉化成能夠運行的病毒程序並進行概念論證。考慮到現代微軟平臺中所使用的隨機空間地址分配策略（ASLR），這項工做的實施並不像從前那麼容易。在某些狀況下，能夠繞過隨機空間地址分配的一種策略是利用內存泄漏來公開內存地址；另外一種方法即是經過漏洞進行暴力破解從而使得隨機空間地址分配策略沒法發揮做用。然而，在這種狀況下，阻力最小的方法即是使用Rich Text Format(RTF)內容來利用對象連接和嵌入技術加載未選擇使用ASLR的庫。

當我開始加入富文本格式和對象連接和嵌入技術時，我發現了比ASLR旁通更嚴重的漏洞。在下文中，隨着個人研究，你將會發現這一缺陷可以致使Windows系統崩潰和密碼被盜等狀況的發生。

在繼續深刻分析個人研究以前，先介紹一下相關基礎知識：

0×01 對象鏈接與嵌入（OLE）

OLE是Microsoft於1990年發佈的一項技術，它容許未來自一個程序的內容嵌入到另外一個程序處理的文檔中。 例如，在Windows 3.x中，Microsoft Write提供了嵌入「畫筆圖片」對象以及「聲音」或「包」的功能。 這些是能夠插入Write文檔中的三個可用的OLE對象：

一旦插入，咱們就有一個嵌入了畫筆內容的文檔。

0×02 服務器報文塊協議(SMB)

SMB是一種協議，它擴展了用於本地文件訪問的DOS API（中斷21h）以包含網絡功能。也就是說，操做者能夠像訪問本地驅動器上的文件同樣訪問遠程服務器上的文件。微軟在Windows for Workgroups3.1中包含了SMB功能，該版本於1992年發佈。

2.1 Microsoft Outlook

Microsoft Outlook是Microsoft Office附帶的電子郵件客戶端。 Outlook包括髮送富文本（RTF）電子郵件的功能。 這些消息能夠包含OLE對象。

當使用Microsoft Outlook客戶端查看電子郵件時，富文本電子郵件將會以更爲酷炫的方式展示郵件內容。

0×03 前述內容小結

你可能已經知道個人想法了，若是仍不明晰，就讓咱們總結一下目前爲止所瞭解到的內容：

1.Microsoft Outlook能夠建立和呈現RTF電子郵件。

2.RTF文檔（包括電子郵件消息）能夠包含OLE對象。

3.因爲SMB，OLE對象能夠位於遠程服務器上。

3.1 觀察Microsoft Outlook行爲

互聯網上的HTML電子郵件比富文本電子郵件更爲常見，所以，讓咱們首先查看在Web服務器上具備遠程圖像的HTML消息時Microsoft Outlook的行爲：

在這裏咱們能夠看到遠程圖像沒有自動加載。爲何會出現這樣的狀況？緣由是若是Outlook容許遠程映像自動加載，它可能會泄露客戶端系統的IP地址和其餘元數據，例如查看電子郵件的時間。 此限制有助於防止電子郵件中使用的網絡錯誤。如今讓咱們以富文本格式的形式來查看一樣的內容，如今它並非遠程圖像文件，而是從遠程SMB服務器上加載的OLE文檔：

這種現象是意料以外的。因爲網絡錯誤的隱私風險，Outlook會阻止遠程Web內容。 可是，若是使用富文本電子郵件，則OLE對象將被加載而沒有用戶交互。讓咱們看一下Wireshark（網絡封包分析軟件）中的流量來弄清因爲這種自動遠程對象加載泄露了什麼內容：

在這裏咱們能夠看到，SMB鏈接正在自動協商。觸發此協商的惟一操做是Outlook對發送給它的電子郵件進行了預覽操做。 在上面的屏幕截圖中，我能夠看到如下內容正在泄露：

一、IP地址

二、域名

三、用戶名

四、主機名

五、SMB會話密鑰

富文本電子郵件中的遠程OLE對象的做用就相似於網絡錯誤中的興奮劑。在2016年底的分析中，我通知了微軟這個問題。

0×04 OLE網絡錯誤的影響

這個錯誤將致使兩個主要的問題，以下所述：

4.1 客戶端崩潰

咱們知道在這一點上，咱們能夠出發Outlook啓動到任意主機的SMB鏈接。2017年2月1日，披露了Windows SMB客戶端漏洞（VU＃867968）。 鏈接到惡意SMB服務器時，Windows會崩潰。若是咱們在Outlook中建立了富文本電子郵件，但指向利用此漏洞的SMB服務器，該怎麼辦？

如上所述，一旦Outlook預覽了這樣一封電子郵件，Windows就會崩潰，出現藍屏死機（藍屏）。除此以外，每次遇到這種狀況後Outlook都會啓動，Windows將再次崩潰，由於Outlook會記住最後一封打開的電子郵件。這至關於拒絕服務攻擊行爲。在這一點上，我與微軟分享了攻擊細節。最終，微軟解決了這個SMB漏洞，幸運的是，咱們沒有據說任何基於郵件的大規模電子郵件攻擊。

4.2 收集密碼哈希值

除了SMB的漏洞以外，我決定深刻挖掘客戶端試圖啓動SMB鏈接到攻擊者服務器的風險。 根據我在Wireshark（網絡封包分析軟件）中看到的，我已經知道它泄露的不只僅是受害者的IP地址。此次我同時使用了Responder）（響應系統）和John the Ripper（快速密碼破解工具）。

首先，我發送了一個富文本電子郵件，該電子郵件具備指向運行響應程序的系統的遠程OLE對象。在響應系統上，我在Outlook中預覽電子郵件後當即看到如下內容：

 

[SMB] NTLMv2-SSP Client   : 192.168.153.136[/size]

[size=3][SMB] NTLMv2-SSP Username : DESKTOP-V26GAHF\test_user[/size]

[size=3][SMB] NTLMv2-SSP Hash     : test_user::DESKTOP-V26GAHF:1122334455667788:571EE693342B161C50A73D502EB49B5A:010100000000000046E1992B4BB2D301FFADACA3241B6E090000000002000A0053004D0042003100320001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D004200310032000800300030000000000000000100000000200000D3BDB30B62A8937256327776471E072C7C6DE9F4F98458D1FEA17CBBB6AFBA770A001000000000000000000000000000000000000900280063006900660073002F003100390032002E003100360038002E003100350033002E003100330038000000000000000000

 

這裏咱們有一個NTLMv2哈希，咱們能夠將它交給John the Ripper（快速密碼破解工具）。 以下所示，我將哈希複製並粘貼到名爲test_user.john的文件中：

 

john test_user.john[/size]

[size=3]Using default input encoding: UTF-8[/size]

[size=3]Loaded 1 password hash (netntlmv2, NTLMv2 C/R [MD4 HMAC-MD5 32/64])[/size]

[size=3]Will run 24 OpenMP threads[/size]

[size=3]Press ‘q’ or Ctrl-C to abort, almost any other key for status[/size]

[size=3]test             (test_user)[/size]

[size=3]Session completed

 

在不到1秒的時間內，我就能夠肯定打開我富文本電子郵件的用戶「test_user」的密碼是「test」。 更強密碼的散列（更長和更多類型的字符）須要更長時間才能破解。我已經作了一些基本的測試，在單箇中檔GPU（NVIDIA GTX 960）上破解8字符密碼的整個解決方案空間須要多長時間：

一、小寫字母 – 16分鐘

二、混合大小寫字母 – 3天

三、混合大小寫字母和數字 – 12天

四、混合大小寫字母，數字和符號 – 1年

以上統計數據是暴力破解隨機生成密碼的最壞狀況。任何文字（好比「test」）或模式（好比「asdf」）的密碼比隨機生成的密碼更容易破解，由於大多數破解工具都有規則來檢查這些事情。

另外，攻擊者能夠訪問具備多個高端GPU的系統，這些GPU能夠將他們的時間縮減爲上述數字的一小部分。不過，添加到密碼長度的每一個字符對暴力破解密碼所需的時間都有指數效應。例如，雖然個人中檔GPU須要1年的時間才能耗盡8個字符的密碼（混合大小寫字母，數字和符號）的整個解決方案空間，但將密碼長度增長到9個字符也會增長耗時，將需84年來獲取所有解決方案空間！

0×05 微軟的修復

微軟針對Outlook自動加載遠程OLE內容（CVE-2018-0950）的問題發佈了一個修復程序。一旦安裝了此修復程序，預覽的電子郵件將再也不自動鏈接到遠程SMB服務器。 此修復有助於防止上面列出的攻擊。但意識到即便使用這個補丁，用戶仍然只需點擊一下便可成爲上述攻擊類型的受害者，這一點很重要。例如，若是電子郵件消息具備以「\\」開頭的UNC樣式連接，則單擊此連接會啓動到指定服務器的SMB鏈接。

其餘詳細信息可在CERT漏洞註釋VU＃974272中找到。

0×06 結論與建議

在Windows平臺上，有幾種方法可使客戶端啓動SMB鏈接。 任什麼時候候SMB鏈接啓動時，客戶端的IP地址，域名，用戶名，主機名和密碼哈希均可能泄漏。 爲了防止涉及致使受害者機器啓動SMB鏈接的攻擊，請考慮如下緩解措施：

安裝Microsoft更新CVE-2018-0950。此更新防止在預覽富文本電子郵件時自動檢索Microsoft Outlook中的遠程OLE對象。 可是，若是用戶單擊SMB連接，此行爲仍會致使密碼散列泄漏。

在您的網絡邊界處阻止入站和出站SMB鏈接。這能夠經過阻止端口445/tcp，137/udp，139/udp以及137/udp和139/udp來完成。

按照Microsoft安全通報ADV170014中的規定，阻止NTLM單點登陸（SSO）身份驗證。從Windows10和Server2016開始，若是建立EnterpriseAccountSSO註冊表值並將其設置爲0，則將禁用外部和未指定網絡資源的SSO身份驗證。經過此註冊表更改，仍然容許訪問SMB資源，但外部和未指定的SMB資源將須要用戶輸入憑據，而不是自動嘗試使用當前登陸的用戶的散列。

假設您的客戶端系統在某個時候會嘗試與攻擊者的服務器創建SMB鏈接。 所以，請確保任何Windows登陸名都有足夠複雜的密碼，以防止破解。如下兩種策略能夠幫助實現這一目標：

1.使用密碼管理器來幫助生成複雜的隨機密碼 此策略能夠幫助確保跨所用資源使用惟一密碼，並確保密碼具備足夠的複雜性和隨機性。

2.使用更長的密碼（使用混合大小寫字母，數字和符號）而不是密碼。這種策略能夠產生使人難忘的憑證，不須要額外的軟件來存儲和檢索。

• 做者：Will Dormann  
• 翻譯：i春秋翻譯小組
• 責任編輯：F0rmat、淺安
• 發表於Vulnerability Discovery
• 轉載請註明來自bbs.ichunqiu.com
• 參考來源：(https://insights.sei.cmu.edu/cer … utlook-and-ole.html)，