本文作者：奇安信代码安全实验室

漏洞简介

CVE-2020-1472是一个windows域控中严重的远程权限提升漏洞。由于微软在Netlogon协议中没有正确使用加密算法而导致的漏洞，微软在进行AES加密运算过程中，使用了AES-CFB8模式并且错误的将IV设置为全零，这使得攻击者在明文(client challenge)、IV等要素可控的情况下，存在较高概率使得产生的密文为全零。下面就整个攻击过程做一个简要分析。

漏洞原理

Netlogon协议是微软提供的一套域访问认证协议，不同于大部分rpc服务，该协议使用的并不是典型的微软认证方式如NTLM\Kerberos，该协议的通信流程如下：

图1-1

图1-1中攻击者可控的因素有client challenge,攻击者将它设置为全0，server challenge在每一轮认证过程中都会变化，secret对应于用户密码的hash，Encrypt的过程采用的是AES-CFB8，其运算过程如下：

图1-2

在图1-2中，黄色部分内容即为IV,微软错误的将其设置为全0，而实际上为了保证AES算法的可靠性该部分内容应该随机生成，黄色部分后紧接着的蓝色部分为明文，对应于client challenge,该部分内容攻击者可控，设置为全0，AES使用的key是将secret、challenge进行运算后得到的值，也就是说，key会随着每一轮server challenge的变化发生变化，那么如果IV和client challenge为全0的话，那么整个AES运算过程变成图1-3所示：

图1-3

如图1-3所示，在第一轮AES运算过程中，密文(黑色部分)第一个字节为0的概率是1/256，这是因为一个字节有8位，全为0的概率是1/256，那么由这运算得到的密文第一个字节0x0和IV以及后面全0的client challenge计算后得到的新一轮”明文”依旧为全0，同样进行AES运算，由于第二轮运算时明文 密钥和第一轮都一致，那么这一轮所产生的密文第一个字节也同样是0，接下来几轮计算原理以此类推，所以每一次连接都是由1/256的概率产生一个全0的密文，最理想的情况即是256次就一定能完成碰撞。因此Client challenge设置全0后，客户端凭据(8字节)通过验证的概率就从1/2^64提高到了1/256。

通过上述碰撞方法，攻击者便完成了域身份认证，在接下来的攻击过程用类似的方法也bypass了对call的校验，最后通过相关调用完成对域控密码的修改。值得注意的是由于整个碰撞过程中session key一直是未知的，攻击者可以通过NetrServerAuthenticate3设置合适的flag使得剩下的通信过程不使用session key进行加密。

一言以蔽之，Netlogon协议身份认证采用了挑战-响应机制，其中加密算法是AES-CFB8，并且IV默认全零，导致了该漏洞产生。又因为认证次数没做限制，签名功能客户端默认可选，使得漏洞顺利被利用。

漏洞验证

1．无法获取域内用户凭据信息

2．执行PoC测试

3. 可以看到DC01的密码置空，然后获取域内凭据信息

参考链接：