江苏龙网

  1. 首页 > 人文 > >

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


根据DNS RFC 5966：“在没有EDNS0（DNS 0扩展机制）的情况下 ， 任何需要发送超过512字节限制的UDP响应的DNS服务器的正常行为是截断响应 ， 使其符合该限制 ， 然后在响应头中设置TC标志 。 当客户端收到这样的响应时 ， 它将TC标志作为一个指示 ， 指示它应该通过TCP重试 。 ”
因此 ， 我们可以在响应中设置TC（truncation) 标志 ， 这将导致目标Windows DNS服务器启动与恶意NameServer新的TCP连接 ， 并且我们可以传递大于4,096字节的消息 。 但是要大多少？
根据DNS RFC 7766：“DNS客户端和服务器应同时2个八位字节长度字段和该长度字段描述的消息传递到TCP层” ， (例如 ， 在单个的“write”系统调用中) ， 以使所有数据更有可能在单个TCP段中传输 。
由于邮件的前两个字节表示其长度 ， 因此TCP上DNS中邮件的最大大小表示为16位 ， 因此限制为64KB 。
DNS Server远程代码执行漏洞分析-SIGRed（CVE-2020-1350）
本文插图
但是 ， 即使长度为65,535的消息也不足以触发漏洞 ， 因为消息长度包括标头和原始查询 。 在计算传递给RR_AllocateEx的大小时 ， 没有考虑这个开销 。
DNS指针压缩–少即是多
让我们再来看一个合法的DNS响应（为方便起见 ， 我们选择了A类型的响应） 。
DNS Server远程代码执行漏洞分析-SIGRed（CVE-2020-1350）
本文插图
dig research.checkpoint.com A @8.8.8.8的DNS响应 ， 如Wireshark所示
您可以看到Wireshark对research.checkpoint.com的答复名称字段中的0xc00c字节进行了计算 。 问题是 ， 为什么?
为了尽可能多的将信息压缩到512字节中 ， 可以（通常必须）压缩DNS名称……在这种情况下 ， 答复的DNS名称编码为0xc0 0x0c 。 c0部分设置了两个最高有效位 ， 表示下面的6+8位是指向消息前面某个地方的指针 。 在本例中 ， 这指向数据包内的位置12（=0x0c）它紧跟在DNS header之后 。
与数据包开头的偏移量0x0c（12）是什么？是research.checkpoint.com啊！
在这种压缩形式中 ， 指针指向编码字符串的开头 。 在DNS中 ， 字符串被编码为（<size> <value>）链 。
DNS Server远程代码执行漏洞分析-SIGRed（CVE-2020-1350）
本文插图
因此 ， 我们可以使用“magic”字节0xc0从数据包中引用字符串 。 让我们再次检查计算传递给RR_AllocateEx的大小的公式:
[Name_PacketNameToCountNameEx result] + [0x14] + [The Signature field’s length (rdi–rax)]逆向Name_PacketNameToCountNameEx确认我们上面描述的行为 。 Name_PacketNameToCountNameEx的目的是计算名称字段的大小 ， 并将指针压缩考虑在内 。 当仅用两个字节表示分配时 ， 拥有一个允许我们大量增加分配大小的原语正是我们所需要的 。
因此 ， 我们可以在SIG签名者的名称字段中使用指针压缩 。 但是 ， 仅指定0xc00c为签名者的名称不会引起溢出 ， 因为查询的域名已经存在查询中 ， 并且从分配的值中减去开销大小 。 但是0xc00d呢？我们唯一需要满足的约束是编码字符串是有效的（以结尾0x0000） ， 并且我们可以轻松做到这一点 ， 因为我们有一个没有任何字符约束的字段-签名值（signature value） 。 对于域名41414141.fun ， 0xc00d指向域名的第一个字符（“4”） 。 然后将此字符的序号值用作未压缩字符串的大小（“4”表示值0x34（52）） 。 该未压缩字符串的大小加上我们可以在Signature字段中容纳的最大数据量（最多65,535 ， 具体取决于原始查询）的汇总将造成大于65,535字节的值 ， 从而导致溢出！
让我们用WinDBG附加到dns.exe:
DNS Server远程代码执行漏洞分析-SIGRed（CVE-2020-1350）


推荐阅读


上一篇：北方邦|被恶霸欺凌后投诉无门，印度母女走投无路在政府大楼前双双自焚

下一篇：国际丨美国得州一监狱暴发大规模疫情 超千人感染