Question

本节将讨论最后一个概念。本文反复提到过，身份验证层，即 NTLM 消息，几乎独立于应用层使用的协议（SMB、LDAP 等）。 说「几乎」是因为已经看到一些协议使用 NTLM 消息标志来表明会话是否必须签名。

在任何情况下，就目前而言，攻击者很有可能从协议 A 中检索 NTLM 消息，然后使用协议 B 将其发回，称为跨协议中继。

因此，存在一种新的保护措施来对抗这种攻击。这称为通道绑定( Channel Binding )，或 EPA（增强型身份验证保护）。这种保护的原则是将身份验证层与使用中的协议绑定，即使存在 TLS 层（例如 LDAPS 或 HTTPS）。总体思路是，在最后一条 NTLM AUTHENTICATE 消息中，有一条信息放在那里，攻击者无法修改。此信息指示所需的服务，以及可能包含目标服务器证书哈希的另一个信息。

8.1 Service binding

第一类保护方法很容易理解。如果客户端希望对服务器进行身份验证以使用特定服务，则会在 NTLM 响应中添加标识该服务的信息。

这样，当服务器收到这个认证后，就可以看到客户端请求的服务，如果与实际请求的不一样，就不会同意提供该服务。

由于服务名称在 NTLM 响应中，因此它受到 NtProofStr 响应的保护，该响应是此信息、质询和其他信息（例如 msAvFlags ）的 HMAC_MD5 。它是用客户端的密钥计算的。

在上图的示例中，客户端尝试通过 HTTP 向服务器验证自己的身份。除了服务器是攻击者，并且攻击者将此身份验证重放到服务器，以访问网络共享 (SMB)。

除了客户端在他的 NTLM 响应中指明了他想要使用的服务，并且由于攻击者无法修改服务信息，攻击者只能按原样重放它。服务器然后接收到最后一条消息，将攻击者（SMB）请求的服务与 NTLM 消息（HTTP）中指定的服务进行比较，拒绝连接，发现两个服务不匹配。

具体来说，所谓的服务其实就是 SPN ( Service Principal Name )。下图是客户端在其 NTLM 响应中发送 SPN 的数据包。

可以看到它表示客户端将使用 CIFS 服务。将此信息中继到 LDAP 服务器将导致服务器拒绝访问。

同时，该属性不仅有服务名称 (CIFS)，还有目标名称或 IP 地址。 这意味着如果攻击者将此消息中继到服务器，服务器也会检查 IP 等字符串，不一致会拒绝连接。

8.2 TLS binding

TLS binging 此保护的目的是将身份验证层（即 NTLM 消息）链接到可能使用的 TLS 层。

如果客户端想要使用封装在 TLS 中的协议（例如 HTTPS、LDAPS），它将与服务器建立 TLS 会话，并计算服务器证书哈希。此哈希称为通道绑定令牌 ( CBT )。 计算完成后，客户端会将这个哈希值放入其 NTLM 响应中。 然后，服务器将在身份验证结束时接收 NTLM 消息，读取提供的哈希值，并将其与其证书的真实哈希值进行比较。 如果不同，则表示不是 NTLM 信息的原始接收者。

同样，由于此散列在 NTLM 响应中，因此它受 NtProofStr 响应的保护，就像服务绑定的 SPN 一样。

由于存在这种类型的保护，以下两种攻击场景就不可能再发生：

1. 如果攻击者想从使用不带 TLS 层的协议的客户端中继到带 TLS 层的协议（例如 HTTP 到 LDAPS），则攻击者由于不能更新 NtProofStr，导致无法将来自目标服务器的证书哈希添加到 NTLM 响应。
2. 如果攻击者想从一个带有 TLS 的协议中继到另一个带有 TLS 的协议（例如 HTTPS 到 LDAPS），在客户端和攻击者之间建立 TLS 会话时，攻击者将无法提供服务器证书，因为它不匹配攻击者的身份。因此，它必须提供伪造的自签证书，以识别攻击者。客户端然后会散列这个证书，当攻击者将 NTLM 响应中继到合法服务器时，响应中的证书 Hash 与真实证书的 Hash 不同，服务器将拒绝身份验证。

下面是说明该种方式的示意图。

图中体现了两个 TLS 会话的建立。一种介于客户端和攻击者之间（红色），一种介于攻击者和服务器之间（蓝色）。客户端将接收攻击者的证书，并计算一个哈希值，即红色的证书哈希值。

在 NTLM 交换结束时，此散列将添加到 NTLM 响应中，并且将受到保护。服务器收到这个 hash 后，会 hash 自己的证书，结果不一样，拒绝连接。