DNS Server远程代码执行漏洞分析-SIGRed（CVE-2020-1350）( 二 )

3.受害DNS目前不知道该查询的答复，将查询转发到其上层的DNS服务器（8.8.8.8）。

4.权威服务器（8.8.8.8）知道答复，并响应的NameServer deadbeef.fun为ns1.41414141.club 。

5.受害Windows DNS服务器处理并缓存此响应。

6.下次我们查询域名deadbeef.fun ，目标Windows DNS服务器也会查询ns1.41414141.club并响应，因为它是该域的NameServer 。

DNS Server远程代码执行漏洞分析-SIGRed（CVE-2020-1350）

本文插图
漏洞– CVE-2020-1350
函数：dns.exe!SigWireRead漏洞类型：整数溢出导致基于堆的缓冲区溢出
dns.exe 为每种受支持的响应类型实现解析功能。

本文插图
Wire_CreateRecordFromWire:RRWireReadTable被传递给RR_DispatchFunctionForType函数处理

本文插图
RRWireReadTable支持响应的类型
支持的响应类型之一用于SIG查询。根据Wikipedia:”SIG查询是在SIG(0) (RFC 2931)和TKEY (RFC 2930)中使用的签名记录,RFC 3755指定RRSIG作为在DNSSEC内使用的SIG的替代品。 ”
让我们来看一下由Cutter生成的反汇编:dns.exe!SigWireRead SIG响应类型的处理函数：

本文插图
RR_AllocateEx通过以下公式计算传递给第一个参数：
[Name_PacketNameToCountNameEx result] + [0x14] + [The Signature field’s length (rdi–rax)]签名字段的大小可能会有所不同，因为它是SIG响应的主要payload 。

本文插图
R根据RFC 2535的SIG资源记录的结构
正如你在下面的图片中看到， RR_AllocateEx希望其参数在16位寄存器中传递，因为它只使用rdx的dx部分和rcx的cx部分。
这意味着，如果我们可以使上述公式输出的结果大于65,535字节(16位整数的最大值) ，则会出现整数溢出，从而导致分配比预期的小得多，这可能会导致基于堆的缓冲区溢出。

本文插图
比较方便的是，这个分配的内存地址作为memcpy的目标缓冲区传递，从而导致基于堆的缓冲区溢出。

本文插图
从中分配的缓冲区RR_AllocateEx被传递到中memcpy
总而言之，通过发送一个包含较大(大于64KB) SIG记录的DNS响应，我们可能会导致一个基于堆的缓冲区溢出，溢出大约64KB 。
触发漏洞
现在我们能够让受害者DNS服务器查询我们的DNS服务器，我们已经有效地将其转换为客户端。我们可以让受害者DNS服务器询问我们的恶意DNS服务器特定类型的查询，并分别用匹配的恶意响应请求。
我们认为触发此漏洞所需要做的只是使受害DNS服务器向我们查询SIG记录，然后用一个很长的签名(length >= 64KB)回复它一个SIG响应。我们失望地发现DNS超过UDP的大小限制为512字节(如果服务器支持EDNS0 ，则为4,096字节) 。无论如何，这都不足以触发漏洞。
但是，如果有合理的理由让服务器发送一个大于4,096字节的响应，会发生什么呢?例如，一个很长的TXT响应或可以解析为多个IP地址的主机名。
DNS截断-但等一下，还有更多!