Question

在前文阐述了会话签名和身份认证签名，提及到要签名时需要获得用户的密钥。在关于 MIC 的小节中也提到过，实际上使用的并不完全是用户的密钥，而是 Session Key，它基于用户密钥生成。

以下是为 NTLMv1 和 NTLMv2 计算 Session Key 的方法：

# For NTLMv1
Key = MD4(NT Hash)

# For NTLMv2
NTLMv2 Hash = HMAC_MD5(NT Hash, Uppercase(Username) + UserDomain)
Key = HMAC_MD5(NTLMv2 Hash, HMAC_MD5(NTLMv2 Hash, NTLMv2 Response + Challenge))

有了这些算法，客户端可以完成 Session Key 的计算。但是，在域环境中，服务器由于没有用户密钥不能独立完成。对于本地身份验证，是没有问题的。

因此，对于域帐户的身份验证，服务器会让域控制器为它计算 Session Key，然后将其返回。服务器以 NETLOGON_NETWORK_INFO 结构向域控制器发送请求，域控制器以 NETLOGON_VALIDATION_SAM_INFO4 结构响应。如果身份验证成功，会话密钥将在域控制器的此响应中发送。

那么问题就出现了，如果攻击者构造出与目标服务器向域控制器发出的相同请求，就同样可以获得 Session Key，即：CVE-2015-005 。

域控制器没有验证正在发送的身份验证信息是否实际上是针对请求此操作的加入域的机器（例如 NetrLogonSamLogonWithFlags()）。这意味着任何加入域的机器都可以验证针对域控制器的任何传递身份验证，并获取域内任何会话的 Session Key。

所以，微软已经修复了这个 BUG。为了验证只有用户进行身份验证的服务器有权请求会话密钥，域控制器将验证 AUTHENTICATE 响应中的目标计算机与发出 NetLogon 请求的主机相同。

在 AUTHENTICATE 响应中，我们详细说明了 msAvFlags 的存在是为了表明 MIC 是否存在。但还有其它信息，例如目标机器的 Netbios 名称。

这是与发出 NetLogon 请求的主机进行比较的机器名称。因此，如果攻击者尝试对 DC 进行 NetLogon 请求，由于攻击者的名称与 NTLM 响应中的目标主机名不匹配，域控制器将拒绝该请求。

最后，与 msAvFlags 一样，在计算 NTLMv2 Hash 时，包含了机器名称，因此，不能在 NTLM 响应中修改机器名称。