CVE-2020-1472，也称Zerologon漏洞。该漏洞为微软2020年8月份补丁日例行更新时公开的漏洞，以其10分的CVSS评分在当时引起诸多研究员重视。在近日的活动期间，国外secura公开了针对该漏洞的扫描检测脚本和whitepaper，不久之后互联网中即公开了漏洞利用的完整exp。国内各安全厂商在短时间对该漏洞进行了各种手段的防御，目前尚未发现该漏洞的大范围利用案例。

Netlogon远程协议是一个远程过程调用（RPC）接口，用于基于域的网络上的用户和计算机身份验证。Netlogon远程协议RPC接口还用于为备份域控制器（BDC）复制数据库。

Netlogon远程协议用于维护从域成员到域控制器（DC），域的DC之间以及跨域的DC之间的域关系。此RPC接口用于发现和管理这些关系。

该漏洞主要是由于在使用Netlogon安全通道与域控进行连接时，由于认证协议加密部分的缺陷，导致攻击者可以将域控管理员用户的密码置为空，从而进一步实现密码hash获取并最终获得管理员权限。成功的利用可以实现以管理员权限登录域控设备，并进一步控制整个域。

• Microsoft Windows Server 2008 R2 SP1
• Microsoft Windows Server 2012
• Microsoft Windows Server 2012 R2
• Microsoft Windows Server 2016
• Microsoft Windows Server 2019
• Microsoft Windows Server version 2004 (Server Core Installation)
• Microsoft Windows Server version 1903 (Server Core Installation)
• Microsoft Windows Server version 1909 (Server Core Installation)

微软官方针对该漏洞的解决方案分成了2部分：

第1部分，首先发布该漏洞的安全更新补丁，补丁地址：https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1472

第2部分，在2021年的Q1完成对所有加入域的设备（包含非Windows设备）的全面保护。

靶机操作：

安装impacket：

使用公开的检测脚本进行检测：

检测结果：

（1）存在漏洞

（2）已安装更新补丁

同样，使用公开的利用脚本（重置密码为空）进行漏洞利用验证：

运行结果（与检测环境不同，但不影响漏洞利用）：

然后，使用空密码获取hash：

这里我使用的powershell，所以会弹出一个cmd，输出hash信息，然后快速关掉，可以使用linux，就会保持窗口不会立刻关闭了：

这里可以拿到administrator的密码hash，然后就可以使用hash进行登录了：

后续操作：

Netlogon Remote Protocol，是在Windows域控上开启的一个RPC接口。它用于执行与用户和计算机身份验证相关的各种task，最常见的是方便用户使用NTLM协议登录服务器。其他功能包括NTP response的身份验证，尤其是可以让计算机在域内更新其密码。 RPC接口可通过TCP（通过域控制器的portmapper服务分配的动态端口）或通过端口445上的SMB管道来使用。

该协议并未使用RPC服务的相同的认证策略，它使用了一种密码学协议来让client（域内）和域控的进行client的账户密码hash的确认，使用这种方式的主要原因是在Windows NT时代，计算机账户不再是首选原则，因此就无法使用类似NTLM或者Kerberos之类的标准用户身份验证方案。

Netlogon session初始化由client完成，client和sever会交换随机的8字节随机数（称为challenges），然后他们都通过使用密钥派生函数将两个challenges与client的账户密码hash混合在一起来计算session key。然后，client使用计算得到的session key计算得到一个client credential。

server重新计算相同的credential，如果与client计算的结果相同，则判定client拥有正确的用户密码以及session key，验证通过。其过程大致如下图所示：

在认证握手阶段，client和server都可以协商是否对subsequent messages进行加密和密码学认证(称为seal and sign)，其主要目的是抵御网络层面的攻击者。如果不使用加密，一些执行重要action的Netlogon call仍然会包含一个authticator值，该值也是使用session key计算获得。

客户端和服务器用于生成凭据值的加密原语由ComputeNetlogonCredential()函数实现，该函数接收一个8字节长度的输入，然后使用session key对其进行转换，然后输出8字节长度的数据。这里保证安全性的基本原则是，不知道session key的攻击者将无法计算或猜测与某个输入匹配的正确输出，那么也就无法获取可以成功实现认证的credential。

在计算credential时可使用的算法有2种：AES-CFB8和2DES。

2DES

在使用2DES进行计算时，计算session key的逻辑如下：

假设bytes(s,e,l)为从字节数组l返回，从s到e 。session key计算完成后，credential按照如下逻辑进行计算：

AES-CFB8

如果client和server之间协商了AES支持，则使用AES-128加密算法使用0初始化矢量在8位CFB模式下计算Netlogon凭据。 其计算过程大致如下：

AesEncrypt是8位CFB模式下的AES-128加密算法，初始化矢量为0。

具体使用哪种算法，是在进行认证时由client进行相关flags的设置。但是，由于现代版本的Windows Server的默认设置都会拒绝使用2DES加密方案，所以大多数的domains都使用AES加密方案。而本次漏洞就产生于这种新发展的加密方案，2DES的旧版加密方案反而没有该漏洞的存在。

基本的AES块密码操作需要16个字节的输入并将其置换为大小相等的输出，为了加密更大或更小的input，需要选择一种mode of operation。在ComputerNetlogonCredential()函数种，仅需要转换8字节数据，选择了CFB8模式。因为该模式比一般的AES的任何一种模式都要慢大约16倍，所以利用范围很有限，大部分情况下都不会选择使用该模式。

AES-CFB8算法的计算过程大致如下：

上述过程示意图如下：

从上面的过程可以看出，为了完成对message的各个字节数据的加密，需要指定一个IV来引导整个过程。IV必须具备唯一性，必须为随机产生，这样对于同一个plaintext才可能产生不同的加密结果。但是，在ComputeNetlogonCredential()函数中，该值被设置为了固定长度、值全为0的16字节数据。但是，使用全0的IV，就一定会出问题吗？概率很低，但不代表没有概率：在256个密钥中总是可以找到1个，对全0的plaintext应用AESCFB8加密将导致全0的ciphertext，其过程如下：

也就是说，如果IV和plaintext均为0，那么有256次机会可以找到一个key，使得最后的计算结果也全为0。实际上，此属性比较通用：当IV仅由0组成时，将存在一个0≤X≤255的整数，该整数表示以n字节开头的X值的明文最终被转换成n个值为0的字节开头的密文。X取决于加密密钥，并且是随机分布的。

到此为止，漏洞内容已经明确：一个全0的输入会导致一个全0的输出。

在通过NetrServerReqChallenge()函数完成challenges交换后，client会调用NetrServerAuthenticate3()函数来进行自身验证，函数原型如下：

该函数的ClientCrendential参数为一个指向NETLOGON_CREDENTIAL结构的指针，该结构中包含client的credential：

credential的计算由ComputeNetlogonCredential()完成，该函数利用NetrServerReqChallenge()函数传来的challenge进行计算，而challenge是完全可以由我们控制的，因此可以设置为8个0。这也就意味着，对于一个正确有效的ClientCredential来说，可以在256次机会中计算得到一个全0的ClientCredential。

因为server在每次认证请求中也会产生一个server challenge，该值也是session key计算的一个参数，也就是说，对于每次认证请求，session key都是不同的。但是因为计算机并没有做防爆破的机制，登录认证失败后可以一直尝试登录，所以可以进行256次爆破，直到找到正确的key。

虽然通过第一步可以实现身份验证绕过，但是对于Netlogon的传输加密机制（RPC signing and sealing）来说，我们不知道session key到底是多少。但是，singing和sealing是可选项，可以通过在NetrServerAuthenticate3()函数中取消设置对应的标志位来关闭这2个选项。在现代的client中，默认是拒绝接受未设置这2个flag的server的连接请求的，但是server并不拒绝client的连接请求。所以，我们可以在进行攻击时手动关闭这2个flag。

即使禁用了加密，每个执行某些敏感操作的函数调用也必须包含一个Authenticator值。 该值的计算通过使用ComputeNetlogonCredential(带有会话密钥)计算ClientStoredCredential + Timestamp获得：

ClientStoredCredential是client维护的一个增量值。 执行握手时，它会初始化为与我们提供的ClientCredential相同的值。 因为client credential全0，因此对于身份验证后执行的第一个调用，ClientStoredCredential的值为0。
TimeStamp为NETLOGON_AUTHENTICATOR结构中的TimeStamp字段，包含当前的Posix时间。 但是事实上，server并未对该值设置多少限制，因此可以简单地设置为1970年1月1日，即值设为0。
经过第一步后，我们知道ComputeNetlogonCredential(0)=0。因此，可以通过简单地提供全零authenticator和全零TimeStamp来验证第一个调用。

经过前3步后，我们已经可以向任何计算机发起Netlogon的请求。接下来，一种思路是调用NetrServerPasswordGet()函数来获取计算机密码的NTLM哈希。但是，哈希利用了另外一种机制使用session key进行加密，所以该函数无法利用。退而使用NetrServerPasswordSet2()函数，其主要作用为client设置新的计算机密码，函数原型如下：

这种密码没有hash，但是使用session key进行了加密。可以再次使用CFB8和全0的IV进行解决。

plaintext密码结构包含516个字节，最后的4个字节指明了密码长度（字节为单位）。结构中所有不属于密码功能的字节都被视为填充，并且可以具有任意值。如果我们提供516个0，那么加密结果就是516个0。实际上，计算机并不禁止设置空密码，所以这里使用516个0可以登录域上的任意一台计算机。完成后，可以代表此计算机建立新的Netlogon连接。 这次计算机的密码是空的，因此可以正常使用该协议。 如果需要，现在还可以设置任何其他非空密码。其过程大致如下：

以这种方式更改计算机密码时，只能在AD中更改。 目标系统本身仍将在本地存储其原始密码。 然后，该计算机将无法再向域进行身份验证，并且只能通过手动操作来重新同步。 因此，可以将任何设备锁定在域之外。 同样，只要计算机帐户在域中具有特殊特权，现在就可以滥用这些特权。

后续可能跟渗透关系更大，个人对渗透了解不多，可能理解有误。

到此为止，可以更改的计算机的密码是DC本身的密码，AD中存储的DC密码与存储在本地注册表（HKLM\SECURITY\Policy\Secrets\$machine.ACC）中的并不相同。这可能会造成DC发生一些不可预知的行为。但是依旧可以登录。只需要运行Impacket的secretsdump脚本就可以让DC的密码生效，该脚本会利用复制DRS协议通过域的从域中提取所有用户HASH，包括域管理员HASH（包括krbtgt，可以用来制作金票），然后用来登录DC更新电脑密码注册表，就可以令攻击者成为域管理员。

针对该漏洞的poc目前有2种，1种是检测脚本，1种是完整的漏洞利用脚本。

检测脚本的代码分析如下：

其实本质上来说，漏洞检测脚本也是利用了漏洞了，尝试登录多次，根据是否登录成功来判断是否存在漏洞。某种意义上来说，这不算一种无损检测。

漏洞利用的脚本关键代码如下：

跟前面的利用思路一致，利用脚本相比检测脚本多了设置为空密码的过程。因为impackt中已经实现了大部分主要功能，所以exp开发难度不大。

此处只对关键流量做一些分析，在DCERPC调用正式开始前还有一些SMB通信的相关流量，因为跟漏洞关系不大，此处不做赘述。

从流量包中可以明显看出爆破特征，在RPC_NETLOGON的流量之前，会有DCERPC和EPM的相关流量。上图的一个竖型红框为一组爆破流量。

每组流量首先在DCERPC协商阶段协商使用的端口，即使用动态端口。因为操作系统版本为Windows Server 2008或的公告版本，所以使用的端口为高端口，范围为49152~65535。因为没有使用固定端口，为流量检测带来一定难度。

在流量中，并没有发现NetrServerReqChallenge()的明显特征，当然，这里的Client Challenge的全0值可以作为漏洞特征进行识别。除此之外，并未发现其他明显特征。

相比NetrServerReqChallenge()函数的流量特征，NetrServerAuthenticate3()函数多了Negotiation options，该字段的以Authenticated RPC supported和AES support位的设置，对漏洞的成功利用具有重要作用，因此Negotiation options字段的流量特征和全0的Client Crenditial的流量特征，可以作为识别该漏洞的最明显特征。

微软在8月份发布了针对该漏洞的安全更新方案。与普通漏洞的安全更新不同，微软打算分阶段完成针对该漏洞的完整防御，但其声称在安装完8月份的安全更新后即可防御该漏洞。可以初步推断，微软打算替换现有的认证方案。考虑到域环境的复杂性，需要花费一定的时间来确认新方案的可行性。

目前，微软官方对Netlogon协议的官方说明文档已经做了更新，部分重要更新如下：

使用的文件版本来自Windows Server 2016，更新前文件版本号为：10.0.14393.1737，更新后版本号为：10.0.14393.3866。

直接看NetrServerAuthenticate3()函数，改动总体上较大，但尚不确定针对该漏洞具体有效的更新。看关键的大改部分：

在IDA中看下新增对NlIsChallengeCredentialPairVulnerable()函数的调用：

进入到新函数NlIsChallengeCredentialPairVulnerable()内部：

根据上述代码，我们可以得到该函数的大致逻辑：

client提供的challenge存储在rcx指向的buffer中；

检查一些全局变量，如果为1，则函数返回0，表示不存在漏洞。

检查rcx为非空，检查rdx为非空。

challenge的第1个字节存储在r9d中，然后在循环中将接下来的4个字节与它进行比较。如果这4个字节中的任何一个与第1个字节都不相同，则该函数返回0，不存在漏洞；否则返回1，存在漏洞。

这种修复方式针对的主要是当前已公开的poc和exp，即challenge全0的情况（也可以变形成其他的全1或者全2等情况）。这种防御逻辑其实比较简单，现在还无法判定是否可以实现更进一步的补丁绕过。

现在针对该漏洞的检测脚本已经在互联网中进行公开，本质上来说，公开的脚本因为尝试了使用空凭据登录，不能算作无损检测。尚未发现其他的检测方法。（终端侧的补丁检测和文件版本扫描除外）

流量侧防御较为简单，根据Negotiation options字段的流量特征和全0的Client Crenditial的流量特征外加爆破限制即可实现针对目前所有公开exp的攻击，本质上来说也算是从漏洞原理侧进行了防御。

正如补丁分析所说，针对该漏洞的终端侧防御可以考虑使用热补丁的方，但是否存在风险需要进一步验证。

看雪内部共享，未经允许，请勿擅自转载。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)