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。

动态更新类型：

• 安全动态区域更新：验证所有 RR 更新均已使用加入域的计算机上的 GSS-TSIG 进行了数字签名。此外，可以对哪些主体可以执行动态区域更新应用更精细的控件。
• 不安全的动态区域：任何计算机无需任何身份验证即可更新 RR（不建议）。

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

• 将 DNS 部署为独立服务器时，默认情况下将禁用“动态区域更新”功能，但可以在安全/非安全模式下启用该功能。
• 将 DNS 部署为 AD 集成时，默认在安全模式下启用“动态区域更新”。

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

• 部署在公网启用动态更新的 Windows DNS Server 风险最高（这种配置是极其不推荐的，应该很少有这种配置）
• 部署 AD 集成的 Windows DNS Server 默认在安全模式下启用“动态区域更新”，可减轻未经身份验证的攻击者的风险，但仍具有受威胁的域计算机或受信任内部人员实现 RCE 的风险

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

CVE-2021-26877 漏洞复现分析

• 使用 TXT length 大于 Data length 的 TXT 资源记录进行区域的动态更新时可触发此漏洞

根据 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 寻址后的地址是否超出了申请的空间。

CVE-2021-26897 漏洞复现分析

• 发送许多连续的 SIG 资源记录动态更新可触发此漏洞
• 将许多连续的 SIG 资源记录动态更新进行组合并将字符串进行 Base64 编码时在堆上引发 OOB 写操作

根据已有信息，可构造以下数据包。更新类型为 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 函数。

• KEY 记录问题

类似地，在 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。

• AAAA 记录问题

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

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

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

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

• ATMA 记录问题

下面再来看 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 大小的自定义堆上），崩溃现场如下图：

• WKS 记录问题

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

[培训]《安卓高级研修班(网课)》月薪三万计划，掌握调试、分析还原ollvm、vmp的方法，定制art虚拟机自动化脱壳的方法