作者：天融信阿爾法實驗室
公眾號：https://mp.weixin.qq.com/s/NEBi8NflfaEDL2qw1WIqZw

漏洞概述

2019年6月，Microsoft發布了一條安全更新。該更新針對CVE-2019-1040漏洞進行修復。此次漏洞，攻擊者可以通過中間人攻擊，繞過NTLM MIC（消息完整性檢查）保護，將身份驗證流量中繼到目標服務器。

通過這種攻擊使得攻擊者在僅有一個普通域賬號的情況下可以遠程控制 Windows 域內的任何機器，包括域控服務器。

漏洞利用

攻擊方式一：Exchange

1.1驗證環境：

2.2驗證過程：

① 環境搭建

  • 安裝配置域控制器

  • 安裝配置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委派

2.1驗證環境：

2.2 驗證過程：

① 環境搭建

  • 安裝配置域控制器，同時開啟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出所有密碼哈希值：

漏洞細節

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

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

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

Exchange攻擊流程

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

下文標題內容，即為攻擊流程，對應流程圖中紅框所示的流程

如果對SMB協議不是很清楚的讀者，可以先參考技術點分析-客戶端與服務器端的SMB通信一節內容

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

在攻擊的開始階段，attacker需要確保擁有一個可使用的AD賬號，這是滿足觸發SpoolService錯誤的必要條件。

首先attacker利用已擁有的AD賬號，連接到遠程服務器的打印服務（spoolsv.exe）。

centerAttacker通過SMB2協議登陸Exchange流程>Attacker通過SMB2協議登陸Exchange流程

Attacker通過SMB2協議登陸Exchange流量

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

2、觸發SpoolService錯誤

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

Attacker發送SpoolService錯誤payload流程

Attacker通過printerbug向Exchange發送帶有payload的流量

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

在觸發SpoolService錯誤后，Exchange服務器向Attacker進行身份驗證

Exchange服務器向Attacker發送Negotiate Protocol Request，這是客戶端向服務器發送第一個SMB請求，可參考技術點分析-客戶端與服務器端的SMB通信

Exchange向Attacker發送SMB協商請求流程

Exchange向Attacker發送SMB協商請求流量

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

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

Attacker向DC中繼Exchange的協商請求流程

Attacker向DC中繼Exchange的協商請求流量

Attacker作為中間人，將Negotiate Protocol Request通過ldap請求中繼到ad服務器

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

5、attacker向Exchange發送Negotiate Protocol Response

Attacker向Exchange發送Negotiate Protocol Response流程

Attacker向Exchange發送Negotiate Protocol Response流量

6、Exchange向attacker發送Session Setup Request

Exchange向attacker發送Session Setup Request流程

Exchange向attacker發送Session Setup Request流量

7、Attacker向DC中繼Session Setup Request

Attacker向DC中繼Session Setup Request流程

Attacker向DC中繼Session Setup Request流量

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

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

Attacker 向exchange發送Session Setup Response流程

Attacker 向exchange發送Session Setup Response流量

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

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

exchange向Attacker發送包含了身份驗證請求的Session Setup Request流程

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認證

Attacker向 DC中繼Session Setup Request 流程

Attacker向 DC中繼Session Setup Request 流量

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中用戶的所有哈希密碼。

同步Active Directory中用戶的所有哈希密碼

Kerberos委派攻擊流程

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

Kerberos委派攻擊流程與Exchange攻擊利用，在DC對Attacker的身份驗證結束之前的階段是類似的。區別在于后續提權過程，下面介紹下Kerberos委派攻擊后續攻擊流程。

在attacker冒用SDC身份后，由于SDC計算機身份沒有修改訪問控制列表(ACL)的權限，無法直接提權。而后續提權利用中的S4U2Self不適用于沒有SPN的帳戶。在域環境中，任何域用戶都可以通過MachineAccountQuota創建新的計算機帳戶，并為其設置SPN。Attacker通過此方式新建一個域中的計算機賬號。這一過程通過LDAP實現并設置賬戶與密碼 ，如下圖

Ntlmrelayx工具成功創建計算機賬戶

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兩部分：

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

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

SMB2 / Session Setup

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

Session Setup分為兩部分：

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

  2. 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執行后的數據包：

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

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

（3） 第二次身份驗證便是使Exchange向attackerhost（192.168.123.69）發起的身份驗證，用戶為TEST\TOPSEC對網絡進行身份驗證）

SMB中繼LDAP思路以及難點

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

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

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

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

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

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

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

MIC校驗

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

NTLM_NEGOTIATE，NTLM_CHALLENGE，NTLM_AUTHENTICATE。

NTLM_NEGOTIATE，NTLM_CHALLENGE，NTLM_AUTHENTICATE對應位于SMB協議中的SessionSetup階段

Clinet與Server交互流程圖

Clinet與Server交互流量

SMB認證協議流程

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

存放于NTLM_AUTH中的MIC

MIC是使用會話密鑰應用于所有3個NTLM消息的串聯的HMAC_MD5，該會話密鑰僅對啟動認證的帳戶和目標服務器是已知的。

因此，試圖篡改其中一條消息的攻擊者（例如，修改簽名協商）將無法生成相應的MIC，這將導致攻擊失敗。

MIC校驗繞過

Microsoft服務器允許無MIC 的NTLM_AUTHENTICATE消息。

如果想要將SMB身份驗證中繼到LDAP，并完成中繼攻擊，可以通過如下步驟：

取消MIC校驗以確保可以修改數據包中的內容：

（1）從NTLM_AUTHENTICATE消息中刪除MIC

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

LDAP簽名繞過

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

將NEGOTIATE_SIGN設置為not set以繞過LDAP驗證

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

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

smb中繼LDAP流程

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

Ntlmrelayx中繼流程如下：

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

Exchange-Attacker-DC交互流量

Exchange向Attacker發送NTLMSSP_NEGOTIATE包內容

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

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

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

Exchange-Attacker-DC交互流量

Exchange向Attacker發送NTLMSSP_AUTH

Attacker將NTLMSSP_AUTH通過LDAP中繼到DC

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

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

Exchange-Attacker-DC交互流量

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’

參考鏈接

[1] Exchange Server 2013 一步步安裝圖解

[2] Enable LDAP over SSL (LDAPS) for Microsoft Active Directory servers

[3] Windows Server 2012 R2 輔助域控制器搭建

[4] 濫用基于資源約束委派來攻擊Active Directory

[5] Abusing S4U2Self: Another Sneaky Active Directory Persistence

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

[7] 濫用Exchange：遠離域管理員的一個API調用

[8] The SYSTEM Account

[9] Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/962/