跳转至

Windows DNS Server远程代码执行漏洞（CVE 2020 1350

0x00 漏洞背景

Windows DNS Server远程代码执行漏洞（CVE-2020-1350）：未经身份验证的攻击者可通过向目标DNS服务器发送特制数据包从而目标系统上以本地SYSTEM账户权限执行任意代码。该漏洞无需交互、不需要身份认证且Windows DNS Server默认配置可触发，攻击场景如下:

img

（注：图来自互联网）

利用场景1：

（1）受害者访问攻击者域名"evil.server.io"

（2）本地DNS服务器或域内的DNS服务器无法解析"evil.server.io"，向google DNS服务器（如8.8.8.8）查询

（3）查到后，发现该域名可以由攻击者DNS服务器解析，所以将该信息缓存到域服务器上

（4）第二次查询时，直接和攻击者DNS服务器进行查询

（5）此时攻击者服务器就可以构造响应包触发漏洞

在复现过程中，笔者省略了（1）、（2）、（3）步，直接在本地DNS服务器上将攻击者服务器地址设为转发器，在本地无法解析"evil.server.io"时，转而向攻击者DNS服务器进行查询。

0x01 漏洞分析

DNS包格式：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gpFNO5D3-1595035305870)(data:image/gif;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQImWNgYGBgAAAABQABh6FO1AAAAABJRU5ErkJggg==)]

UDP：表示DNS查询基于UDP协议传输数据。DNS服务器支持TCP和UDP两种协议的查询方式。

Destination port：目的端口默认是53。

QR：0表示查询报文；1表示回应报文。

TC：表示“可截断的”。如果使用UDP时，当应答报文超过512字节时，只返回前512个字节。通常情况下，DNS查询都是使用UDP查询，UDP提供无连接服务器，查询速度快，可降低服务器的负载。当客户端发送DNS请求，并且返回响应中TC位设置为1时，就意味着响应的长度超过512个字节，而仅返回前512个字节。这种情况下，客户端通常采用TCP重发原来的查询请求，并允许返回的响应报文超过512个字节。直白点说，就是UDP报文的最大长度为512字节，而TCP则允许报文长度超过512字节。当DNS查询超过512字节时，协议的TC标志位会置1，这时则使用TCP发送。

Queries：表示DNS请求的域名和类型。

漏洞点在于dns.exe!SigWireRead，该函数用于处理SIG类型的响应包，RR_AllocateEx 分配大小的参数由寄存器cx传入，只有16个bit，大小为0~65535，所以只要构造size 大于65535，造成溢出，就会分配一个比实际数据量小的堆块，造成堆溢出，将整数溢出转化成堆溢出漏洞。

img

伪代码如下：

img

RR_AlloccateEx用于分配堆块，第一个参数为分配的大小，由[Name_PacketNameToCountNameEx result] + [0x14] + [The Signature field’s length (rdi–rax)] 决定。

所以要触发漏洞，我们需要发送大于64KB的SIG类型响应包给受害者DNS服务器，但是基于UDP传输的DNS包限制大小为512个字节（支持EDNS0的限制大小为4096个字节），不足以触发漏洞。

PoC的思路是通过设置TC标志位，通知客户端采用TCP重发原来的查询请求，并允许返回的响应报文超过512个字节。如下：

img

但是利用TCP传输的DNS包限制大小为65535，还是不足以触发漏洞，这时候需要用到DNS域名压缩。

完整的域名表示，如www.google.com，需要16个字节：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
\3 w w w \6 g o o g l e \3 c o m \0

采用[ ]的形式存储。本例中将域名分成了三段，分别是www，google，com。每一段开头都有一个字节，表示后面域名的长度，最后以\0结尾。由于规定域名段的长度不能超过63个字节，所以表示域名段长度的字节最高两位没有用到，因此另有用途。

（1）当最高两位为00时，表示以上面的形式的传输

（2）当最高两位为11时，表示将域名进行压缩，该字节去掉最高两位后剩下的6位，以及后面的8位总共14位，指向DNS数据报文中的某一段域名，相当于一个指针。如0xc00c, 表示从DNS正文（UDP payload）的偏移offset=0x0c处所表示的域名。

（3）混合表示：以www.google.com为例，假设该域名位于DNS报文偏移0x20处，可能的用法有：

a、0xc020：表示完整域名www.google.com

b、0xc024：从完整域名的第二段开始，指代google.com

c、0x016dc024：0x01表示后面跟的size大小1，0x6d表示字符m，所以0x016d表示字符串"m"，第二段0xc024指代google.com，因此整段表示m.google.com

Name_PacketNameToCountNameEx函数会根据Signers Name 来获取域名的大小。因此0xc00c（偏移从Transaction ID 0x795a开始计算）指向正常域名9.ibrokethe.net，大小则为0x11。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-z2rI7Hdk-1595035305879)(data:image/gif;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQImWNgYGBgAAAABQABh6FO1AAAAABJRU5ErkJggg==)]

但通过设置Signer’s Name为0xc00d，将域名起始位置指向"9"，此时会将"9"当作，将后面的0x39个字节当作域名段，并且一直解析下去，直至解析到’\0’。如下图，Name_PacketNameToCountNameEx会将图中选中的部分当成域名，获取大小。此时大小为(0x39+1)+(0xf+1)*5 +1 =0x8b。（0x39和0xf表示域名段大小，+1表示"."， 最后一个+1表示"\0"）。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-20X5AEwn-1595035305880)(data:image/gif;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQImWNgYGBgAAAABQABh6FO1AAAAABJRU5ErkJggg==)]

windbg调试结果：

img

[rsp+0x30h]为传入Name_PacketNameToCountNameEx的第一个参数，保存获取域名的大小。而后面的(rdi–rax)表示我们填充到Signature的数据大小，rdi为数据结束地址，rax为起始地址（从Signer’s Name后开始计算）。

img

计算完大小为0xffaa：

img

所以最后传入RR_AllocateEx函数的大小为 (0x8b+0x14+0xffaa)&0xffff= 0x49

img

之后将Signature的数据复制到分配的空间：

img

dns!memcpy 目标地址Dst为RR_AllocateEx分配地址+域名大小（0x8b）+0x4c处，源地址Src为Signature数据起始地址，Size为Signature数据大小（0xffaa）。最终造成溢出，产生崩溃。

img

PoC建立TCP连接后，发送的包构造如下：

 # SIG Contents
sig = "\x00\x01" # Type covered
sig += "\x05" # Algorithm - RSA/SHA1
sig += "\x00" # Labels
sig += "\x00\x00\x00\x20" # TTL
sig += "\x68\x76\xa2\x1f" # Signature Expiration
sig += "\x5d\x2c\xca\x1f" # Signature Inception
sig += "\x9e\x04" # Key Tag
sig += "\xc0\x0d" # Signers Name - Points to the '9' in 9.domain.
sig += ("\x00"*(19 - len(domain)) + ("\x0f" + "\xff"*15)*5).ljust(65465 - len(domain_compressed), "\x00") # Signature - Here be overflows!
        ……
# Msg Size + Transaction ID + DNS Headers + Answer Headers + Answer (Signature)
connection.sendall(struct.pack('>H', len_msg) + data[2:4] + response + hdr + sig)
12345678910111213

上述构造的信息抓包内容如下：

img

整个交互过程如下（受害者DNS服务器抓包结果）：

img

img

192.168.148.134为受害者IP，192.168.148.138为攻击者IP。

（1）受害者向攻击者查询 9.ibrokethe.net

（2）攻击者返回一个响应包，设置TC位，通知客户端采用TCP重发原来的查询请求，并允许返回的响应报文超过512个字节

（3）受害者就和攻击者建立TCP连接

（4）受害者重新向攻击者查询 9.ibrokethe.net

（5）攻击者利用TCP传输大于64KB的响应包给受害者，触发漏洞，造成溢出

最后更新: 2023-10-12