原文标题：DNS Cache Poisoning Attack Reloaded- Revolutions with Side Channels
原文作者：Keyu Man、Zhiyun Qian、Zhongjie Wang、Xiaofeng Zheng、Youjun Huang、Haixin Duan
原文地址：https://www.cs.ucr.edu/~zhiyunq/pub/ccs20_dns_poisoning.pdf
笔记作者：yplmyl3s
0x00 摘要
DNS缓存中毒攻击，实践中往往通过基于随机化的源端口机制来进行防御来缓解。本文中作者研究了UDP软件堆栈中存在的缺陷，这些缺陷将会导致DNS缓存中毒“死恢复燃”。作者的研究的攻击方法采用“分而治之”的方式，主要是先猜测源端口，而后猜测事务ID，并将以前需要发送2^32^个响应包和减少到只需要发送2^16^+2^16^个，并且攻击者可以通过增加攻击窗口来提供攻击成功率。该攻击会影响DNS基础设施中所有缓存层，受害者易受攻击的主要条件是操作系统及其网络配置允许ICMP错误回复。根据作者的实验，互联网上超过34%主流的开放解析器易受攻击（尤其是85%的主流DNS服务，包括谷歌的8.8.8.8）。此外，作者还在受控实验和生产DNS解析程序（有授权）中进行了验证，并得到了积极肯定的结果。
本文主要包括9个部分：
序言，介绍DNS缓存中毒攻击的相关概念，阐明了该研究做出的3个贡献。
DNS缓存中毒攻击现状，包括当前的防御措施以及新的攻击面。
攻击概述，提出一种针对DNS新的攻击方式，该攻击方法适用于现有DNS软件栈和所有DNS缓存层，并从威胁模型和攻击流程对该攻击方法进行了阐述。
DNS源端口推测思路与过程，主要分析UDP源端口可扫描性分析、ICMP速率限制、面向公共的源端口扫描方法、私有的源端口扫描方法、DNS转发器和解析器的脆弱性。
阐述如何扩展攻击窗口，提出2种新的策略，一是在转发器攻击中扩展攻击窗口，二是在解析器中扩展攻击窗口。
真实攻击中需要注意的事项，主要包括3个方面，即，需要绕过缓存记录的TTL、同时处理多个权威名称服务器、同时处理多个权威名称服务器。
端到端攻击，对真实环境中的攻击的进行评估分析，包括家庭中使用的转发器，以及具有区域列表配置和网络条件的生产解析器。分别设置实验条件，详细阐述了攻击过程，最后得到结果并进行分析。
对攻击绑定与未绑定的设备的区别、其他操作系统上的UDP源端口推断、其他易受攻击的协议、配置响应速率限制（RRL）的最佳实践等4个方面进行了讨论，并提出了防御措施。
介绍了DNS盲伪造攻击与缓存中毒、网络侧通道漏洞研究方面的相关工作。
最后总结了本文的研究成果。
0x01 序言
域名系统(DNS)是互联网的重要组成部分，作用是将人们可读的网址转换为IP地址。如今，DNS承载了许多其他的安全关键应用程序，如反垃圾邮件防御，路由安全等。DNS在TLS信任方面也起着至关重要的作用，破坏DNS记录完整性将会带来灾难性的安全隐患，攻击者发布的虚假证书，将会对公钥加密技术造成影响。作者对当前DNS缓存中毒攻击的相关研究做了介绍，最后总结了本文的3个贡献：
系统地分析了应用程序和操作系统层级行为之间的交互，从而发现了通用的UDP源端口去随机化策略，关键的一个是由发送ICMP错误消息的全局速率限制引入的信道漏洞。
研究了源端口去随机化策略对各种攻击模型的适用性。并且开发了新的方法来显著扩展攻击窗口，其中一种方法利用了应用层速率限制特性。
针对各种服务器软件、配置和网络状况进行了广泛评估，并得到积极结果。研究发现，在大多数情况下，攻击者只需要几分钟就可以成功地进行端到端中毒攻击。最后，讨论最有效和最简单的缓解措施。
0x02 DNS缓存中毒攻击现状
2008年发生的DNS缓存中毒攻击的经典案例中，攻击者将DNS解析器作为攻击目标，让一个非路径攻击者诱使易受攻击的DNS解析器向上游权威名称服务器发出查询。然后，攻击者尝试使用名称服务器的伪造IP注入恶意响应。如果恶意响应在任何合法响应之前到达，并且如果它与查询中的“机密”匹配，则解析程序将接受并缓存恶意结果。具体而言，攻击者需要猜测查询的正确源/目标IP、源/目标端口和事务ID（TxID）。事务ID为16位长。当源端口和目标端口（即53）都固定时，16位是唯一的随机性。因此，非路径攻击者可以简单地使用65536个恶意响应来暴力猜解所有可能的情况，更可以通过“生日攻击”等类似的方法来优化以致加速攻击。
2.1最先进的防御措施
从那次攻击后，许多用来消除DNS缓存中毒威胁的防御措施被广泛应用，他们使得攻击不再可行。下面描述应用最为广发的防御措施。
信源端口的随机化，它将随机性从16位增加到32位。作为路径外攻击者必须同时猜测源端口和TxID。
域名中字母大写的随机化，即0x20编码。
服务器选择随机化，它的随机性取决于名称服务器的数量。
DNSSEC，依赖于解析器和权威名称服务器的支持。
2.2 DNS层次结构中的新攻击面
现代DNS基础设施具有多层缓存，客户机应用程序经常（通过API调用 gethost-byname（）函数）向本地操作系统存根解析器发起DNS查询—通常是一个单独的系统进程，它维护本地操作系统范围的DNS缓存。存根解析器不执行任何迭代查询，而是将请求转发到上一层递归解析器。DNS转发器通常存在于Wi-Fi路由器中，并且维护一个专用的DNS缓存。它是递归解析器，它完成了迭代查询权威名称服务器的真正工作。然后返回答案并缓存在每一层中。从技术上讲，所有缓存层都会受到DNS缓存中毒攻击。然而，大多数新提出的攻击都集中在解析器上，对存根解析器和转发器的研究非常有限。图1展示了具有多层缓存的DNS基础结构。
0x03 攻击概述
本文提出一种通用的、新颖的攻击方法，适用于所有现代的DNS软件栈，影响DNS缓存的所有层。其主要特点是破解了当前最常见、最有效的源端口随机化防御措施。
威胁模型。此种攻击方法主要聚焦DNS转发器、DNS解析器以及能够触发转发器或解析程序请求的计算机。并且采用非路径（不能窃听转发器和解算器之间的通信）攻击和IP欺骗。
攻击流程。无论是转发器还是解析器，此种攻击方法总是从触发其中一个发送DNS查询开始，主要包括2个关键步骤（如图2所示）：
推断源端口。为了克服源端口的随机性，我们在网络堆栈中利用一个新的通用侧通道来扫描和发现用于发起DNS查询的源端口，速度最多为每秒1000次猜测。
扩展攻击窗口。通常一个未完成的查询将在几十或几百毫秒内收到来自上游服务器的回复。这是不够的，因为攻击需要时间来推断源端口和注入恶意DNS回复。我们发现了有效和新的策略（不同于转发器和解析器攻击，可以极大地将攻击窗口延长到至少几秒（甚至超过10秒），允许实际的缓存中毒机会。一旦知道了源端口号，攻击者就可以简单地截获大量伪造的DNS回复，这些回复会以很高的速度进行，因为大多数服务器都有足够的网络带宽。
0x04 DNS查询源端口推测
4.1 UDP源端口可扫描性分析
UDP是一种与TCP协议有着本质却别的无状态协议。在UDP编程指南（rfc8085）中规定，“可以直接发送和接收UDP数据报，而不需要任何连接设置。使用套接字API，应用程序可以在单个UDP套接字上从多个IP源地址接收数据包。“此外，为了确保应用程序只从一个特定的源地址接收数据，这些应用程序必须在应用层执行相应的检查，或者明确请求操作系统过滤接收到的数据包。
作者实验发现，在特定的远程IP上调用sendto（）的客户机和在同一个套接字上调用recvfrom（）的客户机也可以从“任何其他IP”接收数据包。作者在Windows、Linux和MacOS等操作系统上均验证了这种行为。当dns服务器发出查询时，它的源端口将对外开放，通过分析这种行为，攻击者可以通过简单的UDP端口扫描获得收获。攻击者可以扫描任何UDP数据包的端口范围，在命中正确的端口时不会触发任何事件（因为探测将被操作系统接受，但在应用程序层被丢弃），或者在收到CMP端口不可达数据包时丢弃。
UDP编程指南（RFC 8085）指出，“许多操作系统也允许连接UDP套接字，即将UDP套接字绑定到特定的一对地址和端口。”，现代的socket api允许在UDP socket上使用connect（），但“这只是一个本地操作，用于简化本地发送/接收函数并过滤流量”。因此，当从源端口向特定的目标IP地址和端口发出DNS查询时，操作系统将只接受来自同一远程IP和端口的传入数据包。具体来说，当在实际网络堆栈上测试行为时，我们发现它们会拒绝IP或端口错误的数据包，并用ICMP端口不可达的消息（就好像该数据包是端口扫描尝试）进行响应。这有效地防止了直接扫描DNS查询的源端口。
总之，源端口的可扫描性取决于DNS软件的实现，即是否在UDP套接字上发出了一个connect（）API 调用。作者研究发现在三个最流行的DNS转发器和解析程序软件BIND、Unbound和dnsmasq中，只有BIND使用connect（）。然而，我们开发了不同的扫描方法，并且每种方法都适用。
4.2 ICMP速率限制
有效扫描UDP源端口的一个主要障碍是终端主机上传出ICMP错误消息的常见速率限制。即使在源端口面向公共并且可以由任何IP地址直接扫描的简单情况下，攻击者的扫描速度受到每秒允许的ICMP数据包数（表示源端口未被使用的信号）的限制。以往，ICMP 限制策略将用来限制路由器上的资源消耗，如今，速率限制机制已被各大运营商普遍实施。作者重点介绍了Linux ICMP速率限制行为。Linux系统中，对于每秒可以发送多少个ICMP错误数据包，既有单个IP的速率限制，也有全局速率限制。其中，单个IP速率限制是在Linux的早期版本2.4.10中引入的，全局速率限制是在3.18中引入的，为了改进单个IP速率限制。
默认情况下，单个IP速率限制为每秒一个（累积最大突发数为6），这将严重限制扫描速度；全局速率限制实际上是1000（周期性最大允许突发为50）。两者都是以令牌桶的方式实现的，单个IP令牌以每秒一个的速率恢复，而全局令牌则以每毫秒一个的“名义”速率恢复（但实际的令牌增量只发生在自上次增量以来至少20毫秒之后），可用令牌的数量始终上限为50。作者还测试了WindowsServer2019（版本1809）、MacOS10.15和FreeBSD12.1.0，它们都有全局ICMP速率限制，分别是200、250和200。而且它们都没有每IP速率限制。
4.3 面向公众的源端口扫描方法
在这种情况下，即使源端口可以被任何攻击者IP直接探测，也必须通过单个IP速率限制（主要在Linux中）来实现加速扫描。作者开发了三种不同的探测方法来克服ICMP速率限制。
如果攻击者拥有多个IP地址，或者多台机器，或者一台具有IPv6地址的机器，可以简单得绕过单个IP限制。作者在支持IPv6的住宅网络中的一台机器上进行了测试，并在/64中选择了几个ips来成功地发送和接收流量。
如果攻击者只拥有一个IPv4地址，仍然可以使用DHCP请求多个地址。作者验证了在一个家庭网络中可以获得多个私有IPv4地址，并且在一个教育网络中进行了测试，同样一台物理机器也可以通过这种方法获得多个公共IPv4地址。
如果攻击者拥有单个IPv4地址，且以上方法均失效，则最后一种方法是利用IP欺骗绕过单个IP速率限制，并将全局速率限制作为侧通道来推断欺骗的探测是否命中了正确的源端口。
如图3所示，在Linux中观察到50个ICMP数据包的最大突发流量，攻击者首先发送50个伪造的UDP探测数据包，每个数据包具有不同的源IP。如果受害服务器在这50个端口中没有打开任何源端口，则会触发50个ICMP端口不可达消息（但攻击者无法直接观察到这些消息）。如果受害者服务器有𝑛个开放端口，则只有 50-n 个ICMP数据包将被触发（如𝑛UDP探测数据包将在应用层被自动丢弃）。攻击者使用其真实IP地址发送验证数据包，要么没有得到响应（如果全局速率限制耗尽），要么得到一个ICMP应答。
如果在第一批探测中找不到开放端口，攻击者将等待速率限制计数器恢复至少50毫秒，然后开始下一轮探测。扫描速度将被限制在每秒1000次。因此，枚举所有的65536个端口需要60多秒。尽管如此，攻击者可以通过简单的重复试验，并不断提升试验成功的可能性。
时间因素。这种攻击方法需要很强的时间要求，攻击者需要确保的是必须在20毫秒的时间窗口内发送50个伪造的探测包和验证包.再者，攻击者必须等待足够长的时间才能恢复最多50个令牌。如果网络状况不理想，则需要等待50毫秒以上。
折半查找，缩小到精确端口。假设在一个特定的探测轮中，50个端口中只有一个是开放的，可以使用简单的折半查找来快速缩小到确切的端口。在每一轮二分搜索中，我们总是先探测范围的左半部分。如果匹配，即50个欺骗探测包触发49个应答，攻击者可以观察到一个对其验证包的应答，然后继续搜索其左半部分。否则，我们假设端口位于右半部分，并在那里进行二分搜索。注意，需要发送“填充数据包”，以确保当50次猜测没有一次命中正确的端口时，全局速率限制被耗尽。填充报文是指向已知关闭的UDP端口的欺骗报文，保证会触发ICMP应答。
处理噪声。DNS服务器通常同时为多个客户端提供服务，创建多个未完成的DNS查询和源端口。因此，源端口扫描可能会发现许多相关端口。然而，大多数这样的查询都是暂时的，端口扫描过程可以快速发现一个在折半搜索过程中消失的开放端口并回归到线性搜索。相反，我们假设攻击者触发的DNSqueries将持续更长的时间，例如，以秒为单位而不是毫秒。另一个噪声源来自数据包丢失和重新排序。作者在探测包和验证包之间插入一个延迟，根据经验，该延迟被确定为大于抖动的两倍。当出现误报时，它们会在折半搜索过程中自动处理–它将检测不到打开的实际端口并返回线性搜索。即使可以处理，过多的误报也会很快耗尽单个IP速率限制。此外，DNS服务器本身可能会受到随机UDP端口探测的影响，因此会生成ICMP不可达消息，这将使我们错误地认为没有开放端口，但事实上有，因为验证数据包不会触发任何ICMP不可达的回复，因为噪声耗尽了速率限制。幸运的是，并不是所有的ICMP回复都受速率限制。例如，最常见的触发ICMP echo回复不受限制。
4.4 私有源端口扫描
如前文所述，如果在UDP套接字上执行connect（），则端口实际上成为远程对等方的“私有”端口，从而使以前的方法无效。作者的思路是使用上游DNS服务器的源IP发送伪造的UDP数据包。在DNS解析器成为受害者的例子中，可以发送UDP数据包，用权威名称服务器的伪造IP探测不同的源端口。如果命中了正确的源端口，则不会生成ICMP应答。否则，就会有。然后，可以使用与边通道相同的全局ICMP速率限制来推断是否触发了这样的ICMP消息。乍一看，由于ICMP消息的单个IP速率限制，此方法可以以每秒一个端口的低速工作。令人惊讶的是，在分析了ICMP 速率限制实现的源代码之后，作者发现全局速率限制是在单个IP速率限制之前检查的，即使单个限制可能最终确定不应发送ICMP应答，数据包仍要接受全局速率限制检查，并且一个令牌将被扣除。Linux开发人员故意做了这样的设计，以避免调用昂贵的单各个IP速率限制检查，这涉及到查找单个IP数据结构的搜索过程。这实际上意味着，基于侧通道的扫描，可以忽略单个IP速率限制，因为它只确定是否生成了最终的ICMP应答，而与全局速率限制计数器减量无关。因此，可以继续使用与以前效率大致相同的扫描方法，达到每秒1000个端口。图4展示了稍加修改的扫描工作流程。
由于单个IP速率限制，只要至少扫描了一个非活动端口，受害服务器将始终只生成一个ICMP应答（在稳定状态下），图的左右两侧都是这种情况𝑛专用开放端口（到上游服务器），全局速率限制计数器仍递减到𝑛因为受害者试图制造50−𝑛ICMP回复。相反，当所有50个探测器都连接到非活动端口（图的左侧）时，计数器递减为0。其余过程与之前相同，可以启动二进制搜索以缩小到特定端口。
对面向公众的源端口扫描的影响。基于这些知识，可以这样修改4.3节中的方法3：不需要在每轮探测中使用50个不同的IP，而只需要使用一个欺骗IP（或攻击者拥有的第二个IP），而不需要使用任何不同的IP（有时可能是一个障碍）。
噪音处理。与面向公共的源端口上的扫描相比，此扫描中的噪声本质上更小。这是因为每个源端口现在实际上只对一个远程IP“打开”，而该IP最初是在connect（）中指定的。因此，假设受害者是解析程序，则其大多数查询（噪音）将被指定到与特定攻击目标不同的名称服务器。其他噪声条件，如数据包丢失和重新排序仍然适用。类似地，噪声处理技术也适用（例如，使用多个IP来减轻每IP ICMP速率限制）。
4.5易受攻击的DNS转发器和解析程序
如果转发器或解析器的DNS查询UDP 源端口容易被推测，或者支持全局ICMP速率限制，或者使用公开端口而不适用connect（），则认为该转发器或解析程序易受攻击。
易受攻击的转发器。作则研究了六个家庭路由器设备，所有这些设备在默认情况下都充当支持DNS缓存的转发器。结果如表1所示。
易受攻击的解析程序。我们研究了14个流行DNS应用程序，结果表明，其中12个是非常严重的易受攻击的。试验中发现，由于在多个提供者中遇到了防火墙策略，为了在某些服务器上触发ICMP响应，探测包的源端口必须设置为53。如表2所示。
作者注意到了任意播送的前端IP后面的后端服务器IP的数量（例如，8.8.8.8）。这些后端IP对应于可以扫描端口的可访问服务器。多个这样的IP的存在增加了攻击的难度，因为需要决定扫描哪些IP。为了发现后端IP，只需从同一台机器向前端发送100个查询，并在拥有的权威名称服务器上记录观察到的IP。对于只遇到几个IP的情况，可以简单地同时扫描所有IP。
0x05 扩展攻击窗口
攻击窗口越长，攻击者可以扫描的端口越多，注入恶意记录的时间也越长。因此，防御目标是“禁用”上游服务器，并防止他们能够响应攻击者触发的DNS查询。根据攻击目标（即转发器或解析器），作者提出了两种新的策略。
5.1 在转发器攻击中扩展窗口
攻击者首先发送自己域的地址到 转发器，它最终将触发上游解析器来查询由攻击者控制的权威名称服务器。名称服务器被有意配置为无响应，以便转发器在端口开放的源端口时等待尽可能长的时间（因为解析器也已停止）。根据RFC 8499，递归解析器的作用是处理名称的完整解析，并向其客户机提供“最终答案”。这包括递归地处理别名，并汇编最终答案，包括设计的任何别名重定向。更重要的是，解析器需要执行完整性检查，而转发器则不是。这意味着转发器信任上游解析器及其响应。这不是安全缺陷；相反，它是一种设计选择，以防止转发器重复解析器的工作。转发器将接受恶意响应（可能由来自LAN或外部的攻击者注入），并缓存攻击者和受害者的域记录。这种策略非常有效，因为可以在转发器上施加最大的等待时间（即，创建最大可能的攻击窗口）。具体来说，大多数转发器有一个非常宽松的超时时间（有时接近一分钟，例如在dns masq中）。为了防止冲突解决程序过早生成此类消息，作者还采用了一种技术，这种技术有时可以使冲突解决程序保持更长的工作时间。诀窍是让攻击者拥有的权威名称服务器以缓慢的速度响应一些CNAME记录，从而产生一种它正在取得进展的假象。在某些情况下（例如CloudFlare），这会延迟解析器的响应超过一分钟。
5.2 解析攻击中的窗口扩展
作者提出在权威名称服务器中利用速率限制的安全特性，作为在解析器攻击中使名称服务器禁用和扩展窗口的一种方法。现代DNS名称服务器软件（如BIND、NSD、PowerDNS）都支持一种称为响应速率限制（RRL）的公共安全功能，这是对DNS放大攻击的一种攻击，在这种攻击中，大量恶意DNS查询被发送到提供受害者IP地址的权威名称服务器。为了限制DNS应答数据包的数量，RRL功能允许按IP、按前缀甚至全局限制触发的响应。具体来说，如果达到限制，则响应要么被截断，要么被丢弃。如果攻击者能够以高于配置限制的速率（使用目标解析程序的IP）注入伪造的DNS查询，则可以恶意利用此功能使域名服务器禁用。
为了了解此种策略的可能性，作者进行了一个实验来测量Alexa网站上前10k名的域名服务器的响应率。
测量方法。为了触发RRL，每秒发送1K个查询，持续15秒，然后再向每个域名服务器IP发送大约4kpps的测试，持续15秒；两个测试之间有两秒的间隔，以避免干扰。如果给定域有多个名称服务器，选择第一个。在这两种情况下，查询都是均匀分布的（而不是以突发方式发送），都试图询问WWW子域的记录。理由是1kpps和4kpps表示足够低的吞吐量，分别约为0.6Mbps和2.5Mbps。
伦理考虑。作者有意识地采取了一些措施来限制对这些服务器操作的影响。首先，在查询中搜索一个记录，通常会导致较小的响应，以节省目标网络的资源。第二，查询中的域名总是相同的，这使得服务器上的处理开销最小（结果很可能缓存在内存中，很容易获取）。第三，选择发送间隔均匀的查询（而不是突发），以避免给服务器带来压力。最后，在用于进行探测的IP地址上设置了一个web服务器，为带有选择退出指令的网页提供服务。
结果分析。作者按照4kpps 进行测试，并按降序对丢失率进行排序，结果如图6所示。总体而言，大约有25%的域的名称服务器丢失率高于1%。
为了分析这些域中有多少部分是易受攻击的（可以成功禁用），如果一个域名的名称服务器有66.7%或更高的诱导丢失率，则它是易受攻击的。此外，剩余的损失率从1kpps增加到4kpps的情况中，大约有5000个样本的差异为2%或更高。作者认为，随着探测率的增加，大多数情况会进一步增加，因此也可能变得脆弱。因此，在我们认为有漏洞的10万（18%）样本中，总共有18110例（13110和5000）。最后，在75%的1kpps和4kpps测试都没有损失的情况下，可能有更多的易受攻击的情况，由于相对较低的探测速度，根本无法发现。然而，出于道德考虑，没有以更高的速度进行探索。为了深入了解这些情况，作者设法从合作者那里获得权限，以测试为非营利网站配置的授权名称服务器。以更高的速率探测服务器（深夜以避免中断）。最初以4pps的速率探测时，未观察到任何丢失。当速度增加到25kpps时，开始出现丢失。当速度提高到50kpps时，丢失率将达到75%。
0x06 实际攻击注意事项
绕过缓存记录的TTL。如果攻击者试图毒害良性域，可以 直接触发解析器执行攻击者域名查询，它可能会缓存不需要的合法记录，这将强制攻击程序在开始下一次攻击尝试之前等待缓存超时。
超时和重传查询。当在转发器或解析程序上触发DNS查询，并且没有从其上游接收到合法的响应时，它们不会永远等待。它们中的大多数都有一个超时时间来决定何时关闭当前套接字（以及相应的源端口）并重新传输。这意味着其中一些源端口可能是短暂的，很难捕获。
处理多个权威名称服务器。实践中许多域名都配置了多个权威名称服务器IP，以实现冗余和安全性。一些人认为这是针对解析程序的DNS缓存中毒攻击（称为“IP随机化”）的一种特殊防御措施，因为它增加了DNS查询的随机性。有两种方法可以解决这个问题。首先，一般的策略是同时使所有权威名称服务器禁用，因为它们平均很少存在。这将有助于在解析程序在连接所有名称服务器时遇到重复故障后，RTO以指数级增长。第二，如果一个解析器被解除绑定，它有一个独特的行为，它将停止联系一个名称服务器（将服务器列入黑名单），并将“永久”（即分钟）切换到其他可用的名称服务器，如果多次未能收到最初联系的服务器的消息，因此利用这种行为来执行他们称之为“名称服务器固定”的操作。在作者的实验中需要允许周期性的成功响应（通过暂停禁用过程）来避免姓服务器也被阻塞。
处理多个DNS解析程序后端服务器。如在4.5节介绍，许多公共DNS解析程序都有多个后端服务器（具有不同的IP）来执行实际的查询。作者发现后端服务器的选择通常严重偏向于少数（即使确实看到一些提供商总共有100多个），可能是根据位置和性能度量来确定的。这使得我们可以同时只关注一个少量IP集，这很容易实现，因为每个ip只需要1kpps的扫描流量。
0x07 端到端攻击
在本节中，作者通过评估现实环境中的攻击，包括家庭中使用的转发器，以及具有区域列表配置和网络条件的生产解析器。
7.1 攻击转发器（家庭路由器）
实验设置。作者选择小米R3（aWi-Fi家庭路由器）作为典型案例来发起端到端攻击。在实际家庭中，它是唯一的网关，10到15台设备始终通过无线路由器连接到互联网。此外，小米R3的上游DNS服务器设置为CloudFlare DNS（1.1.1.1）。它的DHCP服务器默认配置为在a/24网络中提供253个IPv4地址。最后，攻击机器是一个Raspberry Pi，它通过路由器无线连接。由于小米R3没有部署全局ICMP速率限制，其转发器软件也没有在UDP套接字上调用Connect（），使用4.3节中的策略2（通过DHCP获得多个IP），为了扩展攻击窗口，使用5.1节中的策略1。
攻击过程。攻击分为两个阶段，第一阶段，攻击者尝试使用DHCP获取240个IP地址。第二阶段，重复以下操作：攻击者向转发器发出查询，询问是否存在任意子域，例如nonce.attacker.com。如果收到serv FAIL/nxdomain，或者如果攻击者等待时间超过1分钟，表示出现问题，将通过发出另一个查询来重复攻击过程。否则，如果接收到错误响应，则表示成功注入了伪造的响应。在第二阶段，攻击者使用获取的IP地址来打开路由器上的端口。在可用的IP之间轮换，并确保永远不会超过单个IP速率限制（在稳定状态下为1pps）。在发现一个端口打开后，通过反复探测同一个端口来确认它至少保持打开一秒钟。如果有，就开始注入恶意反应。实验重复20次，并统计成功率，平均成功时间和其他统计数据。
结果分析。在20个实验中成功率为100%（如果攻击在30分钟内完成，作者认为是成功的）。平均成功时间为271s，第一阶段为103s，第一阶段为168s。第二阶段的标准偏差为109s，最大为739s，最小为83s，攻击平均需要扫描36325个端口才能成功；平均端口扫描速度为210pps，攻击产生了78MB的流量。
7.2 攻击生产解析程序
作者通过授权测试了针对由合作者管理的生产解析器的攻击。
实验设置。该解析器每天处理大约7000万个查询，其中有数千个来自多个机构的真实用户，并被配置为一个开放解析器。配置两个后端服务器，都出现在UDP套接字上的connect（）。在相邻的网络中得到了一个攻击机器，距离解析器4跳远，解析器有1 Gbps以太网，可以执行IP欺骗。同时，设置一个测试域，并将其托管在由作者控制的认证域名服务器上，将BIND软件的响应速率限制配置为10pps，允许五分之一的回答-有效损失率为80%。进行了20轮实验，一轮在白天，另一轮在当地时间午夜之后（如表3所示）。此外，为了了解响应速率限制对权威名称服务器的影响，作者改变了禁用级别，允许丢失率为75%、66.7%到50%——丢失率越低，攻击越困难。
作者通过在机器上施加额外的延迟、抖动和损耗来模拟更真实的网络条件。表3中给出了准确的数字，其中基线表示未修改的网络条件，其余表示模拟条件。为了应对由于模拟网络环境而增加的误报，作者在交替实验中使用了两个IP发起攻击，最后，作者为了了解参数“名称服务器禁用级别”对攻击可行性的影响，并将进行一个控制实验，改变“禁用级别”，其中所有其他参数与基线中的参数相同。
攻击过程。这个过程类似从攻击者生成询问fornonce.attacker.com的查询开始。因为解析器有两个后端服务器ip地址，所以同时在两个ip上启动端口扫描。同时，以20pps的速率对所有具有权威性的名称服务器进行禁用查询，这样解析器将经历80%的恒定丢失率。实验分别重复20次和5次。
结果分析。如表3所示，我们在第一个实验中取得了100%成功率，平均成功时间为504s。标准差是399秒，最大值是1404秒，最小值是13秒（这完全是运气使然）。平均而言，只生成69MB的攻击流量，这与转发器攻击中的情况类似，尽管解析器攻击需要更长的时间才能成功。这是因为转发器攻击更可能进入TxID 暴力模式，每次产生大约10MB的流量。转发器攻击中使用的没有二进制搜索阶段，开放端口在进入TxID 暴力攻击阶段之前简单地确认两次，其中解析器攻击中使用的二进制搜索阶段重复检查开放端口的存在。通过日志分析发现，实验一种有一个近乎完美的网络条件，发送的数据包也比转发器攻击多。这是因为冲突解决程序重试（即RTO）或攻击者发起的新查询（如果冲突解决程序恰好收到合法响应）导致源端口频繁更改，从而导致许多小而支离破碎的攻击窗口。如表3所示，基本（M）实验的设置与基本（D）相同，只是在午夜后进行，背景流量和噪声通常较低。得到同样的100%成功率和平均成功时间从504秒减少到410秒。对于表3所示的禁用级实验，除了50%的禁用级（即丢失率）外，其他所有禁用级都可以达到近乎完美的成功率，并且通常可以在一小时内完成（注意，对于66.7%的禁用级，成功的阈值为3小时）。在50%的禁用水平下，20例中只有9例成功。此外，平均耗时为8985秒或2.5小时。最后，对于交替实验，也取得了完美的100%成功率。具体来说，成功时间分别为2005s、538s、792s、1287s和29s。平均攻击时间为930秒，产生了131MB的流量。作者还发现，丢失率和抖动的增加会导致更多的误报，错误地认为发现了一个端口（因为验证数据包成功地请求了一个ICMP）。这通常是由探测包丢失引起的，这会产生两个问题：（1）在折半搜索阶段，浪费大量时间过滤这些误报，降低了有效扫描速度(2） 尽管使用了两个IP，但由于单个IP ICMP令牌的频繁释放，扫描仍然可以停止。
0x08 讨论
攻击绑定与未绑定的设备的区别。绑定攻击比未绑定攻击要困难得多，因为大多数碎片攻击窗口通常较小，因为它更不愿意将RTO增加一倍，并且具有更严格的硬停止条件. 为了了解攻击绑定解析器是否可行，作者构造了一个极端的实验，使用4个域名服务器，并在绑定解析器上设置了一个默认的等待时间为10秒的硬停止条件，导致解析器几乎总是在一个0.8秒的小攻击窗口中死机，由于查询4个名称服务器3轮已经需要9.6秒（在RTO回退开始之前），因此该实验是在SELINE的类似网络环境中进行的。作者做了两次实验，两次都成功了（一次0.54小时，另一次1.25小时）。作者发现，只扫描一个端口也能在0.8秒内注入恶意内容。一次测试显示端口扫描耗时600毫秒，恶意内容注入耗时200毫秒。
其他操作系统上的UDP源端口推断。除了Linux之外，作者还验证了Windows、FreeBSD、MacOS等主要操作系统，尽管它们全局速率限制较低，同样易受攻击。没有一个操作系统能够识别到全局速率限制的侧信道。
其他易受攻击的协议。任何基于UDP的协议都会受到源端口推断的影响。如quic、HTTP/3、VoIP、视频流和对延迟敏感的在线游戏也可能使用UDP，这会受到端口推断，甚至会受到非路径数据包注入攻击。
配置响应速率限制（RRL）的最佳实践。尽管对权威名称服务器的响应速率限制是防止DNS反射/放大攻击的一个重要措施，但如果不小心，它会允许在DNS缓存中毒攻击中扩展攻击窗口。
8.1防御措施
提出的攻击基本上是一种非路径攻击，因此可以通过额外的随机性和密码学解决方案来缓解。除了DNSSEC和0x20编码之外，还有一个被称为DNS cookie的合并功能，该功能在2016年RFC7873中标准化。在较高级别上，它要求客户端和服务器交换一些非路径攻击者未知的额外秘密；因此，它有可能击败大多数偏离路径的攻击。作者提出的攻击依赖于两个基本条件：（1）推断DNS查询的源端口(2） 扩展攻击窗口。作者讨论了如何解决这两个问题：
对于问题（1），最简单的缓解措施是完全不允许传出ICMP回复，代价可能是丢失一些网络故障排除和诊断功能。否则，需要解决全局速率限制问题。作者建议一个随机化的ICMP 全局速率限制，包括可能随机化的最大允许突发（当前50个）、每次恢复的最小令牌数（当前20个）、恢复令牌的最小空闲时间（当前20ms）和每个时间单位恢复的令牌数（当前每毫秒1个）。当侧通道被缓解时，作者也推荐解析器在其udp socket上使用connect（），这样它们的源端口就不会是面向公众的，并且可以直接扫描。
对于问题（2），作者讨论了使用RRL来防止攻击者轻易禁用权威名称服务器的最佳实践。其他简单的缓解策略包括：（1）设置DNSq查询超时，缺点是可能会引入更多的重传查询，总体性能会更差。(2） 使用任播方式。
0x09 相关工作
DNS盲伪造攻击与缓存中毒。在2008年提出的主要DNS缓存中毒攻击[之后，应用了许多防御措施，这使得这种盲目的偏离路径攻击变得更加困难。有几项研究继续研究在存在最先进防御的情况下新攻击的可行性。例如，Herzberg和Shulman提出了一种方法，通过在与解析器位于同一网络中的虚拟机的帮助下占用NAT上的所有端口（但只有一个端口），来取消NAT后面解析器的源端口的随机性，并提出了一种利用IP碎片的名称服务器钉扎方法。不幸的是，该攻击不适用于拥有公共IP地址的解析程序。Alharbi等人进行了一次类似的攻击，以耗尽clientmachine上的本地端口，并毒害了操作系统范围的DNS缓存。后来，Herzberg和Shulman的另一项工作提出了一种新的IP分段技术，用于目标解析器。这项技术消除了猜测随机源端口号、服务器地址和查询名称等的要求。Brandt等人最近的一项研究通过将ICMP碎片所需的错误消息注入权威名称服务器来主动降低MTU（相对于解析器）并引发碎片，从而放宽了限制。攻击取决于确切的服务器配置，因为许多人会简单地拒绝这样的ICMP数据包，或者维持比分割DNS响应所需的最小MTU。此外，随着时间的推移，随着越来越多的随机性引入，精确地预测IPID变得越来越具有挑战性。尽管如此，Wang等人通过使用攻击者拥有的权威名称服务器强制碎片化，开发了一种针对DNS转发器的新攻击。与以前的工作不同，作者利用了一个基于ICMP全局速率限制的通用网络侧信道，这说明了它的普遍性。此外，作者的攻击还可以完美地抵抗DNS缓存的所有层（不仅仅是解析程序）。
网络侧通道漏洞。几十年来，研究人员一直在使用网络侧通道来推断敏感的网络信息，例如端口扫描、TCP序列号推断和其他内容。在DNS源端口推断中，唯一可以归类为侧信道的工作是Herzberg和Shulman，他们建议使用低速突发数据包来重载解析程序上的特定源端口，这可能会导致以这些端口为目的地的合法DNS回复被丢弃。这会创建一个定时端通道—较长的端到端响应时间（由触发请求的恶意客户端观察）表示使用了端口，较短的时间表示未使用。由于对网络噪声的敏感性，这需要攻击者和解析器共同位于低延迟网络环境（如LAN）中。相比之下，作者的源端口扫描技术更加直接和可靠，因此可以从很远的地方进行。此外，利用网络协议中的全局速率限制作为侧信道的概念已经在一些重要的工作中得到了证明。
0x10 结论
本文提出了一种新颖的、通用的基于全局ICMP速率限制的边信道方案，该方案已被所有现代操作系统普遍采用。这允许高效扫描DNS查询中的UDP源端口。结合扩展攻击窗口的技术，它导致了DNS缓存中毒攻击的强大复兴，在真实的服务器配置和网络条件下进行了实际实验，提出了一些实际的缓解措施，可以用来提高针对这种情况的标准。
声明：本文来自安全学术圈，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
