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://m.yhdeyi.com这个域的DNS ，，，，或许如下：
m.yhdeyi.com. NS ns1.m.yhdeyi.com.
m.yhdeyi.com. NS ns2.m.yhdeyi.com.
m.yhdeyi.com. NS ns3.m.yhdeyi.com.
这三条纪录 ，，，，就是说http://ns1.m.yhdeyi.com、http://ns2.m.yhdeyi.com、http://ns3.m.yhdeyi.com（以下简称ns1、ns2、ns3）都是http://m.yhdeyi.com域的权威DNS ，，，，询问恣意其中一个都可以 。。。。。
虽然 ，，，，在com的权威DNS里 ，，，，还会纪录ns1~ns3这几个http://m.yhdeyi.com权威DNS的IP ，，，，会一并返回给问询者 ，，，，以便问询者直接用IP联系ns1~ns3 。。。。。
● A纪录
A纪录就是最经典的域名和IP的对应 ，，，，在http://ns1.m.yhdeyi.com内里 ，，，，纪录着百度公司各产品的域名和IP的对应关系 ，，，，每一个这样的纪录 ，，，，就是一个A纪录 ，，，，好比下面的3个A纪录：
image.m.yhdeyi.com A 1.2.3.4
wenku.m.yhdeyi.com A 5.6.7.8
tieba.m.yhdeyi.com A 9.10.11.12
若是用户询问http://ns1.m.yhdeyi.com：“http://wenku.m.yhdeyi.com的IP是几多 ？？？？？ ？” ，，，，ns1就会找到对应的A纪录或者CNAME纪录并返回 。。。。。
● CNAME纪录
CNAME纪录也称又名纪录 ，，，，允许将多个纪录映射到统一台盘算机上 。。。。。好比 ，，，，在ns1中 ，，，，并没有http://www.m.yhdeyi.com的A纪录 ，，，，而是一个CNAME纪录：
www.m.yhdeyi.com CNAME www.a.shifen.com
也就是告诉用户 ，，，，http://www.m.yhdeyi.com的又名是http://www.a.shifen.com ，，，，可以直接请求剖析http://www.a.shifen.com 。。。。。
DNS缓存攻击
当会见www.m.yhdeyi.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
918博天堂起劲防御实验室（ADLab）
ADLab建设于1999年 ，，，，是中国清静行业最早建设的攻防手艺研究实验室之一 ，，，，微软MAPP妄想焦点成员 ，，，，“黑雀攻击”看法首推者 。。。。。阻止现在 ，，，，ADLab已通过CVE累计宣布清静误差近1100个 ，，，，通过 CNVD/CNNVD累计宣布清静误差1000余个 ，，，，一连坚持国际网络清静领域一流水准 。。。。。实验室研究偏向涵盖操作系统与应用系统清静研究、智能终端清静研究、物联网智能装备清静研究、Web清静研究、工控系统清静研究、云清静研究 。。。。。研究效果应用于产品焦点手艺研究、国家重点科技项目攻关、专业清静效劳等 。。。。。
京公网安备11010802024551号