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）组成： ：
DNS Header是每个DNS报文都必须占有的一部门，它的长度固定为12个字节。。。Question部门存放的是向服务器查问的域名数据，通常情况下它只有一条Entry。。。每个Entry的体式是一样的，如下所示： ：
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系统中极度重要的一部门，它占有一个变长的结构，具体体式如下： ：
● 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.hnwnww.com这个域的DNS，或许如下： ：
www.hnwnww.com. NS ns1.www.hnwnww.com.
www.hnwnww.com. NS ns2.www.hnwnww.com.
www.hnwnww.com. NS ns3.www.hnwnww.com.
这三笔纪录，就是说http://ns1.www.hnwnww.com、、http://ns2.www.hnwnww.com、、http://ns3.www.hnwnww.com（以下简称ns1、、ns2、、ns3）都是http://www.hnwnww.com域的权威DNS，询问肆意其中一个都能够。。。
当然，在com的权威DNS里，还会纪录ns1~ns3这几个http://www.hnwnww.com权威DNS的IP，会一并返回给问询者，以便问询者直接用IP联系ns1~ns3。。。
● A纪录
A纪录就是最经典的域名和IP的对应，在http://ns1.www.hnwnww.com里面，纪录着百度公司各产品的域名和IP的对应关系，每一个这样的纪录，就是一个A纪录，好比下面的3个A纪录： ：
image.www.hnwnww.com A 1.2.3.4
wenku.www.hnwnww.com A 5.6.7.8
tieba.www.hnwnww.com A 9.10.11.12
若是用户询问http://ns1.www.hnwnww.com： ：“http://wenku.www.hnwnww.com的IP是几多？”，ns1就会找到对应的A纪录或者CNAME纪录并返回。。。
● CNAME纪录
CNAME纪录也称别号纪录，允许将多个纪录映射到统一台推算机上。。。好比，在ns1中，并没有http://www.www.hnwnww.com的A纪录，而是一个CNAME纪录： ：
www.www.hnwnww.com CNAME www.a.shifen.com
也就是通知用户，http://www.www.hnwnww.com的别号是http://www.a.shifen.com，能够直接要求解析http://www.a.shifen.com。。。
DNS缓存攻击
当接见www.www.hnwnww.com时，域名解析的大体流程如下图所示。。。
DNS缓存中毒是一种比力经典的攻击方式，若是攻击者能够成功执行，就会在DNS缓存服务器上留下一个有害的条款，使得用户接见正常网站的要求重定向到被攻击者节制的恶意网站。。。
DNSpooq系列缓存中毒缝隙的单一攻击流程图如下图所示： ：
（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查问了局如下所示： ：
红框中为应答部门，这是未开启DNSSEC的情况下的。。。我们执行号令行： ：dig+dnssec @8.8.8.8 paypal.com，得到的DNS查问了局如下所示： ：
蓝框中就是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位熵值。。。
● CVE-2020-25685
若是要对DNS转发器进行投毒，除了必要猜对正确的TXID和源端口，攻击者发送伪造的回复还必要匹配已盛开的frecs。。。若是想让frec匹配，那么TXID和问题区都要匹配，换句话说，回复的内容是之前询问过的。。。
dnsmasq只存放问题区的哈希值，而不是把整个语句存下来。。。当整个查问提交的时辰，这个哈希值会被保留。。。
若是dnsmasq没有编译DNSSEC支持，那么他默认使用CRC32作为哈希算法。。。问题就在于CRC32从密码学角度并不是一个安全的算法。。�Ｄ芄缓芮崴傻氖褂美嗨芐MT solver等工具进行CRC32碰撞，这里道理不做过多介绍。。。
所以基于这一个性，攻击者能够天生多个查问，每一个查问的CRC32的值都一样，不外查问的是分歧的域名，而这些域名最好是不存在的，即没有被缓存的。。。而后攻击者能够发送一个拥有一样CRC32值的伪造的回复。。。
如下图所示，攻击者节制一台客户端对多个域名提议问询，每一个CRC32的值都是一样的，而后在递归DNS服务器回复之前，回复一个拥有一样CRC32值的域名或IP，攻击即有可能成功。。。
● 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”结尾的名称。。。每个级别中的名称以一样的方式排序。。。如下图所示。。。
CVE-2020-25681缝隙位于dnssec.c文件的sort_rrset()函数中，该函数掌管依照DNSSEC验证过程的要求选取冒泡排序算法将给定的资源纪录集中（RRSets）排序为规范挨次。。。该函数界说如下： ：
它接受了响应数据包（header）以及数据包长度（plen）。。。rrset是指向资源纪录集中中RR数组的指针，而rrsetidx是集中中的RR数，rr_desc是指向与RRset关联的RR类型的描述符的指针。。。最后，有两个缓冲区buff1和buff2，它们用作排序例程的工作区缓冲区。。。这两个缓冲区在法式起头时都是相对分配的，它们是daemon> workspacename和daemon-> keyname。。。当dnsmasq开启DNSSEC时，将会分配这两个缓冲区。。。
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()函数断点后如下图所示： ：
在机关资源纪录集中（RRSets）时，必须保障纪录个数大于1，这样能力保障进入排序循环。。。
这里机关的rrsetidx为0x3。。。
正常数据包如下图所示： ：
Answers块中，p1指向第一个资源纪录，p2指向第二个，而后进行排序。。。
别离跳过Class，Type和TTL，达到RDATA区域。。。
Data lengh为20，为Name Server的长度。。。而后进入排序循环。。。
行315，首先挪用get_rdata()函数解析第一个资源纪录p1的RDATA域中的NameServer，看下该函数实现。。。
判断d是否等于-1，这里不等于，不进入if语句，来到如下代码。。。
而后挪用extract_name()函数解析，这里必要保障extract_name()函数解析谬误返回0，保障进入get_rdata()函数返回为0，通过设置超长NameServer字符串即可。。。
进入if语句，行318，推算len1，为end1-p1，即是NameServer的长度。。。行319，挪用memcpy()将p1拷贝到buff1+left1中。。。
这里len1设置为3550，p1为NameServer，长度RDLENGTH为用户可控。。。前文已经介绍buff1为daemon>workspacename，巨细为2020，因而产生堆溢出。。。
缓解措施
● 升级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
OG东方厅积极防御尝试室（ADLab）
ADLab成立于1999年，是中国安全行业最早成立的攻防技术钻研尝试室之一，微软MAPP打算主题成员，“黑雀攻击”概念首推者。。。截止目前，ADLab已通过CVE累计颁布安全缝隙近1100个，通过 CNVD/CNNVD累计颁布安全缝隙1000余个，持续维持国际网络安全领域一流水准。。。尝试室钻研方向涵盖操作系统与利用系统安全钻研、、智能终端安全钻研、、物联网智能设备安全钻研、、Web安全钻研、、工控系统安全钻研、、云安全钻研。。。钻研成就利用于产品主题技术钻研、、国度重点科技项目攻关、、专业安全服务等。。。
京公网安备11010802024551号