Question

上文中以 SMB、LDAP 两个协议为例，阐述了如何保护会话免受中间人攻击。为了进一步阐述 MIC 的作用，再举一个具体的案例。

6.1 经典案例

假设攻击者设法将自己置于中间人位置，并且通过 SMB 接收身份验证请求。知道域控制器需要 SMB 签名，攻击者不可能通过 SMB 中继进行攻击。另一方面，正如前文所述，由于身份验证和会话相互独立，因此中继攻击时可以更改协议的，并且攻击者决定中继到 LDAPS 协议。

在身份验证数据中存在 NEGOTIATE_SIGN 标志，该标志仅用于指示客户端和服务器是否支持签名。但在某些情况下，这个标志会被考虑在内，如上文中描述的 LDAP 协议那样。

对于 LDAPS，服务器也会同样使用此标志位。LDAPS 是基于 TLS 的 LDAP， TLS 负责处理数据包签名 （和加密）的。因此，如果服务器收到 NEGOTIATE_SIGN 标志设置为 1 的身份验证请求，LDAPS 客户端没有理由表明它可以签名数据包，因此，服务端将拒绝身份验证。

在上面设想的攻击流程中，客户端想要通过 SMB 进行身份验证，它支持数据包签名，并将 NEGOTIATE_SIGN 标志设置为 1。但是如果我们中继其身份验证，而无需更改任何内容，通过 LDAPS，然后 LDAPS 服务器将看到此标志，并会终止身份验证。

可以简单地修改 NTLM 消息并删除标志么？如果可以，上面的攻击场景就成立。但是，除了在 NTLM 级别的签名外，还有另一个签名。该签名称为 MIC ，或 消息完整性代码 。

6.2 MIC - Message Integrity Code

MIC 是仅在 NTLM 身份验证的最后一条消息 AUTHENTICATE 消息中发送的签名。该签名在计算时会包含 NTLM 认证的 3 条消息。 MIC 使用 HMAC_MD5 函数计算，密钥为基于用户密钥生成的密钥，称为会话密钥( Session Key )。

HMAC_MD5(Session key, NEGOTIATE_MESSAGE + CHALLENGE_MESSAGE + AUTHENTICATE_MESSAGE)

重要的是会话密钥取决于用户的密钥，因此攻击者无法重新计算 MIC。

下图为 MIC 的样例：

因此，如果 3 个消息中只要有一个被修改，则 MIC 将不再有效。所以不能像直接更改 NEGOTIATE_SIGN 标志。

由于 MIC 是可选的，如果只是移除 MIC 呢？但是，这样做并不会有效果。因为还有另一个标志位表明 MIC 将出现，即 msAvFlags 。 它也存在于 NTLM 响应中，如果它是 0x00000002 ，则向服务器表名必须存在 MIC。因此，如果服务器没有看到 MIC，它就会终止身份验证。

如果将 msAcFlags 设置为 0，然后再移除 MIC 呢？

事实证明， NTLMv2 Hash ，即客户端对 Challenge 的响应，它不仅考虑了 Challenge，而且还考虑了响应的所有标志。表示 MIC 存在的标志是此响应的一部分。

更改或删除此标志将使 NTLMv2 Hash 失效，因为数据将被修改。

MIC 保护 3 条消息的完整性， msAvFlags 保护 MIC 的存在，NTLMv2 哈希保护标志的存在。攻击者不知道用户的密钥，也无法重新计算这个哈希。

6.3 Drop the MIC

CVE-2019-1040 ：Drop the MIC 漏洞。该漏洞指出：如果直接移除 MIC，即使该标志表明其存在，服务器也会接受身份验证。

可以使用 ntlmrelayx 工具中的 --remove-mic 参数来删除 MIC。