DNSpooq系列误差剖析与复现

宣布时间 2021-02-01

前言


近期，，，，，，以色列清静咨询企业JSOF在最新报告中披露了七个 DNSmasq 误差（统称 DNSpooq），，，，，，并指出攻击者借此熏染了数以百万计的装备。 。。。。。。。DNSmasq 是一套盛行的开源 DNS 转发软件，，，，，，能够为运行该软件的网络装备添加 DNS 缓存和 DHCP 效劳器功效，，，，，，普遍用于种种小型局域网络。 。。。。。。。受 DNSpooq 影响的装备不但可能遭遇 DNS 缓存中毒，，，，，，还可被用于远程代码执行、拒绝效劳（DoS）攻击。 。。。。。。。现在受影响的厂商包括但不限于 Android / Google、康卡斯特、思科、红帽、Netgear、高通、Linksys、IBM、D-Link以及 Ubiquiti 。 。。。。。。。凭证shodan显示，，，，，，有超100万台应用DNSmasq的装备袒露在公网，，，，，，可能受影响的装备数不胜数。 。。。。。。。


其中，，，，，， CVE-2020-25684、CVE-2020-25685 和 CVE-2020-25686 这三个误差，，，，，，可能导致 DNS 效劳遭遇缓存中毒攻击。 。。。。。。。另外四个误差为 CVE-2020-25687、CVE-2020-25683、CVE-2020-25682 和 CVE-2020-25681 ，，，，，，均为缓冲区溢出误差。 。。。。。。。黑客或可在设置了 DNSmasq 的网络装备上，，，，，，使用这些误差远程执行恣意代码。 。。。。。。。


DNS协议简介


DNS的请求和响应的基本单位是DNS报文（Message）。 。。。。。。。请求和响应的DNS报文结构是完全相同的，，，，，，每个报文都由以下五段（Section）组成：


1.png


DNS Header是每个DNS报文都必需拥有的一部分，，，，，，它的长度牢靠为12个字节。 。。。。。。。Question部分存放的是向效劳器盘问的域名数据，，，，，，一样平常情形下它只有一条Entry。 。。。。。。。每个Entry的名堂是相同的，，，，，，如下所示：


2.png


QNAME：由labels序列组成的域名。 。。。。。。。QNAME的名堂使用DNS标准名称体现法。 。。。。。。。这个字段是变长的，，，，，，因此有可能泛起奇数个字节，，，，，，但不举行补齐。 。。。。。。。DNS使用一种标准名堂对域名举行编码。 。。。。。。。它由一系列的label（和域名中用.支解的label差别）组成。 。。。。。。。每个label首字节的高两位用于体现label的类型。 。。。。。。。RFC1035中分派了四个内里的两个，，，，，，划分是：00体现的通俗label，，，，，，11（0xC0）体现的压缩label。 。。。。。。。


Answer，，，，，，Authority和Additional三个段的名堂是完全相同的，，，，，，都是由零至多条Resource Record（资源纪录）组成。 。。。。。。。这些资源纪录由于差别的用途而被脱离存放。 。。。。。。。Answer对应盘问请求中的Question，，，，，，Question中的请求盘问效果会在Answer中给出，，，，，，若是一个响应报文的Answer为空，，，，，，说明这次盘问没有直接获得效果。 。。。。。。。


RR(ResourceRecord)资源纪录是DNS系统中很是主要的一部分，，，，，，它拥有一个变长的结构，，，，，，详细名堂如下：


3.png


● NAME：它指定该条纪录对应的是哪个域名，，，，，，名堂使用DNS标准名称体现法

● TYPE：资源纪录的类型。 。。。。。。。

● CLASS：对应Question的QCLASS，，，，，，指定请求的类型，，，，，，常用值为IN，，，，，，值为0x001。 。。。。。。。

● TTL(Time To Live)资源的有用期：体现你可以将该条RR缓存TLL秒，，，，，，TTL为0体现该RR不可被缓存。 。。。。。。。TTL是一个4字节有符号数，，，，，，可是只使用它大于即是0的部分。 。。。。。。。

● RDLENGTH：一个两字节非负整数，，，，，，用于指定RDATA部分的长度（字节数）。 。。。。。。。

● RDATA：体现一个长度和结构都可变的字段，，，，，，它的详细结构取决于TYPE字段指定的资源类型。 。。。。。。。

   DNS常见资源纪录类型有NS纪录、A纪录、CNAME纪录。 。。。。。。。

● NS纪录

NS纪任命于指定某个域的权威DNS。 。。。。。。。好比在com的DNS里，，，，，，纪录着http://www.hfgufa.com这个域的DNS，，，，，，或许如下：

www.hfgufa.com.  NS ns1.www.hfgufa.com. 

www.hfgufa.com.  NS ns2.www.hfgufa.com. 

www.hfgufa.com.  NS ns3.www.hfgufa.com.


这三条纪录，，，，，，就是说http://ns1.www.hfgufa.com、http://ns2.www.hfgufa.com、http://ns3.www.hfgufa.com（以下简称ns1、ns2、ns3）都是http://www.hfgufa.com域的权威DNS，，，，，，询问恣意其中一个都可以。 。。。。。。。


虽然，，，，，，在com的权威DNS里，，，，，，还会纪录ns1~ns3这几个http://www.hfgufa.com权威DNS的IP，，，，，，会一并返回给问询者，，，，，，以便问询者直接用IP联系ns1~ns3。 。。。。。。。


● A纪录


A纪录就是最经典的域名和IP的对应，，，，，，在http://ns1.www.hfgufa.com内里，，，，，，纪录着百度公司各产品的域名和IP的对应关系，，，，，，每一个这样的纪录，，，，，，就是一个A纪录，，，，，，好比下面的3个A纪录：


image.www.hfgufa.com   A    1.2.3.4 

wenku.www.hfgufa.com   A    5.6.7.8 

tieba.www.hfgufa.com     A    9.10.11.12


若是用户询问http://ns1.www.hfgufa.com：“http://wenku.www.hfgufa.com的IP是几多？？？？”，，，，，，ns1就会找到对应的A纪录或者CNAME纪录并返回。 。。。。。。。


● CNAME纪录


CNAME纪录也称又名纪录，，，，，，允许将多个纪录映射到统一台盘算机上。 。。。。。。。好比，，，，，，在ns1中，，，，，，并没有http://www.www.hfgufa.com的A纪录，，，，，，而是一个CNAME纪录：


www.www.hfgufa.com  CNAME  www.a.shifen.com


也就是告诉用户，，，，，，http://www.www.hfgufa.com的又名是http://www.a.shifen.com，，，，，，可以直接请求剖析http://www.a.shifen.com。 。。。。。。。


DNS缓存攻击


当会见www.www.hfgufa.com时，，，，，，域名剖析的大致流程如下图所示。 。。。。。。。


4.png


DNS缓存中毒是一种较量经典的攻击方法，，，，，，若是攻击者可以乐成执行，，，，，，就会在DNS缓存效劳器上留下一个有害的条目，，，，，，使得用户会见正常网站的请求重定向到被攻击者控制的恶意网站。 。。。。。。。


DNSpooq系列缓存中毒误差的简朴攻击流程图如下图所示：


5.png


（1）用户发送浏览淘宝的请求给DNS转发器，，，，，，希望获得对应的IP。 。。。。。。。

（2）DNS转发器没有此域名的缓存，，，，，，以是将请求转发给上游DNS效劳器。 。。。。。。。

（3）在获得上游DNS效劳器回复前，，，，，，攻击者发送一个伪造的回复，，，，，，将淘宝域名与一个恶意IP相对应。 。。。。。。。

（4）DNS转发器接受了这个伪造的回复，，，，，，并发送给用户，，，，，，于是用户请求会见的淘宝被重定向到了攻击者使用的恶意网站。 。。。。。。。


这个DNS转发器应用场景很普遍，，，，，，好比小我私家开的热门，，，，，，机场、宾馆里的公共网络等，，，，，，一旦攻击乐成，，，，，，则影响使用这些网络的所有人。 。。。。。。。


在DNS Header中有一个16-bit的区域叫TXID（transaction ID），，，，，，用于将盘问包和回复包匹配。 。。。。。。。在已往，，，，，，TXID是防御DNS缓存中毒的主要手段。 。。。。。。。可是在2008年，，，，，，清静研究员Dan Kaminsky证实16-bit的TXID是远远不敷的，，，，，，厥后又增添了端口随机化，，，，，，以是这个时间想伪造回复包，，，，，，不但需要猜对TXID，，，，，，还需要猜对端口，，，，，，一共32位的随机值，，，，，，别的还需要知道源IP和目的IP。 。。。。。。。


DNS清静扩展


到了21世纪，，，，，，DNS清静扩展正在被逐步应用。 。。。。。。。DNS清静扩展是现在为相识决DNS诱骗缓和存污染问题而设计的一种清静机制。 。。。。。。。DNSSEC依赖数字署名来包管DNS应答报文的真实性和完整性。 。。。。。。。简朴来说，，，，，，权威效劳器使用私钥对资源纪录举行署名，，，，，，递归效劳器使用权威效劳器的公钥对应答报文举行验证。 。。。。。。。若是验证失败，，，，，，则说明这一报文可能是有问题的。 。。。。。。。


为了实现资源纪录的署名和验证，，，，，，DNSSEC增添了四种类型的资源纪录：RRSIG（Resource Record Signature）、DNSKEY（DNS Public Key）、DS（Delegation Signer）、NSEC（Next Secure）。 。。。。。。。


例如我们执行下令行：dig @8.8.8.8 paypal.com，，，，，，获得的DNS盘问效果如下所示：


6.png


红框中为应答部分，，，，，，这是未开启DNSSEC的情形下的。 。。。。。。。我们执行下令行：dig+dnssec @8.8.8.8 paypal.com，，，，，，获得的DNS盘问效果如下所示：


7.png


蓝框中即是RRSIG资源纪录存储，，，，，，该资源纪录存储的是对资源纪录荟萃（RRSets）的数字署名。 。。。。。。。


Dnsmasq缓存中毒误差


以下三个误差，，，，，，组合起来用可以降低伪造回复包的熵值。 。。。。。。。


● CVE-2020-25684


DNSmasq自己限制了转发给上游效劳器盘问包的数目，，，，，，通常最大是150条。 。。。。。。。用户可以自己设定这个值。 。。。。。。。转发盘问使用的是frec(forwardrecord)结构。 。。。。。。。每个frec都和TXID相关联。 。。。。。。。当回复被接受或经由一准时间，，，，，，这个frecs就会被删除。 。。。。。。。


通常情形下，，，，，，用于转发盘问的socket数目被限制在64个。 。。。。。。。每个用于转发的socket和一个随机的端口绑定。 。。。。。。。

理论上，，，，，，盘问包中TXID和源端口加起来会有32-bit的熵。 。。。。。。。可是现实上，，，，，，这个熵要更少一些。 。。。。。。。由于dnsmasq在统一个端口会多路复用多个TXID，，，，，，而没有将每个TXID和每个端口设置为逐一对应的关系，，，，，，如下图所示。 。。。。。。。效果就是，，，，，，攻击者只需要料中64个端口中的一个端口尚有准确的TXID就可以了，，，，，，而不必料中某个特定的端口和特定的TXID。 。。。。。。。以是这导致现实上只有26位熵值。 。。。。。。。


8.png


● CVE-2020-25685


若是要对DNS转发器举行投毒，，，，，，除了需要猜对准确的TXID和源端口，，，，，，攻击者发送伪造的回复还需要匹配已开放的frecs。 。。。。。。。若是想让frec匹配，，，，，，那么TXID和问题区都要匹配，，，，，，换句话说，，，，，，回复的内容是之前询问过的。 。。。。。。。


dnsmasq只存放问题区的哈希值，，，，，，而不是把整个语句存下来。 。。。。。。。当整个盘问提交的时间，，，，，，这个哈希值会被生涯。 。。。。。。。


若是dnsmasq没有编译DNSSEC支持，，，，，，那么他默认使用CRC32作为哈希算法。 。。。。。。。问题就在于CRC32从密码学角度并不是一个清静的算法。 。。。。。。�？？？？梢院芮崴傻氖褂美嗨芐MT solver等工具举行CRC32碰撞，，，，，，这里原理不做过多先容。 。。。。。。。


以是基于这一特征，，，，，，攻击者可以天生多个盘问，，，，，，每一个盘问的CRC32的值都相同，，，，，，不过盘问的是差别的域名，，，，，，而这些域名最好是不保存的，，，，，，即没有被缓存的。 。。。。。。。然后攻击者可以发送一个具有相同CRC32值的伪造的回复。 。。。。。。。


如下图所示，，，，，，攻击者控制一台客户端对多个域名提倡问询，，，，，，每一个CRC32的值都是相同的，，，，，，然后在递归DNS效劳器回复之前，，，，，，回复一个具有相同CRC32值的域名或IP，，，，，，攻击即有可能乐成。 。。。。。。。


9.png


● CVE-2020-25686


dnsmasq的另一个问题就是在统一个域名被盘问请求时会粗暴的建设多个frecs。 。。。。。。。随后会转发所有的请求，，，，，，若是乐成的匹配其中的恣意一个，，，，，，就计入缓存。 。。。。。。。这个问题导致就算dnsmasq使用清静的哈希算法，，，，，，也可能乐成的实验攻击。 。。。。。。。


通过以上三个误差，，，，，，导致攻击者伪造恶意回复包的乐成率大大提高，，，，，，后面还需要使用dnsmasq没有对回复包做验证的特征举行攻击。 。。。。。。。


一样平常情形下，，，，，，在递归效劳器上会对回复包做一些验证机制，，，，，，例如bailiwicks。 。。。。。。。可是在设置dnsmasq的装备上并没有做任何验证，，，，，，以是可以在用户请求www.example.com的时间，，，，，，攻击者可以发送如下回复:


www.example.com  CNAME  www.bank.com

www.bank.com           A         6.6.6.6


然后这条纪录的缓存就会被插入到dnsmasq的装备中。 。。。。。。。前文先容过CNAME，，，，，，以是当用户想会见www.bank.com的时间，，，，，，会被重定向到被攻击者控制的IP为6.6.6.6的效劳器。 。。。。。。。而设置了类似bailiwicks的装备，，，，，，会去找权威效劳器询问www.bank.com的IP。 。。。。。。。


Dnsmasq缓冲区溢出误差



● CVE-2020-25681


以下名称以规范的DNS名称顺序排序。 。。。。。。。最主要的标签是“example”。 。。。。。。。在此级别上，，，，，，“example”将首先排序，，，，，，然后是以“a.example”最后的名称，，，，，，然后是以“z.example”最后的名称。 。。。。。。。每个级别中的名称以相同的方法排序。 。。。。。。。如下图所示。 。。。。。。。


10.png


CVE-2020-25681误差位于dnssec.c文件的sort_rrset()函数中，，，，，，该函数认真凭证DNSSEC验证历程的要求接纳冒泡排序算法将给定的资源纪录荟萃（RRSets）排序为规范顺序。 。。。。。。。该函数界说如下：


11.png


它接受了响应数据包（header）以及数据包长度（plen）。 。。。。。。。rrset是指向资源纪录荟萃中RR数组的指针，，，，，，而rrsetidx是荟萃中的RR数，，，，，，rr_desc是指向与RRset关联的RR类型的形貌符的指针。 。。。。。。。最后，，，，，，有两个缓冲区buff1和buff2，，，，，，它们用作排序例程的事情区缓冲区。 。。。。。。。这两个缓冲区在程序最先时都是相对分派的，，，，，，它们是daemon> workspacename和daemon-> keyname。 。。。。。。。当dnsmasq开启DNSSEC时，，，，，，将会分派这两个缓冲区。 。。。。。。。


12.png


MAXDNAME巨细为1025，，，，，，以是workspacename和keyname的巨细2050，，，，，，也是该误差爆发溢出的缓冲区。 。。。。。。。


首先启动dnsmasq，，，，，，并设置参数为：

-p 53535 --no-daemon --log-queries -S127.0.0.2 --no-hosts --no-resolv -d -q --dnssec--trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D，，，，，，结构完恶意DNS盘问响应包，，，，，，使用下令行：dig NS+dnssec @localhost -p 53535 .，，，，，，掷中sort_rrset()函数断点后如下图所示：


13.png


在结构资源纪录荟萃（RRSets）时，，，，，，必需包管纪录个数大于1，，，，，，这样才华包管进入排序循环。 。。。。。。。


这里结构的rrsetidx为0x3。 。。。。。。。


14.png


正常数据包如下图所示：


15.png


Answers块中，，，，，，p1指向第一个资源纪录，，，，，，p2指向第二个，，，，，，然后举行排序。 。。。。。。。


16.png


划分跳过Class，，，，，，Type和TTL，，，，，，抵达RDATA区域。 。。。。。。。


17.png


Data lengh为20，，，，，，为Name Server的长度。 。。。。。。。然后进入排序循环。 。。。。。。。


18.png


行315，，，，，，首先挪用get_rdata()函数剖析第一个资源纪录p1的RDATA域中的NameServer，，，，，，看下该函数实现。 。。。。。。。


19.png


判断d是否即是-1，，，，，，这里不即是，，，，，，不进入if语句，，，，，，来到如下代码。 。。。。。。。


20.png


然后挪用extract_name()函数剖析，，，，，，这里需要包管extract_name()函数剖析过失返回0，，，，，，包管进入get_rdata()函数返回为0，，，，，，通过设置超长NameServer字符串即可。 。。。。。。。


21.png


进入if语句，，，，，，行318，，，，，，盘算len1，，，，，，为end1-p1，，，，，，即是NameServer的长度。 。。。。。。。行319，，，，，，挪用memcpy()将p1拷贝到buff1+left1中。 。。。。。。。


22.png


这里len1设置为3550，，，，，，p1为NameServer，，，，，，长度RDLENGTH为用户可控。 。。。。。。。前文已经先容buff1为daemon>workspacename，，，，，，巨细为2020，，，，，，因此爆发堆溢出。 。。。。。。。


23.png


缓解步伐


● 升级dnsmasq到最新版本(2.83及以上)，，，，，，这是现在最有用的要领。 。。。。。。。

● 若是不须要，，，，，，设置dnsmasq装备不要在WAN口监听。 。。。。。。。

●  只管设置dnsmasq最大转发盘问条目小一点。 。。。。。。。

● 暂时关闭DNSSEC验证选项。 。。。。。。。

● 使用为DNS提供传输清静的协议，，，，，，如DoT或DoH。 。。。。。。。


参考链接：


[1] https://www.jsof-tech.com/disclosures/dnspooq/

[2] https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq-Technical-WP.pdf

[3] https://www.rfc-editor.org/rfc/rfc1664.txt

[4] https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.html

[5] https://spoofer.caida.org/summary.php

[6] https://www.rfc-editor.org/rfc/rfc7858.txt

[7] https://www.rfc-editor.org/rfc/rfc5452.txt

[8] http://www.thekelleys.org.uk/dnsmasq/doc.html

[9]https://dl.acm.org/doi/10.1145/3372297.3417280

[10] https://github.com/Z3Prover/z3

[11] https://www.chromium.org/developers/design-documents/dns-prefetching

[12] https://www.rfc-editor.org/rfc/rfc4033.txt

[13] https://zhuanlan.zhihu.com/p/92899876


万利国际官网起劲防御实验室（ADLab）


ADLab建设于1999年，，，，，，是中国清静行业最早建设的攻防手艺研究实验室之一，，，，，，微软MAPP妄想焦点成员，，，，，，“黑雀攻击”看法首推者。 。。。。。。。阻止现在，，，，，，ADLab已通过CVE累计宣布清静误差近1100个，，，，，，通过 CNVD/CNNVD累计宣布清静误差1000余个，，，，，，一连坚持国际网络清静领域一流水准。 。。。。。。。实验室研究偏向涵盖操作系统与应用系统清静研究、智能终端清静研究、物联网智能装备清静研究、Web清静研究、工控系统清静研究、云清静研究。 。。。。。。。研究效果应用于产品焦点手艺研究、国家重点科技项目攻关、专业清静效劳等。 。。。。。。。


adlab.jpg