漏洞简讯

CVE-2020-1472 NetLogon 权限提升漏洞是微软8月份发布安全公告披露的紧急漏洞，CVSS漏洞评分10分，漏洞利用后果严重，未经身份认证的攻击者可通过使用 Netlogon 远程协议（MS-NRPC）连接域控制器来利用此漏洞。成功利用此漏洞的攻击者可获得域管理员访问权限。

协议分析

Netlogon 服务用于维护计算机与对域中的用户和其他服务进行身份验证的域控制器之间的安全通道，Netlogon 客户端和服务端之间通过RPC调用来进行通信。在进行正式通信之前，双方需进行身份认证并协商出一个 SessionKey。SessionKey 将用于保护双方后续 RPC 通信流量。以下为 Netlogon 身份验证握手流程：

首先由客户端发起挑战（传送Client challenge），服务端响应Server challenge，然后双方都使用共享的密钥以及来自双方的 challenges 进行计算得到 SessionKey，这样双方就拥有了相同的 SessionKey 以及 Client challenge 和 Server challenge。然后客户端使用 SessionKey 作为密钥加密 Client challenge 得到 Client credential 并发送给服务端，服务端也采用相同的方法计算出一个 Client credential，比较这两者是否相同，如果相同，则客户端身份认证成功，然后双方对调来验证服务端的 Server credential，如果成功，则说明双方身份认证成功且拥有相同的 SessionKey，后续可采用该密钥进行加密和完整性保护。

• SessionKey 计算过程
  如果双方协商了AES support，就会采用 HMAC-SHA256 算法来计算 SessionKey，具体流程如下：

  使用MD4算法对密码的 Unicode 字符串进行散列得到 M4SS，然后以 M4SS 为密钥采用 HMAC-SHA256 算法对 ClientChallenge + ServerChallenge 进行哈希得到 SessionKey，取 SessionKey 的低16个字节作为最终的 SessionKey。

  1 2 3 4 5 6 7 8

  ComputeSessionKey(SharedSecret, ClientChallenge, ServerChallenge) M4SS := MD4(UNICODE(SharedSecret)) CALL SHA256Reset(HashContext, M4SS, sizeof(M4SS)); CALL SHA256Input(HashContext, ClientChallenge, sizeof(ClientChallenge)); CALL SHA256FinalBits (HashContext, ServerChallenge, sizeof(ServerChallenge)); CALL SHA256Result(HashContext, SessionKey); SET SessionKey to lower 16 bytes of the SessionKey;

• Credential 计算过程
  如果双方协商了AES support，后续会采用 AES-128 加密算法在 8 位 CFB 模式下计算 Credential（来自MS-NRPC文档）。 其计算过程大致如下：

  在 ComputeNetlogonCredential 函数中将 IV 初始化为 0，Input 接收 Challenge，使用 IV、SessionKey 对 Input 进行加密，AesEncrypt 使用的算法为 8 位 CFB 模式的 AES-128。

  1 2 3

  ComputeNetlogonCredential(Input, SessionKey, Output) SET IV = 0 CALL AesEncrypt(Input, SessionKey, IV, Output)

下面来插播一下 AES-CFB8 算法，如下所示：

首先初始化随机 IV（16字节），对 IV 进行 AES 运算，将结果的第一个字节与 PLAINTEXT（可对应上面算法的 Input） 的下一个字节进行异或，将异或结果放在 IV 末尾，IV 整体向前移1位。然后重复上述 "加密->异或->移位" 操作，直到取出了 PLAINTEXT 中的所有字节。最后得到 CIPHERTEXT（对应上面算法的 Output，其长度与 Input 相同）。

然而，Netlogon 在计算 Credential 的过程中直接将 IV 初始化为 0，这会使 AES-CFB8 算法更加脆弱，Secura 的研究人员在阅读 Microsoft 文档时发现了这个安全问题。由于在认证过程中 SessionKey 是随机的 (至少 ServerChallenge 是随机的，所以 SessionKey 一定是随机的)，因而对 IV 进行 AES 块加密得到的结果也是随机的，但只有结果中的第一个字节有机会参与后续运算，这个字节为 X 的概率为 1/256（一个字节可能的结果为 0 ~ 255）。那么我们假设第一轮 IV（全0） 加密结果的第一个字节为 X，我们就知道全 0 的输入可以获得输出 X ，因而我们可以构造 Challenge 为 XXXXXXXY，使得每一次异或的结果都为 0（除了最后一次，最后一位不参与加密运算），因为每一次加密结果的第一个字节都是 X，与 X 进行异或还是 0 ，因而每一轮的 "IV" 还是全 0 的。这样加密结果是可以预测的，我们可以得到一个确定的 Credential：00 00 00 00 00 00 00 (X Xor Y)。因而在平均 256 次尝试之后，可以成功使用 00 00 00 00 00 00 00 (X Xor Y) 模式的 Credential 欺骗服务器认证通过而无需知道真正的密码以及 SessionKey，利用的关键是获得一个对全 0 IV 进行加密之后得到结果的第一字节为 X 的环境。POC 中选择将 X、Y 设置为 0，如下所示：

• Authenticator 认证
  在协商出 SessionKey 后，客户端就可以申请远程调用了，如 POC 中使用的 NetrServerPasswordSet2，这也是简略流程图中的最后一步。除了 NetrLogonSamLogonEx 之外，所有需要安全通道的调用都将使用 Netlogon Authenticator。Authenticator 结构如下所示，包括 8 字节的 Credential 和 4 字节的 Timestamp。

  1 2 3 4 5

  typedef struct _NETLOGON_AUTHENTICATOR {  NETLOGON_CREDENTIAL Credential;  DWORD Timestamp; } NETLOGON_AUTHENTICATOR, *PNETLOGON_AUTHENTICATOR;

  客户端在每次发送新请求时，都会记录当前时间戳（ClientAuthenticator.Timestamp，表示自1970年1月1日（UTC）00:00:00起的秒数），然后更新 ClientCredential（之前的 ClientCredential 加 Timestamp），然后以 SessionKey 为密钥使用之前协商的加密算法计算出 ClientAuthenticator.Credential，之后将 Authenticator 附在调用请求中一起发送给服务端。

  1 2 3 4 5

  SET TimeNow = current time; SET ClientAuthenticator.Timestamp = TimeNow; SET ClientStoredCredential = ClientStoredCredential + TimeNow; CALL ComputeNetlogonCredential(ClientStoredCredential, Session-Key, ClientAuthenticator.Credential);

  服务端接收到请求后将采用相同的步骤计算 TempCredential（ ClientCredential 和 SessionKey 是一致的），比较 TempCredential 和 客户端发来的 ClientAuthenticator.Credential 是否一致，一致则通过客户端认证。然后服务端将 ClientCredential 加1之后进行同样的运算，得到 ServerAuthenticator.Credential ，将 Authenticator 附在响应包中。

  1 2 3 4 5 6 7 8

  SET ServerStoredCredential = ServerStoredCredential + ClientAuthenticator.Timestamp; CALL ComputeNetlogonCredential(ServerStoredCredential, Session-Key, TempCredential); IF TempCredential != ClientAuthenticator.Credential THEN return access denied error SET ServerStoredCredential = ServerStoredCredential + 1; CALL ComputeNetlogonCredential(ServerStoredCredential, Session-Key, ServerAuthenticator.Credential);

  然后客户端更新 ClientCredential（自加1），进行同样的运算得到 TempCredential ，判断 TempCredential 和服务端发来的 ServerAuthenticator.Credential 是否一致，一致则通过认证，否则重新建立安全通道。

  1 2 3 4 5

  SET ClientStoredCredential = ClientStoredCredential + 1; CALL ComputeNetlogonCredential(ClientStoredCredential, Session-Key, TempCredential); IF TempCredential != ServerAuthenticator.Credential THEN return abort

POC复现分析

使用公开的POC进行漏洞复现，如下所示，目标系统存在该漏洞，密码成功被置为空。

同时使用Wireshark抓包，前面说过 Netlogon 采用 RPC（Remote Procedure Call Protocol，远程过程调用协议）来进行通信。RPC 是一种通过网络从远程计算机程序上请求服务而不需要了解底层网络技术的协议。RPC 允许用户在程序中调用一个函数，而这个函数将在另外一个或多个远程机器上执行，并将结果返回给最初进行 RPC 调用的机器，在这个过程中RPC体系会替用户完成网络上连接建立、会话握手、用户验证、参数传递、结果返回等细节问题，使得远程过程调用和本地函数调用一样方便。因而，我们直接关注用户验证阶段就好。

注意 NetrServerReqChallenge 和 NetrServerAuthenticate3 请求&响应包，直接翻到最后一组。NetrServerReqChallenge 请求包将 Server Handle、Computer Name 以及 Client Challenge 序列化数据发送至服务端，其中，Client Challenge 为 "00 00 00 00 00 00 00 00"。

服务端返回 Server Challenge 为 "7a 06 53 36 16 8d 5f 78"。

发送 NetrServerAuthenticate3 请求，传送 Server Handle、Client Credential、Negotiation options等参数，Client Credential 依旧还是 "00 00 00 00 00 00 00 00"。其实，在每次尝试中 Client Challenge、Client Credential 都是 8 字节全零数据，只有最后一次认证成功了（成功了就不用尝试了呢）。

这次，服务端返回认证成功的代码（STATUS_SUCCESS），Server Credential 和服务端身份认证相关，不必关注。只需要记得这次使得身份认证成功的 Server Challenge 为 "7a 06 53 36 16 8d 5f 78" 就好，后面会有个小验证。

再接下来是发送 NetrServerPasswordSet2 请求，如下图所示，参数为 Server Handle（PrimaryName），还有一些 Wireshark 没有识别出来的参数 AccountName、SecureChannelType、ComputerName、Authenticator、ClearNewPassword，我按照格式用不同颜色的笔标记出来了，其中，Authenticator 和 ClearNewPassword 都是全 0 的：

然后服务端返回其 Authenticator，至此密码已成功被置为空。

逆向分析

POC中先后调用了 NetrServerReqChallenge 函数和 NetrServerAuthenticate3 函数。因而，服务端会通过 NetrServerReqChallenge 函数接收 ClientChallenge 并生成 ServerChallenge，在接收到 NetrServerAuthenticate3 请求后会调用 NetrServerAuthenticate3 函数进行认证。以下为两个函数原型，可对比抓包数据来看，其中，in 和 out 分别对应了客户端和服务端请求响应的参数。

重点来看服务端对客户端身份认证环节，在 NetrServerAuthenticate3 函数中会调用 NlMakeSessionKey 函数计算 SessionKey，然后调用 NlComputeCredentials 函数计算 ClientCredential，比较客户端发来的 ClientCredential 和自己计算出来的是否相同。

在计算 ClientCredential 的过程中会调用 SymCryptCfbEncrypt 函数进行 AES-CFB8 运算，如下所示，会循环调用 SymCryptAesEncrypt 函数对数据块进行加密， IV 被初始化为 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00。

将上述流程使用 python 实现，设置 Client Challenge 为 41 41 41 41 41 41 41 41（即 X 为 0x41，Y 为 0），随机生成 Server Challenge，打印每次的 SessionKey 和 ClientCredential，看会不会出现全 0 的 ClientCredential：

在经过 2000 次测试之后，发现成功需要平均的次数为 252，已经很接近 256 了，理论上测试次数越多越接近 256。幸运的是，在每一次测试中都在 2000 次之内得到了全 0 的 ClientCredential。

稍微修改一下代码，对抓包得到的 Server Challenge 进行测试，可发现成功得到全 0 的 Client Credential，服务端计算的 Authenticator.Credential 为 01 55 c7 b5 50 3b 23 ab（和抓包数据相吻合）。

POC 中的下一步是调用 NetrServerPasswordSet2 将密码置空，以下为 NetrServerPasswordSet2 函数原型，在该函数调用请求中需要提交 Authenticator 认证数据（NETLOGON_AUTHENTICATOR 结构）以及 ClearNewPassword 数据（NL_TRUST_PASSWORD 结构）。

NETLOGON_AUTHENTICATOR 前面介绍过，包括计算得到的 Credential 和当前的 Timestamp；NL_TRUST_PASSWORD 结构体中包括 Buffer（Unicode类型，512 字节）和 4 字节的 Length（指明 Password 长度）。

如果表示计算机账户密码，Buffer 中的前 512 - Length 个字节必须为随机数，作为加密熵源，后面 Length 个字节为密码。

服务端在获取到客户端发送的 Authenticator 中的 timestamp 后，只是判断该值是否为0xFFFFFFFF，如果不是的话就直接使用用户发送的 timestamp 进行后续计算（计算过程前面已经分析过）。如下所示，在 netlogon!NlCheckAuthenticator 函数中验证Authenticator，采用 NlComputeCredentials 函数计算 Credential，由于还是使用同一条件下的算法（相同的 IV 和 SessionKey），因而使用和之前 Client Challenge 相同的输入依然可以得到全 0 输出，POC 中使用的 timestamp 还是0，这样 timestamp 加上之前计算得到的 Credential 后还是全 0 的，计算出的 TempCredential 也还是全 0，这样我们使用 00 00 00 00 00 00 00 00 的 Authenticator.Credential 就可以通过验证。由于 timestamp 的长度为 4 个字节，因而在前面的模式中只有 X 取 0 的情况下可以通过验证，即 Client Challenge、Client Credential、Authenticator.Credential 都为 00 00 00 00 00 00 00 Y，Authenticator.timestamp 为 0。

Authenticator 认证通过后会调用 NlDecrypt 函数对 TRUST_PASSWORD 进行 8 位 CFB 模式 AES-128 解密，在进行一些判断后会调用 NlSetIncomingPassword -> NlSamChangePasswordNamedUser -> SamISetMachinePassword 设置密码。以下为测试，随意填充 ClearNewPassword 结构，这里我将密码长度设置为 0x10，密码为 "testtest" ，其余数据用 00 填充（应该是随机数）。理论上这个结构应该进行 8 位 CFB 模式的 AES-128 加密，但我们不知道原来的密码，也算不出 SessionKey，所以干脆就这样啦。解密之后长度变成了 0xc6e8ca2，由于后面会有是否大于 0x200 的判断，将其手动修改为 0x10，然后继续运行程序。

解密后的密码为 "74 7d 5d be 3e 03 af cc 2e cb b8 52 1c 4b af f5"，使用 MD4 散列算法进行运算得到 2d7091de951698701d2c34e3ccec0596，使用此哈希可从域控制器中复制用户凭据：

现在再来回顾一下漏洞模式，由于我们可以走到这里，说明客户端和服务端直接已经协商出了给定输入 00 就可以得到 AES 块加密结果第一个字节为 00 的 SessionKey，如果我们给出 516 个 00，那么 8 位 CFB 模式 AES-128 加密的结果也是 516 个 00。我们将 ClearNewPassword 结构填充为 516 个 00 ，这样系统在解密的时候得到的结果也是 516 个 00，这样密码的长度字段就被解析为 0，账户密码被置空。

然后可以使用 wmiexec 拿到域控制器中的本地管理员权限（后面恢复密码的操作就不介绍了，教程很多）：

测试

使用前面总结的 00 00 00 00 00 00 00 Y 模式进行漏洞利用，这里 Y 为 0x41，ClearNewPassword 结构完全置零，成功将密码置空。以下为抓包数据：

1、NetrServerReqChallenge 请求，Client Challenge 为 00 00 00 00 00 00 00 41

2、NetrServerAuthenticate3 请求，Client Credential 为 00 00 00 00 00 00 00 41，Negotiation options 设置为 0xffffffff，POC 中将其设置为 0x212fffff（ 将 Secure NRPC 位（Netlogon signing and sealing）设置为 0），但测试时将其设置为 0x612fffff 也是可以成功的，甚至，我直接将其设置为 0xffffffff。但无论如何，AES supported 位必须被设置，可参考 MS-NRPC 文档 3.1.4.2 节查看 NegotiateFlags 位。

3、NetrServerPasswordSet2 请求，Authenticator 中 Credential 设置为 00 00 00 00 00 00 00 41，timestamp 设置为 0。ClearNewPassword 设置为全 0。

4、最终，服务端设置成功，返回其 Authenticator。

参考链接

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1472
https://www.secura.com/pathtoimg.php?id=2055
https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-NRPC/%5BMS-NRPC%5D.pdf
https://mp.weixin.qq.com/s/wHoT-h468TXR48zzc79XgQ
https://nakedsecurity.sophos.com/2020/09/17/zerologon-hacking-windows-servers-with-a-bunch-of-zeros/
https://bbs.pediy.com/thread-262236.htm
https://github.com/mstxq17/cve-2020-1472

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课