编者按
近期OpenAI称由于遭受分布式拒绝服务攻击（DDoS）导致网络和服务器超载,使得ChatGPT周期性服务中断。攻击者需要控制多少资源才能让OpenAI强大的网络超负荷呢？事实上，有些拒绝服务的攻击者不需要控制大量僵尸节点。域名服务系统（DNS）作为一种开放的资源，常常被攻击者滥用为强大的网络攻击武器。然而，与传统利用DNS做放大攻击的方式和规模不同，本文的攻击方法可以把海量的DNS服务器级联，构造更大规模的拒绝服务攻击，我们取名为“海啸之王（TsuKing）[6]”。
本文作者为许威、陆超逸、段海新，原文为清华大学网络与信息安全实验室段海新教授团队发表在国际网络安全顶会ACM CCS 2023的研究工作：“海啸之王：协调DNS解析与查询构造拒绝服务放大攻击(TsuKing: Coordinating DNS Resolvers and Queries into Potent DoS Amplifiers)”。本文揭示了当前DNS解析服务的复杂层次结构和不遵守协议规范的现象，可以被用来发起这种新型的拒绝服务攻击，通过级联组合实现高倍率的流量放大效果，形成更加强大的网络攻击武器。
01 域名解析系统结构的复杂变迁
域名系统（DNS）是当今互联网中必不可少的基础设施，负责提供域名与IP的映射。DNS的协议标准在1987年由RFC1034 [1]和RFC1035 [2]确立，遵循“客户端-解析服务器-权威服务器”的基本解析结构。然而，经过四十年的演变，如今的域名解析结构已远比当年复杂。
“一骑红尘妃子笑，无人知是荔枝来”。唐玄宗为了让杨贵妃吃上荔枝，需要“换马不换人”式的不断在驿站之间接力以保证最快地将荔枝送到贵妃手中。时至今日，当你需要解析一个域名时，你的待遇可能并不比杨贵妃差。
图1展示了一个当下典型的多层次解析结构，包含客户端、转发器（forwarder [3]）、递归解析器、以及权威服务器。当你发起一个域名解析请求（想要“吃荔枝”）后，这条消息就从离你最近的转发器（“驿站”）出发，被层层传递给各种公共或隐藏的转发器（其他多个“驿站”）并最终到达某个递归解析器（“荔枝供应点”），由它们在权威服务器（“荔枝园”）中问询后，再原路接力将结果送到到你的手中。
图1 多层级的域名解析过程
在这条“荔枝道”的入口，你作为尊贵的杨玉环，自然不需要关心荔枝中途经过了哪里，只需要向最近的驿站发出指令即可；在“荔枝道”的出口，荔枝园也只负责提供荔枝，并不关心这份果实要给谁。类似地，尽管域名解析的路径复杂，在外界看来都对应着入口节点（ingress，即最近的转发器“驿站”）和出口节点（egress，即递归服务“荔枝供应点”）。因此，我们将中间过程看作是一个黑盒；在入口节点确定后，将它背后的解析路径中包含的所有服务器，直到出口节点，统称为一个DRS（DNS Resolver System）。一个递归解析器就是一个最小单位的DRS。
图2 DRS的构成
在万物互联的今天，任何一个联网的终端（如摄像头）都是“杨贵妃”，因为都要查询IP地址。作为互联网基础服务的域名系统（DNS），承受了巨大的解析需求。在此过程中，一些大型公共递归DNS服务开始出现。以谷歌的“8.8.8.8”为例，作为一个“荔枝供应点”想要满足来自全球的巨量需求，就需要雇佣大量的“业务员”，包括接收和分配订单的前台（frontend），以及能够独立完成“荔枝采收“的后台业务员（Backend resolvers，即直接查询权威服务器的节点）。可以说，这些公共DNS服务自身就是复杂的DRS系统。这种地址解析服务是云服务的一种（基础设施即服务IaaS），利用云计算资源的灵活资源调配能力提供了高可靠性和吞吐量。
图3 大型公共递归解析器的单个节点（e.g. Google Public DNS）
然而，能力越大、责任越大；如果这种强大的DNS服务存在安全缺陷并且被滥用，则可能给网络造成灾难性的破坏，本文所提出的海啸之王（TsuKing）是滥用云解析资源的典型案例，也是拒绝服务攻击的一种新模式。
02 什么是海啸之王（TsuKing）
海啸之王（TsuKing）由两部分构成，其中Tsu是Tsunami（海啸），代指我们能够让一个DNS解析系统（DRS）尽可能地发挥流量放大能力；而King就像它的字面意思一样，是多个DRS攻击的协调者、攻击流量的指挥者（尽管King本来是网络测量领域用DNS做测量的一种方法 [5]）。同时，考虑到TsuKing模型可能带来的流量放大影响，我们可以不太谦虚地说，我们（目前）算是基于DNS的流量放大之王（The King of Tsunami）。
TsuKing是利用了DNS解析结构的复杂性，以及一些DRS对于请求处理的不规范，来形成流量放大攻击。TsuKing的攻击将导致诸多DRS发出大量的DNS请求，或者让受害者收到巨量的DNS请求；前者造成性能上的负担，后者带来带宽上影响，最终目标都是形成DoS攻击。
图4 海啸之王（TsuKing）的两部分核心内容（左侧为Tsu，右侧为King）
1.Tsunami：重试与多后端架构所形成的放大能力
当域名解析因超时等原因失败时，DRS会自然地发起重试，这些重试是流量放大的基础。多数情况下，单台服务器重试的放大能力相对有限。但是，某些提供大规模公共解析的DNS系统结构复杂，特别是多后端架构可能加重流量放大风险：由于每次重试请求可能由不同的后端节点发出（如下图），且不同的后端节点具备独立缓存 [4]，无法对同一请求的重试进行统筹处理。
图5 有多后端的DRS使用不同后端节点进行重试
这就好比，当一个吃荔枝的需求来到供应点，第一个业务员甲（Egress #1）由于各种原因没能拿到荔枝，供应点就会再次派业务员乙（Egress #2）去。业务员甲、乙之间并不会直接联系，也不会发现他们处理的其实是同一笔订单。也就是说，在Tsunami过程中，一个荔枝订单被复制成多个订单。
2.King：请求重定向与组合调度
对DNS请求进行重定向的操作，与一款名为King的IP间时延测量工具异曲同工。如下图所示，其基本原理是：攻击者会在自己的权威服务器上动态地构造恶意响应，而这个响应是一条NS记录，致使DRS将请求转发至其他的DRS，不断地重复这个过程，就会有越来越多的DRS参与到解析中被组合在一起导致级联放大。如下图：
图6 攻击者利用多后端的重试实施组合调度
试想一下，你是一个攻击者并成立了自己的荔枝园（attacker[.]com的权威服务器）然后故意通知某个荔枝道#1（DRS#1）请求你自己品种的荔枝：
01 荔枝道#1会派业务员访问你的荔枝园（步骤①），但你却故意说这种品种的荔枝在别处，让业务员去其他某处（步骤②）。
02 这个业务员会去你所描述的地方继续访问（步骤③），但它不知道的是，那并不是一个荔枝园，而是另一个荔枝道（#2a）的入口。
03 荔枝道#1不见回复，于是派出另外一个业务员再次访问你的荔枝园（步骤④），而这一次你让业务员去又一个不同的荔枝道#2b寻找（步骤⑤）。
04 如果荔枝道#1仍不放弃，还要派出其他业务员找你，那受你蒙骗还会访问更多其他的荔枝道。
05 而荔枝道#2a、#2b，由于各自收到了来自#1的业务员请求，也会开始派人来访。重复这个过程，将使得越来越多的荔枝道开始参与进来，派出的业务员也越来越多。
在此过程中，需要额外注意一个技术细节，即对于RD标志位的处理。RD（Recursion Desired，期望递归）是DNS请求报文中的一个标记位，表明是否希望域名服务器执行递归查询：当查询报文的RD=0时，表示希望目标服务器仅在本地缓存数据中寻找并返回答案，不向外执行额外的查询。换句话说，我希望你直接给我荔枝“存货”，而不再派业务员出去。
一般地，递归域名服务器在查询权威服务器时，发送的查询报文即满足RD=0；在图6中，如果DRS#2b遵循协议规范，它在收到DRS#1请求时并不会继续执行递归查询和重试，级联放大过程失败。然而，现实的世界并不遵守理想的设计；我们通过全球的测量实验发现，约27%的开放DRS并不遵循上述规范，这为攻击者的任意级联创造了条件。
03 海啸之王攻击模型
TsuKing攻击模型将上述的两特性（能力）结合，通过灵活的处理构成流量放大攻击。具体地，我们在文章中介绍了3种攻击变种，经实验证明都具备非常可观的流量放大能力。
1.DNS重试攻击（DNSRetry）
正如我们在图5中说明的那样，互联网上部分DRS自身激进的重试已经足以形成可观的放大效果（如重试同一请求上千次），所以攻击者要做的仅仅是控制这些重试激进的荔枝供应点频繁地去受害者那里请求荔枝。我们称该攻击模型为DNS重试攻击（DNSRetry）。此攻击模型挑选重试策略非常激进的DRS，无需级联即可实现高倍率流量放大。我们的测量结果显示，约有529个开放DRS（占总数0.04%）的重试次数能够达到1K以上，最高达11万次以上（即我们向该DRS发出一个请求，在权威服务端可能收到11万以上的重复请求报文）。
图7 DNS重试攻击（DNSRetry）示意
攻击者只需要像图6中那样通过恶意的NS记录，就可以让这些激进的DRS去向受害者发送查询，而不断地重复这个过程，就可以持续对受害者造成压力。
我们在可控环境下组织了小规模下现实网络实验，展开了持续了大约12个小时的攻击，在整个实验过程中，攻击者的发送速率为1.38p/s（packets per second），受害者收到请求的平均速率为882.6p/s，流量放大638倍。
图8 DNS重试攻击（DNSRetry）实验结果
2.DNS链式攻击（DNSChain）
虽然有重试激进的DRS，但大多数的DRS的重试行为并不足以形成威胁。为了实现更大规模的放大攻击，需要借助组合协调的技术让流量实现级联放大，我们称之为DNS链式攻击（DNSChain）。此攻击模型通过级联多层DRS完成，每层都在实现重试放大，并通过攻击者的刻意重定向实现放大倍率的叠加。
和图6一致，请求在攻击者的控制下不断地向更高的层级转发，而每一轮的转发都会因为DRS的重试和多后端导致更多的DRS参与进来。当到达层级 n，会有 x 个DRS参与转发，放大能力已经足够，攻击者则控制所有 x 个DRS都向受害者转发请求，形成流量放大。最后一层的控制如图9所示，攻击者的权威服务器向所有最后一层的DRS回复的NS记录均一致，均指向受害者。
图9 DNS链式攻击(DNSChain) 最后一层攻击过程
我们组织了可控环境下的小规模现实网络实验，通过调度61个脆弱DRS，组成了一个5层长度的DNSChain。该实验持续了6个小时（如图10所示），在整个实验中，攻击者总共发送了17864个数据包（0.8p/s），而受害者总共收到了4,557,336个请求（206.4p/s）。
在我们所有的可控实验中，DNSChain所达到的最大放大倍率是使用253个脆弱DRS组成的7层DNSChain模型，达到了3702倍的放大倍率。值得注意的是，如果攻击者构造更加庞大的攻击链条，放大倍率还能上升。
图10 DNS链式攻击(DNSChain) 实验结果
3. DNS循环攻击（DNSLoop）
DNS循环攻击（DNSLoop）的攻击是在DNSChain攻击的基础上，让最后一层的请求再次转发到第一层，从而形成一个环路。一个请求被发送给环路内的任何一个DRS，都会导致该查询在环路内被永久地转发下去；当攻击者继续向环路内注入新的查询请求，整个环路内的负载会越来越重，最终导致服务器或链路的拒绝服务。该模型的攻击目标为链路中的所有DRS。
图11 DNS循环攻击(DNSLoop)
我们组织了可控环境下的小规模现实网络实验，构建了一个7层的环路，并使用我们自己的转发器（DRS#1）作为首尾衔接，以此来观察和控制环路内的流量。我们只在实验开始时通过Layer1的DRS#1发出了一个DNS的查询请求，这个请求被转发、重复、最终通过最后一层的DRS回到第一层，循环往复。图12是实验过程中我们的转发器的流量情况，可以看到整个实验直到最后人为停止，在24小时之内都一直保持着稳定的转发环路，在这其中我们的转发器总共发送了86,380个数据包（1 p/s，每2个请求为一次新的对外查询），收到了1,100,320个数据包（12.7 p/s），实验期间收到（循环）了43,190次相同的请求。
图12 DNSLoop实验首尾衔接点的流量情况
04 总结与建议
海啸之王（TsuKing）作为一种新的DNS放大攻击，它利用域名解析结构的复杂性和DRS对于RD处理的不规范，将放大能力有限的单个服务器级联组合，产生强大的放大效果。TsuKing在现实世界中具有重大而广泛的影响，在130万个开放的DRS中，约有14.5%可被利用，其中也包括一些流行的DNS软件和公共DNS服务。在我们进行反馈报告后，这些软件厂商和服务提供商给了我们积极的反馈，修复了其中的安全问题，Tsuking目前被分配了3个CVE编号。
为了应对TsuKing可能带来的威胁，我们提出了一些缓解措施。首先，DNS解析器需要遵守RD标志位的操作规范，以切断级联转发链条；其次，解析器可以通过实现负缓存和避免激进的重试操作来减轻TsuKing攻击带来的影响。对于具有多后端的解析器而言，应该优化不同后端的调度逻辑，避免在重试过程中使用多个后端。
参考文献
[1] Paul V. Mockapetris. 1987. Domain names - concepts and facilities. RFC 1034 (1987), 1–55. https://doi.org/10.17487/RFC1034
[2] Paul V. Mockapetris. 1987. Domain names - implementation and specification. RFC 1035 (1987), 1–55. https://doi.org/10.17487/RFC1035
[3] Xiaofeng Zheng, Chaoyi Lu, Jian Peng, Qiushi Yang, Dongjie Zhou, Baojun Liu, Keyu Man, Shuang Hao, Haixin Duan, and Zhiyun Qian. 2020. Poison Over Troubled Forwarders: A Cache Poisoning Attack Targeting DNS Forwarding Devices. In 29th USENIX Security Symposium, USENIX Security 2020, August 12-14, 2020, Srdjan Capkun and Franziska Roesner (Eds.). USENIX Association, 577–593. https://www.usenix.org/conference/usenixsecurity20/presentation/zheng
[4] Audrey Randall, Enze Liu, Gautam Akiwate, Ramakrishna Padmanabhan, Geoffrey M. Voelker, Stefan Savage, and Aaron Schulman. 2020. Trufflehunter: Cache Snooping Rare Domains at Large Public DNS Resolvers. In IMC ’20: ACM Internet Measurement Conference, Virtual Event, USA, October 27-29, 2020. ACM, 50–64. https://doi.org/10.1145/3419394.3423640
[5] P. Krishna Gummadi, Stefan Saroiu, and Steven D. Gribble. 2002. King: estimating latency between arbitrary internet end hosts. In Internet Measurement Workshop. ACM, 5–18.
[6] Wei Xu, xiang Li, Chaoyi Lu, Baojun Liu, Haixin Duan, Jia Zhang, Jianjun chen, Tao Wan. TsuKing: Coordinating DNS Resolvers and Queries into Potent DoS Amplifiers. ACM CCS 23. https://tsuking.net/
相关文章
头条焦点
精彩导读
关注我们
【查看完整讨论话题】 | 【用户登录】 | 【用户注册】