漏洞点⼆：错误设置CFB8模式
建⽴安全通道时，需要使⽤ComputeNetlogonCredential函数对客户端的Netlogon凭据输⼊client challenge和服 务器的Netlogon凭据输⼊server challenge (SC）进⾏加密，ComputeNetlogonCredential函数⽀持使⽤AES-128 加密算法和DES_ECB 进⾏加密，采⽤哪种加密算法在NetrServerAuthenticate3 (Opnum 26)或 NetrServerAuthenticate2（Opnum 15）⽅法中的NegotiateFlags（32 位位标志，可协商选项）中进⾏定义，例 如使⽤AES-128 加密算法，如图6-所示。
图6- NegotiateFlags 标志
漏洞点1:错误使⽤了 AES-128 加密算法，ComputeNetlogonCredential函数使⽤的是名为在8位CFB模式下使⽤零 初始向量的AES-128加密算法：
复制
CFB是⼀种分组密码，可以将块密码变为⾃同步的流密码，CFB8模式下加密过程，如图6- 所示： 1.将明⽂拆分为N份，C1，C2，C3，然后定义⼀个初始向量IV；
2.第⼀先将轮加密初始向量IV，然后异或明⽂得到第⼆轮的密⽂，加密第⼆轮的密⽂，异或明⽂得到第三轮的密 ⽂；
图6- CFB加密过程 其加解密公式如下：
这种加密算法要求IV每次都要随机不同，然⽽ComputeNetlogonCredential 函数中IV却是固定，即 IV=000000000000000000000000000000，现在如果我们控制输⼊的明⽂为0000000000000000，那么整个加密 过程变量为在AES加密中的Key（AES加密使⽤的Key会随着每⼀轮Server Challenge的变化⽽变化）。但是因为 AES 是⼀种没有统计偏差的⾼质量密码，输⼊任何使⽤密钥加密的字符，输出中的每个位为0或1的概率都为 50%，所以8个输出位全为零的⼏率为1/256，所以如果我们控制明⽂内容为0000000000000000然后不断的进⾏ 运算，那么⼀定存在⼀个Key，使得密⽂为00000000，如图6- 所示。
图6- IV和明⽂为0的运算过程
所以配合漏洞点⼀中的利⽤，我们可以通过关闭签名校验，然后发送⼤量的ClientCredential （0000000000000000）请求来进⾏验证（如图6- 所示），直⾄服务器那端计算出来的密⽂hash也全是0，就可认 证通过，如图6- 所示
图6- 发送⼤量ClientCredential
