紅隊與理論：Credential Relay與EPA
n1nty @ 360 A-TEAM
近期，因各種相關的漏洞與攻擊方案，大家又開始關注了 Credential Relay 這種攻擊手法。 在我有限的認知內，我沒看到過有人詳細地講解過微軟為這種攻擊手法而推出的防禦機制，所以我整理了一下以前看過的資料，希望這是第一篇（當然講的比較淺且這其中還有不少我沒解決的問題甚至錯誤，歡迎交流）。
為什麼寫的是 "Credential Relay" 而不是 "NTLM-Relay"，因為 NTLM 只是Windows 下身份認證的其中一種方法。
Credential Relay
大體可以分為兩類：
-
Credential Forwarding
攻擊者通過一定的方法使得 Client 與自己進行認證，然後將 Client 傳送過來的 Credential 轉發至 Server，從而使攻擊者獲得 Client 在 Server 上的許可權。後續的利用則要看 Server 提供了哪些功能以及 Client 能在 Server 上面做什麼。
-
Credential Reflection
攻擊者通過一定的方法使得 Client 與自己進行認證，然後將 Client 傳送過來的 Credential 轉發回 Client 自身，從而攻擊 Client（你也可以認為此時的 Client 也相當於是一臺 Server）。早年出現的 SMBRelay 攻擊方案就是這種方法。
在我有限的認知內，微軟推出的所有的防禦方案，防禦的都是 Server 端。
（除非是在 NTLM 的場景下，你可以通過組策略來配置不允許 Client 發起NTLM 認證）
防禦方案 1：Server 端的 Signing/Encryption
估計安全圈的各位最熟悉的例子就是 SMB Signing 功能了。
Windows 下的 SSP 除了提供身份認證功能以外，還提供會話安全功能。
比如 Client 與 Server 建立了一個 Socket 連線後，可以使用 SSP 與 Server 進行身份認證，身份認證完以後，Client 與 Server 還可以利用 SSP 提供的會話安全功能為後續的資料包進行簽名與加密，以防止資料包被中間人篡改、竊聽。
SSP 提供的會話安全功能，是基於 session key 的。在 Client 與 Server 端進行了身份認證以後，Client 與 Server 端都能夠同時得到一個用於會話安全功能的 session key。攻擊者要想知道這個 session key，就必須要知道 Client 的原始密碼，而對於 Credential Relay 的攻擊場景，攻擊者只是站在一箇中間人的位置對 Credential 進行轉發，是不可能知道客戶端的原始密碼的。這一點我在以下這篇文章裡面也說過：
這裡用一張圖來解釋一下 Signing 機制防止 Credential Relay 的方法：
如上圖所示：
Attacker 在攻擊一個開啟了 Signing/Encryption 的伺服器的時候，出現的情況就是認證會成功，但是後續的操作會失敗。因為 Server 要求後續資料包是被 session key 簽名、加密過的，而 Attacker 沒有 Client 的原始密碼無法計算出那個 session key，所以自然也就無法對攻擊資料包進行簽名、加密。操作失敗的具體表現依 Server 的不同而不同，你有可能會看到一個報錯說操作失敗，也有可能看到的是服務端無響應之類的。
Server 必須要支援並且強制使用 SSPI session key 來對資料包進行簽名或加密，才能夠使用這種方法來防禦 Credential Relay。
防禦方案 2：EPA
EPA = Extended Protection for Authentication，增強的身份認證保護
這個機制是從什麼時候引入的我沒有嚴肅去考證，好像是從 Win7 以及 Windows 2008 R2 開始引入的。其他版本的作業系統可以通過安裝補丁的方式來獲取此機制。
看這裡吧：
https://docs.microsoft.com/en-US/security-updates/SecurityAdvisories/2009/973811
EPA 機制主要引入了以下兩個方案用於防止 Credential Relay
-
Channel Binding
-
Service Binding
在網路中傳輸的身份認證資料有的時候也被稱為 authentication token。比如 NTLM 的三條訊息以及 Kerberos 傳送的 AS-REQ/AS-REQ 之類的都可以被稱為 authentication token。
Channel binding 與 Service binding 這兩個方案就是在原有的 authentication token 中加入一些其他的額外資訊，這些額外的資訊使得 Server 端可以免受 Credential Relay 的攻擊。
Channel Binding
Channel Binding 方案會在原有 Windows SSPI 生成的 authentication token 中加入一段額外資訊，這段額外的資訊被稱為 Channel Binding Token（CBT）。
Channel Binding 方案只能用於保護那些只接受 TLS 連線的 Server 端。即，它可以使 Server 端有能力知道其接收到的憑據到底是不是發給自己的（也就是有能力知道收到的憑據是不是被 Relay 過來的）。如果發現憑據不是發給自己的（也就是憑據是被 Relay 過來的），則拒收，則 Attacker 嘗試與 Server 進行身份認證的請求將會失敗。
用一張圖演示一下 Channel Binding 防禦 Credential Relay 的原理：
上圖分為以下幾個步驟：
-
Attacker 通過某種方式使得 Client 與自己建立 TLS 連線，並且 Client 將 Credential（authentication token） 傳送給 Attacker。authentication token 中帶有 CBT。 CBT 是基於 client 到 server 的這個 TLS 連線的一些屬性所計算出來的（我沒有去研究具體的計算過程）。且這個 CBT 受到了完整性保護，使得攻擊者無法刪除、修改 CBT。具體的完整性保護的方式依認證協議的不同而不同。
-
Attacker 與 一臺開啟了 Channel Binding 機制的 Server 建立 TLS 連線，將 authentication token 轉發至 Server
-
Server 接收到 authentication token 後，會基於attacker 到 server 的這個 TLS 連線的一些屬性計算出來一個 CBT，同時取出 attacker 轉發過來的由 client 計算出來的 CBT進行對比。
-
對比將會失敗，因為 client 計算出來的 CBT 是基於 client --> attacker 這個 TLS 連線的一些屬性，而 server 計算出來的 CBT是基於 attacker --> server 這個 TLS 連線的一些屬性。 通過這個對比，Server 就會知道 attacker 轉發過來的 authentication token 並不是發給自己的，所以認定這個憑據是被 relay 過來的，所以 attacker 與 server 的認證將會失敗 。
Service Binding
Channel Binding 只能用於保護使用 TLS 連線的 Server。而 Service Binding 可用於保護那些使用非加密連線的 Server。
Service binding 防禦 Credential Relay 的原理與 Channel Binding 基本類似，只不過是將 CBT 替換成了目標服務的 SPN。
下面用一張圖來表示 Service Binding 是如何防禦 Credential Relay 的：
-
Attacker 通過某種方式觸發 Client 與自己認證，Client 傳送給 Attacker 的憑據中帶有 Attacker 的 SPN（因為 Client 是在訪問 Attacker），並且這個 SPN 受到了完整性保護(具體的完整性保護的方式依認證協議不同而不同)，使得 attacker 無法刪除、修改這個 SPN。（需要知道的一點是， NTLM 中也是會涉及到 SPN 的概念的）
-
Attacker 將憑據轉發至 Server
-
Server 收到憑據後，檢查憑據中的 SPN，發現 SPN 不是自己的而是 attacker 的，說明這個憑據並不是發給自己的（而是發給 attacker 的），所以認為遇到了 Credential Relay 攻擊，認證將會失敗。
需要注意的是，如果你的服務端程式想要受到 EPA 的保護，則要求：
-
執行服務端的作業系統必須支援 EPA（Win7 及 Win 2018 R2 後自動支援，或者可以通過安裝補丁的方式來新增支援）
-
你的服務端自身需要做修改，來接入 EPA
-
連線服務端的客戶端所在的作業系統要支援 EPA 並且客戶端需要做相應修改來發送 CBT 或 SPN
即，EPA 是作業系統提供的一些基礎框架，它並不會自動保護伺服器上的所有程式，只有那些使用了 EPA 的程式才會受到保護。
有不少服務端程式雖然支援 EPA，但是考慮到相容性問題（比如客戶端不支援 EPA），所以沒有強制開啟 EPA，LDAPS 就是這麼一個例子。
微軟針對 CVE-2017-8563 的修復方式就是使 LDAP Server 支援 EPA，但是卻沒有預設強制 LDAP Server 必須要使用 EPA，所以造成了最近那些 Relay 到 LDAPS 的各種攻擊手法。
防禦方案 3：Type3 in Flight Checking
這是一個作業系統層面針對 NTLM-Relay 的防禦方案，主要防禦的是 Credential Reflection。
我沒找到官方對這種防禦方案的命名，所以我把它稱為 'Type3 in Flight Checking'
要想受到此機制的保護，要求 Client 與 Server 必須使用 Windows SSPI 來生成與驗證 NTLM 訊息，而不能用其他第三方 API。
我在先前那篇 Exchange SSRF 中講到了這個機制的原理，看這裡： Exchange CVE-2018-8581 補丁有用？沒用？
除了上述的一些相對通用的 Credential Relay 防禦方案以外，微軟還為一些與 Relay 相關的 CVE 單獨做了一些修補，我花了不少時間在網上進行搜尋最後得出一個結論：
目前沒人明確知道這些針對 CVE 的修補方案是怎麼做的。
360 A-TEAM 是隸屬於 360 企業安全集團旗下的純技術研究團隊。團隊主要致力於 Web 滲透，APT 攻防、對抗，前瞻性攻防工具預研。從底層原理、協議層面進行嚴肅、有深度的技術研究，深入還原攻與防的技術本質。歡迎有意者加入！
宣告：本文來自n1nty，版權歸作者所有。文章內容僅代表作者獨立觀點，不代表安全內參立場，轉載目的在於傳遞更多資訊。如需轉載，請聯絡原作者獲取授權。