如何進行結合CVE-2019-1040漏洞的兩種域提權深度利用分析

如何進行結合CVE-2019-1040漏洞的兩種域提權深度利用分析，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

一、漏洞概述

2019年6月，Microsoft發布了一條安全更新。該更新針對CVE-2019-1040漏洞進行修復。此次漏洞，攻擊者可以通過中間人攻擊，繞過NTLM MIC（消息完整性檢查）保護，將身份驗證流量中繼到目標服務器。    通過這種攻擊使得攻擊者在僅有一個普通域賬號的情況下可以遠程控制 Windows 域內的任何機器，包括域控服務器。

二、漏洞利用

攻擊方式一：Exchange

驗證環境：

驗證過程：

① 環境搭建

安裝配置域控制器

安裝配置Exchange Server，參考[1]

在域中新建一個用于測試的賬戶test

②執行ntlmrelayx.py腳本進行NTLM中繼攻擊，設置SMB服務器并將認證憑據中繼到LDAP協議。其中--remove-mic選項用于清除MIC標志，--escalate-user用于提升指定用戶權限。

③ 執行printerbug.py腳本，觸發SpoolService的bug。    

④ SpoolService的bug導致Exchange服務器回連到ntlmrelayx.py，即將認證信息發送到ntlmrelayx.py。可以在下圖中看到認證用戶是TEST\TOPSEC$。

接著ntlmrelayx.py開始執行LDAP攻擊，加上-debug選項后可以看到更詳細的信息。 首先，通過遍歷驗證中繼帳戶所在用戶組及權限，發現當前賬戶可以創建用戶、可以修改test.local域的ACL，因為域中的Exchange Windows Permissions用戶組被允許修改ACL，如下圖所示：

該用戶組下的成員正是中繼的計算機賬戶TOPSEC：

因此腳本會首選修改ACL來提權，因為這相比創建用戶的方式更隱秘一些。具體方式是通過LDAP修改域的安全描述符（Security Descriptor），可以在下面的數據包中看到ACL中每一條具體的訪問控制條目（ACE，Access    Control Entries）：

⑤ 完成ACL的修改后，test就可以通過secretsdump.py的DCSync功能dump出所有密碼哈希值：

攻擊方式二：Kerberos委派

驗證環境：

驗證過程： ① 環境搭建

安裝配置域控制器，同時開啟LDAPS支持，因為該攻擊方式需要添加新的計算機賬戶，必須在LDAPS進行。開啟方法參考[2]

安裝配置輔助域控制器，方法參考[3]

在域中新建一個用于測試的賬戶topsec，一個域管理員admin

② 和攻擊方式一相同，執行ntlmrelayx.py本，使用--delegate-access選項，delegate-access選項將中繼計算機帳戶（這里即輔助域控制器）的訪問權限委托給attacker。

③ attacker對輔助域控制器(SDC)執行printerbug.py腳本    

③ printerbug.py腳本執行成功后，將觸發輔助域控制器(SDC)回連Attacker主機，回連使用的認證用戶是輔助域控制器(SDC)本地計算機賬戶TEST/TOPSEC$。 ntlmrelayx.py通過ldaps將該用戶賬戶中繼到域控服務器(DC)，因為這種攻擊方式下所冒用的身份TEST/TOPSEC$并不在Exchange    Windows Permissions組內，不具有修改ACL權限，但是可以通過此身份在DC上添加一個新計算機賬戶（下圖中EJETBTTB$）, 并修改其約束委派授權，授予它對受害計算機（輔助域控制器）的委派權限。

④使用getSP.py腳本，通過-impersonate參數模擬用戶admin請求其票證，保存為ccache，admin用戶為Domain Admins組的成員，具有對輔助域控制器(SDC)的管理與訪問權限。  

⑤ 使用上一步驟中保存的Kerberos服務票證，我們可以在目標主機(SDC)上模擬admin身份，從而執行任何操作，例如使用secretsdump轉儲哈希值。通過secretsdump dump出所有密碼哈希值：

三、漏洞細節

此次的攻擊流程有如下兩個方式：

Exchange攻擊流程：使用任何AD帳戶，通過SMB連接到目標Exchange服務器，并觸發SpoolService錯誤。目標服務器將通過SMB回連至攻擊者主機，使用ntlmrelayx將SMB身份驗證中繼到LDAP。使用中繼的LDAP身份驗證，為攻擊者帳戶授予DCSync權限。攻擊者帳戶使用DCSync轉儲AD中的所有密碼哈希值。

Kerberos委派攻擊流程：使用任何AD帳戶，通過SMB連接到目標服務器，并觸發SpoolService錯誤。目標服務器將通過SMB回連至攻擊者主機，使用ntlmrelayx將SMB身份驗證中繼到LDAP。使用中繼的LDAP身份驗證，將目標服務器的基于資源的約束委派權限授予攻擊者控制下的計算機帳戶。攻擊者作為受害者服務器上的任何用戶進行身份驗證。

Exchange攻擊流程

下文出現的攻擊流量圖中,個角色與ip對應關系同上文驗證環境搭建：

下文標題內容，即為攻擊流程，對應流程圖中紅框所示的流程 如果對SMB協議不是很清楚的讀者，可以先參考技術點分析-客戶端與服務器端的SMB通信一節內容

1. attacker使用普通AD賬戶登陸Exchange

在攻擊的開始階段，attacker需要確保擁有一個可使用的AD賬號，這是滿足觸發SpoolService錯誤的必要條件。 首先attacker利用已擁有的AD賬號，連接到遠程服務器的打印服務（spoolsv.exe），下圖是Attacker通過SMB2協議登陸Exchange流程和流量：

成功的通過該階段，就可以請求對一個新的打印作業進行更新，令其將該通知發送給指定目標。

2. 觸發SpoolService錯誤

attacker通過Printerbug腳本，觸發Exchange服務器SpoolService錯誤，強制Exchange服務器通過MS-RPRN RPC接口向attacker進行身份驗證。具體細節見技術點分析一章中的SpoolService/printer bug。下圖是Attacker觸發SpoolService錯誤payload流程和流量：

3. Exchange主機向Attacker發送Negotiate Protocol Request

在觸發SpoolService錯誤后，Exchange服務器向Attacker進行身份驗證，即發送Negotiate Protocol Request，這是客戶端向服務器發送第一個SMB請求，可參考技術點分析-客戶端與服務器端的SMB通信。下圖是Exchange向Attacker發送SMB協商請求流程和流量：

在正常的業務場景中，用戶想登陸并使用Exchange，往往需要向Exchange服務器發送SMB協商請求流量，以便驗證身份并登陸。但由于SpoolService錯誤，在這里，Exchange向Attacker發送SMB協商請求流量，以便驗證身份。這便造成了Attacker可以作為中間人身份中繼此身份認證以冒充Exchange欺騙DC的機會。

4. Attacker將協商請求通過ldap中繼到DC服務器

Attacker作為中間人，將Negotiate Protocol Request通過ldap請求中繼到ad服務器 在此步驟以及以下攻擊流程中，有需要將SMB身份驗證通過LDAP中繼至DC的環節。由于NTLM協議的工作方式，無法將SMB流量直接通過LDAP中繼，因此需要對流量進行修改，而需改流量，勢必需要繞過MIC驗證，此處便是本次漏洞的重點，詳情見技術點分析-MIC校驗繞過部分。

5. attacker向Exchange發送Negotiate Protocol Response

6. Exchange向attacker發送Session Setup Request

7. Attacker向DC中繼Session Setup Request

Attacker將Exchange發送來的Session Setup Request 中繼給DC， DC將包含 CHALLENGE的Response發送給Attacker。

8. Attacker 向exchange發送Session Setup Response（CHALLENGE）

Attacker 將DC發出的包含challenge的Session Setup Response發送給exchange。

9. exchange向Attacker發送包含了身份驗證請求的Session Setup

我們可以看到上圖中的認證用戶為TEST\TOPSEC$，而不是運行Exchange的SYSTEM賬戶，這是因為SYSTEM賬戶具有太高權限，如果用此帳戶對網絡資源進行身份驗證，則會出現安全問題。所以當訪問網絡資源時，使用本地計算機的網絡帳戶對網絡進行身份驗（形式為domain\computername$，即TEST\TOPSEC$）。 Exchange收到challenge后，向attacker發送包含了身份驗證請求的Session Setup流量。

10. Attacker向 DC中繼含有Exchange的身份認證的Session Setup Request

Attacker將身份認證請求中繼到DC，并使用Exchange的身份認證通過DC認證

DC認證通過Exchange身份，并向Attcker發送認證通過的Response，此時，DC對Attacker的身份驗證結束，Attacker成功冒用Exchange身份。 由于安裝Exchange后，Exchange在Active Directory域中具有高權限，Exchange的本地計算機賬戶TOPSEC$會被加入用戶組Exchange Trusted Subsystem，該用戶組又隸屬于Exchange Windows Permissions。Exchange    Windows Permissions組可以通過WriteDacl方式訪問Active Directory中的Domain對象，該對象允許該組的任何成員修改域權限，從而可以修改當前域ACL達到提權目的。 使用提權后的用戶或計算機可以執行域控制器通常用于復制的同步操作，這允許攻擊者同步Active Directory中用戶的所有哈希密碼。

Kerberos委派攻擊流程

下文出現的攻擊流量圖中,個角色與ip對應關系同上文驗證環境搭建：

Kerberos委派攻擊流程與Exchange攻擊利用，在DC對Attacker的身份驗證結束之前的階段是類似的。區別在于后續提權過程，下面介紹下Kerberos委派攻擊后續攻擊流程。 在Attacker冒用SDC身份后，由于SDC計算機身份沒有修改訪問控制列表(ACL)的權限，無法直接提權。而后續提權利用中的S4U2Self不適用于沒有SPN的帳戶。在域環境中，任何域用戶都可以通過MachineAccountQuota創建新的計算機帳戶，并為其設置SPN。Attacker通過此方式新建一個域中的計算機賬號。這一過程通過LDAP實現并設置賬戶與密碼    ，如下圖    

DC上可見computers列表中新創建的名為EJETBTTB的計算機：

在域中新的計算機賬戶EJETBTTB(下圖中的service A)建立成功后，后續攻擊如下圖攻擊步驟

1. 攻擊者為Service A配置了基于資源的約束委派

由于通過S4U2Self請求到的TGS forwardable標志位為 Non-forwardable,這意味著該TGS服務票據是不可轉發的，不可以在接下來的S4U2Proxy中進行轉發。但是不可轉發的TGS竟然可以用于基于資源的約束委派，S4U2Proxy會接收這張不可轉發的TGS。由于我們擁有Service A的計算機賬號以及密碼，所以在這里可以為Service A到SDC配置了基于資源的約束委派，將默認的約束委派更改為基于資源的約束委派，以便后續攻擊。

2. Service A 調用S4U2Self向認證服務器(SDC)為admin請求訪問自身的服務票據

通過國外安全研究員Elad Shami的研究可知，無論服務賬號的UserAccountControl屬性是否被設為TrustedToAuthForDelegation，    服務自身都可以調用S4U2Self為任意用戶請求訪問自己的服務票據，也就是說，這里Service A 可以調用S4U2Self向SDC為admin用戶申請可訪問自身的服務票據。

3. SDC將為admin用戶申請的訪問Service A的TGS發送給Service A

4、 Service A通過S4U2Proxy 轉發TGS，并為admin申請訪問SDC票據

5、SDC將為admin用戶申請的訪問SDC的TGS發送給Service A

在這里，Service A為Attacker創建并控制，Attacker獲得TGS票據，利用該票據以admin身份訪問SDC，完成提權

技術點分析

在理清利用流程后，接下來詳解利用流程中的技術點。

客戶端與服務器端的SMB通信

補充介紹一些關于SMB通信協議相關內容，通過這部分內容，可以加深對的漏洞流程的理解。對SMB通信協議熟悉的讀者，可以跳過此部分。 下圖是客戶端與服務器端的SMB通信流程：

SMB2 / Negotiate Protocol Negotiate Protocol是在SMB2的任何新TCP會話上發出的第一個SMB2命令，它用于協商要使用的協議版本。Negotiate Protocol命令分為Negotiate Protocol Request/ Negotiate Protocol Response兩部分：

Negotiate Protocol Request： 客戶端向服務器發送第一個SMB請求：“Negotiate Protocol Request”。這個請求包含了客戶端所支持的各種 SMB Dialect。

Negotiate Protocol Response: 服務器收到該請求后，選擇一個它支持的最新版本（比如NTLM 0.12），再通過“Negotiate Protocol Response”回復給客戶端。

SMB2 / Session Setup SMB2 / Session Setup命令用于對用戶進行身份驗證并獲取分配的UserID。此命令通常是SMB2 / Negotiate Protocol階段完成后從客戶端發出的第一個命令。Session Setup分為兩部分：

Session Setup Request: Negotiate Protocol階段結束之后，，客戶端請求和服務器建立一個session，在客戶端發送的Session Setup Request里，包含了身份驗證請求。

Session Setup Response: 服務器回復是否通過驗證。

SpoolService/printer bug

在攻擊利用流程中，需要使用到一個名為printerbug.py的工具，此工具觸發SpoolService/printer bug，強制Windows主機通過MS-RPRN RPC接口向攻擊者進行身份驗證。 Windows的MS-RPRN協議用于打印客戶機和打印服務器之間的通信，默認情況下是啟用的。協議定義的RpcRemoteFindFirstPrinterChangeNotificationEx()調用創建一個遠程更改通知對象，該對象監視對打印機對象的更改，并將更改通知發送到打印客戶端。

任何經過身份驗證的域成員都可以連接到遠程服務器的打印服務（spoolsv.exe），并請求對一個新的打印作業進行更新，令其將該通知發送給指定目標。之后它會將立即測試該連接，即向指定目標進行身份驗證（攻擊者可以選擇通過Kerberos或NTLM進行驗證）。另外微軟表示這個bug是系統設計特點，無需修復。

在本次漏洞的利用過程中，我們通過printerbug.py腳本觸發了上述bug，強制Exchange服務器對攻擊者（192.168.123.69）發起身份驗證，而Exchange默認是以SYSTEM身份執行的。 下圖是printerbug.py執行后的數據包：    

第一次身份驗證由攻擊者向exchange服務器發起，以便可以遠程連接到Spoolsv服務，可以看到使用的賬號是一個普通的域成員賬號test；

接著，printerbug.py腳本中調用RpcRemoteFindFirstPrinterChangeNotificationEx()，請求對一個新的打印作業進行更新，并令其將該通知發送給我們指定的attackerhost（192.168.123.69）。這部分數據就是上圖中Encrypted SMB3中的一部分。

第二次身份驗證便是使Exchange向attackerhost（192.168.123.69）發起的身份驗證，用戶為TEST\TOPSEC$，（不是SYSTEM的原因是：如果本地服務使用SYSTEM帳戶訪問網絡資源，則使用本地計算機的網絡帳戶domain\computername$對網絡進行身份驗證）

SMB中繼LDAP思路以及難點

在攻擊利用流程中，需要將SMB身份驗證通過LDAP中繼至DC，由于NTLM協議的工作方式，無法將SMB流量直接通過LDAP中繼，將SMB流量通過LDAP中繼難點以及繞過思路如下：

默認情況下，SMB中的NTLM身份驗證:NEGOTIATE_SIGN為set狀態

將此SMB流量中繼到LDAP時，由于此時的Negotiate Sign設置為set，該標志會觸發LDAP簽名，而此SMB流量為Attacker從Exchange服務器上中繼而來，無法通過LDAP的簽名校驗，從而被LDAP忽略，導致攻擊失敗

為了防止攻擊失敗，需要將NEGOTIATE_SIGN設置為Not set

MIC保護不被篡改，如果簡單的改包，將NEGOTIATE_SIGN設置Not set，將會導致MIC校驗不通過

需要尋找一種可以繞過MIC校驗的方式，以便更改包中的值

在繞過MIC校驗之后，更改NEGOTIATE_SIGN值為Not set，使得在不觸發LDAP簽名校驗的情況下，將SMB中繼LDAP

MIC校驗

NTLM身份驗證由3種消息類型組成：

NTLM_NEGOTIATE

NTLM_CHALLENGE

NTLM_AUTHENTICATE

分別對應位于SMB協議中的SessionSetup階段，下圖就是Clinet與Server交互流程圖和流量：

為了確保惡意行為者不在傳輸過程中處理消息，在NTLM_AUTHENTICATE消息中添加了一個額外的MIC（消息完整性代碼）字段，如下圖所示：

MIC是使用會話密鑰應用于所有3個NTLM消息的串聯的HMAC_MD5，該會話密鑰僅對啟動認證的帳戶和目標服務器是已知的。因此，試圖篡改其中一條消息的攻擊者（例如，修改簽名協商）將無法生成相應的MIC，這將導致攻擊失敗。

MIC校驗繞過

Microsoft服務器允許無MIC 的NTLM_AUTHENTICATE消息。 如果想要將SMB身份驗證中繼到LDAP，并完成中繼攻擊，可以通過如下步驟： 取消MIC校驗以確保可以修改數據包中的內容：

從NTLM_AUTHENTICATE消息中刪除MIC

從NTLM_AUTHENTICATE消息中刪除版本字段（刪除MIC字段而不刪除版本字段將導致錯誤）。

LDAP簽名繞過

在繞過MIC校驗之后，可以修改NEGOTIATE_SIGN值以便將SMB流量順利通過LDAP簽名校驗 將NEGOTIATE_SIGN設置為not set以繞過LDAP驗證

取消設置NTLM_NEGOTIATE消息中的簽名標志

NTLMSSP_NEGOTIATE_ALWAYS_SIGN

NTLMSSP_NEGOTIATE_SIGN

取消設置NTLM_AUTHENTICATE消息中的以下標志：

NTLMSSP_NEGOTIATE_ALWAYS_SIGN

NTLMSSP_NEGOTIATE_SIGN

NEGOTIATE_KEY_EXCHANGE

NEGOTIATE_VERSION

SMB中繼LDAP流程

為了實現SMB中繼LDAP流程，這里使用ntlmrelayx.py工具作為中繼

Ntlmrelayx中繼流程如下：

取消設置NTLM_NEGOTIATE消息中的簽名標志（NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN）

Exchange向Attacker發送NTLMSSP_NEGOTIATE包內容：

Attacker將NTLMSSP_NEGOTIATE通過LDAP中繼到DC包內容：

可見，在通過LDAP中繼時，已經取消設置NTLM_NEGOTIATE消息中的簽名標志（NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN）

從NTLM_AUTHENTICATE消息中刪除MIC以及版本字段

Exchange向Attacker發送NTLMSSP_AUTH：

Attacker將NTLMSSP_AUTH通過LDAP中繼到DC：

在通過LDAP中繼時，NTLM_AUTHENTICATE消息中MIC以及版本字段已被刪除。

取消設置NTLM_AUTHENTICATE消息中的以下標志：NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN，NEGOTIATE_KEY_EXCHANGE，NEGOTIATE_VERSION。

Exchange向Attacker發送NTLMSSP_AUTH包內容：    Attacker將NTLMSSP_AUTH通過LDAP中繼到DC包內容：

在通過LDAP中繼時， NTLM_AUTHENTICATE消息中的以下標志：NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN，NEGOTIATE_KEY_EXCHANGE，NEGOTIATE_VERSION已經被設置為‘NOT set’。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。