作者：n1nty @ 360 A-TEAM
公眾號：https://mp.weixin.qq.com/s/hACLQ4UgdFXDdlB4CKKhXg

近期，因各種相關的漏洞與攻擊方案，大家又開始關注了 Credential Relay 這種攻擊手法。 在我有限的認知內，我沒看到過有人詳細地講解過微軟為這種攻擊手法而推出的防御機制，所以我整理了一下以前看過的資料，希望這是第一篇（當然講的比較淺且這其中還有不少我沒解決的問題甚至錯誤，歡迎交流）。

為什么寫的是 "Credential Relay" 而不是 "NTLM-Relay"，因為 NTLM 只是Windows 下身份認證的其中一種方法。

Credential Relay

大體可以分為兩類：

  1. Credential Forwarding

    攻擊者通過一定的方法使得 Client 與自己進行認證，然后將 Client 發送過來的 Credential 轉發至 Server，從而使攻擊者獲得 Client 在 Server 上的權限。后續的利用則要看 Server 提供了哪些功能以及 Client 能在 Server 上面做什么。

  2. 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 進行轉發，是不可能知道客戶端的原始密碼的。這一點我在以下這篇文章里面也說過：

360 A-TEAM 帶你走進 NTLM-Relay

這里用一張圖來解釋一下 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

  1. Channel Binding
  2. 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 的原理：

上圖分為以下幾個步驟：

  1. Attacker 通過某種方式使得 Client 與自己建立 TLS 連接，并且 Client 將 Credential（authentication token） 發送給 Attacker。authentication token 中帶有 CBT。 CBT 是基于 client 到 server 的這個 TLS 連接的一些屬性所計算出來的（我沒有去研究具體的計算過程）。且這個 CBT 受到了完整性保護，使得攻擊者無法刪除、修改 CBT。具體的完整性保護的方式依認證協議的不同而不同。

  2. Attacker 與 一臺開啟了 Channel Binding 機制的 Server 建立 TLS 連接，將 authentication token 轉發至 Server

  3. Server 接收到 authentication token 后，會基于attacker 到 server 的這個 TLS 連接的一些屬性計算出來一個 CBT，同時取出 attacker 轉發過來的由 client 計算出來的 CBT進行對比。

  4. 對比將會失敗，因為 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 的：

  1. Attacker 通過某種方式觸發 Client 與自己認證，Client 發送給 Attacker 的憑據中帶有 Attacker 的 SPN（因為 Client 是在訪問 Attacker），并且這個 SPN 受到了完整性保護(具體的完整性保護的方式依認證協議不同而不同)，使得 attacker 無法刪除、修改這個 SPN。（需要知道的一點是， NTLM 中也是會涉及到 SPN 的概念的）

  2. Attacker 將憑據轉發至 Server

  3. Server 收到憑據后，檢查憑據中的 SPN，發現 SPN 不是自己的而是 attacker 的，說明這個憑據并不是發給自己的（而是發給 attacker 的），所以認為遇到了 Credential Relay 攻擊，認證將會失敗。

需要注意的是，如果你的服務端程序想要受到 EPA 的保護，則要求：

  1. 運行服務端的操作系統必須支持 EPA（Win7 及 Win 2018 R2 后自動支持，或者可以通過安裝補丁的方式來添加支持）

  2. 你的服務端自身需要做修改，來接入 EPA

  3. 連接服務端的客戶端所在的操作系統要支持 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 的修補方案是怎么做的。

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