通過電子郵件遠程獲取NTLM哈希

介紹

幾個月前，CERT/CC的Will Dormann發表了一篇博文 [1]，描述了一種技術，即對手可能會濫用Microsoft Outlook和OLE對象，這是微軟Windows早期的一個特性，迫使操作系統泄漏Net-NTLM哈希。

去年我們撰寫了一篇博文 [2]，通過濫用常見的Web應用程序漏洞（如跨站點腳本（XSS）和伺服器端請求偽造（SSRF））來闡述了NTLM哈希泄漏的一些內容，從而實現了同樣的目標，獲得我們都喜歡且珍惜的系統哈希。除非你熟悉Windows單點登錄如何在公司網路中進行身份驗證，否則我們建議你先閱讀我們之前發布的文章，然後再繼續。

在Blaz Information Security團隊中，我們已經使用了一段時間，成功率很高，類似的技術迫使MS Outlook泄露NTLM哈希，除了閱讀特製的電子郵件之外幾乎沒有其他交互。就在最近，當我們在寫這篇博客時，NCC集團在他們的博客發表[5]了一篇文章，講述了我們已經使用以及其他細節相同的技術，所以我們決定公布我們的解釋，我們使用的方法以及如何減輕這個問題帶來的風險。

SMB-to-NTLM哈希攻擊的簡史

在1997年3月發布到Bugtraq郵件列表中（是的，21年前），Aaron Spangler在Internet Explorer和Netscape Navigator版本中公布了一個漏洞 [3]，該漏洞通過嵌入Error! Filename not specified. 的字樣的帶有SMB共享的"src"值的標籤來實現此種攻擊而不是HTTP或HTTPS頁面。這將強制Windows使用修改後的SMB伺服器啟動NTLM身份驗證，該伺服器可以獲取用戶的Net-NTLM哈希值。

有趣的是，Aaron的Bugtraq帖子也暗示了身份驗證協議的理論缺陷，後來被稱為SMBRelay攻擊，但它們僅在幾年後出現。

臨近2016年，一位名叫ValdikSS的俄羅斯安全研究員在Medium上寫了 [6]似乎是Spangler 19年前所做的同一實驗的現代複製品，對原始攻擊向量幾乎沒有任何修改。

濫用Microsoft Outlook竊取Net-NTLM哈希值

本文所公布的技術要比使用CERT / CC公布的技術更有優勢，利用將OLE對象嵌入到RTF，DOC或PDF中的可能性，可能使受害者對於集成了安全軟體的電子郵件伺服器完全信任。這種技術利用了Outlook的處理帶有圖片的HTML消息和1997年Bugtraq的文章中所描述的方法。嵌入圖片的HTML電子郵件非常流行，特別是在企業環境中，並且不太可能被反病毒軟體和電子郵件網關屏蔽或阻止。

Net-NTLM哈希將通過SMB流量泄露給外部偽造的SMB伺服器，如Responder（我們為了演示選擇使用這個工具），Core Security的Impacket中的smbrelay或ntlmrelay，甚至是自定義SMB伺服器都可以用來作為偽造的SMB伺服器。

簡而言之，攻擊的工作原理是向受害者發送HTML格式的電子郵件，嵌入的圖片指向外部的SMB伺服器。該圖片可以是例如基於HTML的電子郵件簽名。客戶端將自動啟動針對惡意伺服器的NTLM身份驗證，最終泄漏客戶端的哈希值。

在某些情況下，從受害者的角度來看，成功與否取決於客戶端的Outlook是如何配置在HTML格式的電子郵件中渲染圖片的，可能會有關於打開外部內容的警報，這可能暗示這是一個異常行為。然而，對於許多Outlook用戶來說，必須單擊警告以呈現圖片，這是很常見的事情，因此這不會對此利用向量構成較大的障礙。有時我們也會在較慢的連接中從遠程SMB伺服器獲取內容之前注意到一個非常快速的彈出窗口，這也是一種不太可能引起懷疑的常規事件。

即使在某些情況下，這種技術並不像Will Dormann所描述的那樣隱蔽，但事實證明它在我們的許多活動中非常有效，這應該放在你的攻擊工具箱中。

值得注意的是，Net-NTLM哈希不能用於Pass-the-Hash攻擊，與純NTLM哈希不同，它們可以使用像hashcat這樣的現成工具進行中繼（在某些情況下）[9]或破解。

漏洞利用步驟

儘管利用該漏洞所需要的只是發送一封HTML格式的電子郵件，這意味著可以使用任何電子郵件客戶端甚至腳本來自動化這種攻擊，在本節中我們將描述如何實現這一點。我們打算使用Microsoft Outlook本身來利用這種漏洞。

1）創建包含以下內容的HTML文件：

Test NTLM leak via Outlook

上面的IP地址僅供參考，並僅在我們的實驗室中使用。它可以是任何IP或主機名，包括遠程地址。

2）向目標創建電子郵件。將HTML有效載荷添加為附件，但使用「作為文本插入」選項，以便它能夠以HTML格式創建電子郵件。

3）受害者在不需要有任何進一步互動的情況下打開電子郵件：

4）目標的Net-NTLM哈希值由我們啟動的Responder自動捕獲：

此漏洞利用中的一個重要的要求顯然是目標在埠445上能夠連接到攻擊者的SMB伺服器的能力。一些ISP默認阻止了此埠，而其他許多ISP則沒有。有趣的是，微軟維護了一個小型列表 [7]的ISP，它們不會過濾對埠445的出站訪問。

如何防止此安全問題的發生

再次說明一點，本文中描述的問題是來自Windows的設計決策，並且已知20多年來它可以在無數場景中被濫用。

有幾種不同的方法可以緩解這種不安全行為帶來的影響。

將註冊表項HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV10中的RestrictSendingNTLMTraffic的值設置為2可以降低這種風險的暴露，因為Windows將不再發送NTLMv1身份或NTLMv2的哈希作為與伺服器通信的挑戰，無論SMB伺服器是合法的還是偽造的。

但是，它可能會破壞正常功能和單點登錄機制，尤其是在嚴重依賴NTLM身份驗證的企業網路中。

在2017年，微軟還發布了針對Windows 10和Windows Server 2016的緩解方案[4]，該緩解方案使用Windows防火牆阻止NTLM SSO身份驗證使用未標記為內部的資源，拒絕公共資源的NTLM SSO身份驗證，最終限制了當受到攻擊者操作的SMB伺服器等外部服務的挑戰時，Net-NTLM哈希的泄露問題。默認情況下不會激活此功能，用戶必須通過明確將更改應用於註冊表來選擇加入。

從網路安全的角度來看，可以通過定義禁止SMB連接到達非白名單的外部伺服器的防火牆規則來減輕這種漏洞的負面影響，或者如果可以將其視為一種選擇，甚至可以更好地阻止所有外部SMB連接。

結論

儘管NTLM認證已有二十多年的歷史，但它們經常被忽視，存在與NTLM認證相關的安全風險。利用這些漏洞的門檻是非常低的，並給企業組織帶來了嚴重的風險，特別是從內部威脅的角度來看，或者是一個被入侵的帳戶場景來看。防止這個問題並非易事，但可以通過一些最新的微軟補丁和其他精心思考的策略來限制NTLM流量。

也許有一天微軟會發布補丁或服務包，以防止Windows在任何地方泄露NTLM哈希。

參考

[1] https://insights.sei.cmu.edu/cert/2018/04/automatically-stealing-password-hashes-with-microsoft-outlook-and-ole.html

[2] https://blog.blazeinfosec .com/leveraging-web-application-vulnerabilities-to-steal-ntlm-hashes-2 /

[3] //insecure.org/sploits/winnt.automatic.authentication.html

[4] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170014

[5] https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2018/may/smb- hash-hijacking-and-user-tracking-in-ms-outlook /

[6] https://medium.com/@ValdikSS/deanonymizing-windows-users-and-capturing-microsoft-and-vpn-accounts-f7e53fe73834

[ 7] http://witch.valdikss.org.ru/

[8]https://social.technet.microsoft.com/wiki/contents/articles/32346.azure-summary-of-isps-that-allow-disallow-access-from-port-445.aspx

[9] https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html

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