2021 年 3 月，微软于补丁日发布了关于 Windows DNS Server 的五个远程代码执行漏洞和两个拒绝服务漏洞，漏洞编号如下：

RCE漏洞
CVE-2021-26877，CVE-2021-26897（Exploitation More Likely）
CVE-2021-26893，CVE-2021-26894，CVE-2021-26895（Exploitation Less Likely）

DoS漏洞
CVE-2021-26896，CVE-2021-27063（Exploitation Less Likely）

Windows DNS Server 存在多个远程代码执行漏洞和拒绝服务漏洞，攻击者可通过向目标主机发送特制请求来利用这些漏洞，成功利用这些漏洞可在目标主机上以 SYSTEM 权限执行任意代码或导致 DNS 服务拒绝服务。启用安全动态更新可暂时缓解这些漏洞，但攻击者依然可以通过加入域的计算机攻击启用了安全区域更新的 DNS 服务器。

从通告的 FAQ 说明上看，这些漏洞都存在于 Windows DNS Server 进行动态区域更新的过程中。DNS 更新功能使 DNS 客户端计算机能够在发生更改时向 DNS 服务器注册并动态更新其资源记录（RR）。 使用此功能可以缩短手动管理区域记录所需的时间，从而改进 DNS 管理。动态区域更新功能可以部署在独立的 DNS 服务器或 Active Directory（AD）集成的 DNS 服务器上。最佳实践是部署与 AD 集成的DNS，以便利用 Microsoft 的安全性，如 Kerberos 和 GSS-TSIG。

动态更新类型：

在DNS服务器上创建区域时，可以选择启用或禁用 DNS 动态区域更新：

以下为 McAfee 关于 Windows DNS Server 部署模型制作的威胁分析表格：

参考链接：https://www.mcafee.com/blogs/other-blogs/mcafee-labs/seven-windows-wonders-critical-vulnerabilities-in-dns-dynamic-updates/

根据 McAfee 博客中的信息可知，此漏洞在更新 TXT 记录时产生，TXT 记录中的 TXT Length 被设置为 0xFF，这个值大于资源记录里指定的 Data Length (0xbd)，这个长度表示的是这个记录后面的所有数据的长度，在当前场景下，包括所有的 TXT Length 和 TXT 数据的长度。使用 Scapy 构造数据包及抓包数据如下：

配置 DNS 服务器，新增一个名为 MAL 的主要区域，并设置允许动态更新。(启用页堆) 以下为漏洞触发场景，问题出现在 dns!File_PlaceStringInFileBuffer 函数中，程序尝试访问超出边界的数据：

漏洞分析
在 CopyWireRead 函数中，通过 RR_AllocateEx 函数申请长度为 data length 的空间，而在后续的操作中实际上会分配 data length + 0x38 + 0x10 大小的空间。0x10 为自定义头部的大小、0x38 为 RR 头部的大小。result 指向 RR 头部，然后调用 memcpy 函数向缓冲区复制 data length 长度的数据。如果 data 数据长度大于 data length 长度也可以被处理，只是复制到缓存中会被截断。

接下来在 TxtFileWrite 函数中会调用 File_PlaceStringInFileBuffer 函数，分别传入待写入缓冲区地址、待写入缓冲区结尾地址、1、TXT 记录缓存地址以及分组长度（TXT Length，每组长度不超过 0xFF）。这个长度就是从 data 字段中取出的，在调用 File_PlaceStringInFileBuffer 函数前没有判断这个长度是否超出了 TXT 缓存数据的界限（在这个函数内部也没有判断）。虽然在后面会有判断（粉框内），但在第一次执行 File_PlaceStringInFileBuffer 函数的过程中就有可能会触发漏洞。

在 File_PlaceStringInFileBuffer 函数中存在以下循环，使用传入的 length 控制循环的次数，这会导致访问超出边界的数据。

补丁分析
以下为补丁后的 TxtFileWrite 函数，在调用 File_PlaceStringInFileBuffer 函数前，会判断通过 TXT Length 寻址后的地址是否超出了申请的空间。

根据已有信息，可构造以下数据包。更新类型为 SIG，记录超长（signature 字段超长）。注意这次需使用 TCP 连接，Scapy 不能直接构造，以下仅为模型：

以下为抓包数据：

漏洞触发现场以及函数调用堆栈如下，异常的原因是 0x2713533c000 无法访问。漏洞触发是在 Dns_SecurityKeyToBase64String 函数（用于 Base64 编码）中。

查看出现问题的缓冲区，可以发现，其首地址为 0x271352bbff0 ，UserSize 为 0x80010，是在 File_WriteZoneToFile 函数中调用 Mem_Alloc 分配的。

File_WriteZoneToFile 函数中调用 Mem_Alloc 申请大小为 0x80000 长度的空间，实际是通过 allocMemory 函数申请大小为 0x80010 长度的堆（包括 0x10 大小的头部长度）。而触发访问异常的 0x2713533c000 正好和 0x271352bbff0 相差 0x80010。下一步要查看为何会有超出边界的数据复制过来。

漏洞分析
通过回溯及数据跟踪可关注到 zoneTraverseAndWriteToFile 函数，其第一个参数偏移 0x20 处保存了待写缓冲区的实时地址。该函数会调用 writeZoneRoot、writeNodeRecordsToFile 等函数向缓冲区写入数据。然后利用 NTree_FirstChild 以及 NTree_NextSiblingWithLocking 函数遍历 NodeRecords，然后通过回调依次对这些节点进行处理。如果该节点偏移 0x5c 处没有设置 0x10 的 flag，就会调用 writeNodeRecordsToFile 函数进行处理。

writeNodeRecordsToFile 函数中会调用 RR_WriteToFile 函数，在 RR_WriteToFile 函数中也会有判断，如果当前缓冲区距离 end_addr 的长度小于 0x11000，就将缓冲区数据写入文件，并重置缓冲区指针。但这里没有考虑 Base64 编码后是 3:4 的长度。

然后通过 type 类型从 RawRecordFileWrite 表中选择相应的 FileWrite 处理函数，type 18 对应的是 SigFileWrite 函数，然后调用这个函数。（IDA 下面解析错了，实际上 SigFileWrite 函数有 4 个参数）

SigFileWrite 函数用于解析 SIG 结构并将其写入 MAL.dns 缓存，如下所示，SigFileWrite 函数拿到的初始缓存缓冲区指针为 p_buffer(来自第二个参数)，在向其写入 SIG 头信息以及 Signer's name 后，v13 指向该缓冲区待写入的地址，然后调用 Dns_SecurityKeyToBase64String 函数对 Signature 进行 Base64 编码并将结果写入 v13 指向的地址处。

如下所示，在调用 Dns_SecurityKeyToBase64String 函数时，第二个参数为 0xffb9，经过 Base64 编码后的数据长度为 0x154f8。查看上下文可以发现（上图所示），在向缓冲区写入的每一步几乎都用了 end_addr(用户可用的最大长度) 作为限制，唯独在 Dns_SecurityKeyToBase64String 函数的调用中没有，这可能会造成隐患。

由于向 zoneTraverseAndWriteToFile 函数中传入的第一个参数是不变的，因而会一直向该缓冲区中写入数据。虽然在 RR_WriteToFile 函数和 SigFileWrite 函数中有一些判断，但仍未考虑数据 Base64 编码后的长度，因而在多次循环写入的时候，正好在 Dns_SecurityKeyToBase64String 函数的执行过程中触发 OOB 写操作。

补丁分析
更新后的 DNS 在 SigFileWrite 函数中调用 Dns_SecurityKeyToBase64String 函数前会进行以下判断。会考虑当前缓冲区的剩余空间是否可以容纳 Base64 编码后的 Signature 数据。

以下为 3 月更新内发生变动的函数列表，包括前面已经分析过的TxtFileWrite 函数和 SigFileWrite 函数。

类似地，在 KeyFileWrite 函数中也加入了 Base64 编码预检查（粉框对应）。但不是这个的问题，补丁前已经有 a3 - (signed __int64)a2 < (signed int)(2 * v3) 这个判断了，可以阻断 CVE-2021-26897 式触发。真正的原因我用蓝框圈起来了，v3 来自 Data Length - 4，而且它是无符号 int 型，如果 Data Length 小于 4，会产生整数溢出。而它又作为 Dns_SecurityKeyToBase64String 函数的第二个参数，该函数指明待编码数据长度，4 个字节的大整数，肯定会溢出的啦。

构造 POC 如下，触发场景见下图：

另外，值得注意的是，CopyWireRead 函数中加入了以下判断，经过分析可知，当接收 update 请求类型为 WKS、AAAA 或 ATMA 时，会分别判断其 Data Length 是否小于 5、0x10、2。

该请求会由 AaaaFileWrite 函数进行处理，经过前面的分析可知，a1 偏移 0x38 处指向 Data Length 字段后的记录数据。经过 CopyWireRead 函数的处理，a1 偏移 0x38 处指向的数据的有效长度等于 Data Length 大小。如果 Data Length 小于 XXXFileWrite 函数中函数调用所需的数据长度，就有可能访问到缓冲区边界之外的数据（如 RtlIpv6AddressToStringA 函数）。

以下为 RtlIpv6AddressToStringA 函数原型，其第一个参数类型为 in6_addr，该长度应为 16 个字节。因而在新的 CopyWireRead 函数中会判断 Data Length 大小是否小于 0x10。

新的 AaaaFileWrite 函数中也会加入对待读缓冲区和待写缓冲区的判断。

构造如下 POC 进行验证，崩溃场景如下图：

下面再来看 AtmaFileWrite 函数，CopyWireRead 函数中给的限制是：它的 Data Length 长度要大于等于 2。对比补丁前后，对 Data Length 长度判断吸引了我的注意（右边），如果是 0，就走结束流程。那么再看不补丁前的函数，v6 为 Data Length - 1 的无符号数，当 Data Length 为 0 时，v6 为 0xFFFFFFFF , 会产生整数溢出。而且，当 Data 数据的第一个字节为 1 时，会以 v6 做为控制长度向缓冲区复制数据（堆溢出）。

构造 ATMA 更新请求如下，为了使 Data Length 为 0 时，满足漏洞触发条件，需要在发送恶意请求时发送一些“铺垫”数据，即保证 Data 数据的第一个字节（a1 偏移 0x38 处）为 1，且分配的大小一致。那么当触发漏洞的请求到来时，申请的堆可能就来自之前的数据包。例：rdl 先 1（多个） 后 0（分配到 0x50 大小的自定义堆上），崩溃现场如下图：

WksFileWrite 函数中会打印 IP 地址，还有协议名称，这需要保证数据必须大于等于5。如果发送的数据不到 5，就会读取到后面的数据，这样会存在一定程度的信息泄露（然而我觉得没什么用）。

微软 3 月补丁日公开了 Windows DNS Server 中存在的多个远程代码执行漏洞和拒绝服务漏洞，这些漏洞都存在于 Windows DNS Server 进行动态区域更新的过程中。攻击者可通过向目标主机发送特制请求来利用这些漏洞，成功利用这些漏洞可在目标主机上以 SYSTEM 权限执行任意代码或导致 DNS 服务拒绝服务。通过对 McAfee 博客中的细节描述进行分析以及补丁比对，笔者构造 POC 复现了其中的 5 个（不包括 WKS）。如有不足之处，欢迎批评指正，期待技术交流。

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/seven-windows-wonders-critical-vulnerabilities-in-dns-dynamic-updates/

https://docs.microsoft.com/zh-cn/troubleshoot/windows-server/networking/configure-dns-dynamic-updates-windows-server-2003

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26877

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26897

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！