Report: New DNS-based Pulsing DoS Attack (DNSBomb) of BIND

Quick Links	🔗
Incident Manager:	@tkrizek
Deputy Incident Manager:	@ebf
Public Disclosure Date:	YYYY-MM-DD
CVSS Score:	TBD
Security Advisory:	TBD
Mattermost Channel:	CVE-YYYY-NNNN: DNSBomb
Support Ticket:	N/A
Release Checklist:	TBD

💡 Click here (internal resource) for general information about the security incident handling process.

Earlier Than T-5

At T-5

🔗 (Marketing) Update the text on the T-5 (from the Printing Press project) and "earliest" ASN documents in the SF portal
🔗 (Marketing) (BIND 9 only) Update the BIND -S information document in SF with download links to the new versions
🔗 (Marketing) Bulk email eligible customers to check the SF portal
🔗 (Marketing) (BIND 9 only) Send a pre-announcement email to the bind-announce mailing list to alert users that the upcoming release will include security fixes

At T-1

🔗 (First IM) Send notifications to OS packagers

On the Day of Public Disclosure

After Public Disclosure

🔗 (QA) Merge a regression test reproducing the bug into all affected (and still maintained) branches

Report: New DNS-based Pulsing DoS Attack (DNSBomb)

By Xiang Li [1] from Network and Information Security Laboratory, Tsinghua University [2]

Paper - confidential

dnsbomb-li-sp14summer.pdf

Overview

We found a new DNS vulnerability that can be exploited to perform a new pulsing DoS attack, named the DNSBomb attack.

DNSBomb exploits multiple widely-implemented DNS mechanisms to accumulate DNS queries that are sent at a low rate, amplify queries into large-sized responses, and concentrate all DNS responses into a short, high-volume periodic pulsing burst to simultaneously overwhelm target systems.

The effects of an exploit would be widespread and highly impactful, as our small-scale experiments show that the peak pulse magnitude can approach 8.7Gb/s and the bandwidth amplification factor can exceed 20,000x. Besides, DNSBomb conforms to defacto DNS specifications and best practices and exploits current mitigation patches of "birthday paradox"-based DNS cache poisoning attacks.

Pulsing DoS Attack

Figure 1. Concept of the Pulsing DoS Attack.

Traditional DoS attacks function by continuously flooding a target with superfluous requests, exhausting the available resources. Such classic hyper-volumetric DoS attacks, however, are simple to detect due to continual high volume of traffic.

To make DoS attacks more covert and effective, consequently, Kuzmanovic and Knightly first proposed the Pulsing DoS (PDoS) attack in 2003 [3]. Unlike its continuous counterpart, a PDoS attack is characterized by intermittent traffic bursts aimed at periodically overwhelming the target and a low average traffic rate during the period. This pulsating approach is analogous to a pulse beat, which resonates at the target’s weakest points, causing perturbations that can lead to temporary or even permanent system failure.

As shown on the right of Figure 1, the PDoS attack differs from traditional traffic flooding attacks that send the attacking traffic continuously by constructing the traffic pulse with a magnitude of M and lasting a time window of W at a period of P.

Previous pulsing attacks leveraged latency-based methods to concentrate traffic. However, these PDoS attacks either yield a small amplification factor (e.g., 10 of [4]) or require a large pulse period (1,800s of [5]), neither of which are practical and powerful enough to apply.

Vulnerability Details

We find that the inherent availability-guaranteeing, security-protecting, and reliability-enhancing DNS mechanisms can be exploited to accumulate, amplify, and concentrate attack traffic with a much larger time window. All of these features contribute to the presence of the DNSBomb vulnerability.

Specifically, first, we employ the availability-guaranteeing DNS mechanism timeout to ensure a long period for accumulating queries, e.g., between 1s and 15s, which is greater than the maximum path latency. Second, by leveraging the security-protecting DNS mechanism query aggregation on the same domain, we can amplify a small-sized DNS query packet into a large-sized response packet with minimal overload (only one query will be sent to the authoritative server). Third, by delicately delaying the response, we are able to manipulate resolvers to simultaneously return all responses with the reliability-enhancing DNS mechanism response fast-returning.

Rather than leveraging different query path latencies of global DNS resolvers, DNSBomb delicately combines both DNS queries and responses with multiple operational DNS resolution mechanisms and could achieve a bandwidth amplification factor of over 20K.

Inherently, we demonstrate that the availability-guaranteeing, security-protecting, and reliability-enhancing DNS mechanisms can be exploited to accumulate, amplify, and concentrate attack traffic.

We find that the combination of DNS query and response opens long-overlooked attack surfaces to launch new practical-and-powerful PDoS attacks. Especially, the timeout and fast-returning mechanisms provide sufficient time to accumulate attack traffic fast.

DNSBomb Attack

Figure 2. Threat Model of the DNSBomb Attack.

As illustrated in Figure 2, there are three critical steps to construct the DNSBomb attack: accumulating DNS queries (step ➀), amplifying DNS queries into responses (step ➁), and concentrating DNS responses to the target (step ➂).

The core concept of the DNSBomb attack is analogous to Goku’s signature Kamehameha technique (a blast wave attack) in the Dragon Ball series [6]. The Kamehameha is formed when cupped hands are drawn to the user’s side to gather energy (step ➀: Ka-me) and the energy is enhanced into a large force ball between cupped hands (step ➁: Ha-me). The hands are then thrust forward in order to release a streaming, powerful beam of energy (step ➂: HA!!!).

Similarly, DNSBomb first accumulates sufficient DNS queries to collect bomb energy (Ka-me), then amplifies each query into a larger response for enhancing energy (Ha-me), and finally concentrates them into a powerful missile of energy directed at the target server (HA!!!).

Since attackers can control the accumulating time to collect enough traffic (bomb countdown) and cause concentrated traffic to explode like a bomb, we refer to our newly proposed PDoS attack as the DNSBomb attack.

➀ Ka-me: Accumulating DNS Queries. The first phase is accumulating as many DNS queries as possible at a very low rate on the exploitable resolver before responses returning (step ❶). To achieve this goal, we employ the availability-guaranteeing DNS mechanism timeout to ensure a long period for sending queries. The timeout window, for instance, can range from hundreds of milliseconds to tens of seconds, allowing for enough accumulating time. Furthermore, we will show how the IP defragmentation timeout mechanism can be integrated to increase the accumulating time.

➁ Ha-me: Amplifying DNS Queries into Responses. The second phase is to amplify a small DNS query packet into a larger response packet (step ❷). To accomplish this, we use our controlled domain and return large-sized responses in accordance with the resolver’s capability. In addition, by exploiting the security-protecting DNS mechanism query aggregation on the same domain name, we significantly reduce our nameserver’s overload from tens of thousands of accumulated queries to just a few (or even one) queries.

➂ HA!!!: Concentrating DNS Responses. After accumulating numerous queries and amplifying them into larger responses, in the third phase, by delicately holding responses until nearing timeout in our own nameserver (step ❸), we can manipulate resolvers to simultaneously return all responses corresponding to each query (step ❹). Specifically, due to the reliability-enhancing DNS mechanism response fast-returning that the packet should be transmitted as soon as possible, all responses will be concentrated and then sent to the target server in a short amount of time, producing a powerful pulsing DoS traffic.

Threat Surface

Table 1. Software and tested attack features.

Software	Version
BIND	All versions are vulnerable
`Query rate-limit`	130
`Query timeout`	10s
`Number of queries to Auth.`	6
`Max. response size to client`	1,232B
`1k-response-returning time`	8ms

To demonstrate the attack result, we analyzed and tested several attack features that impact the DNSBomb attack, including:

Query rate-limit: the number of client queries that can be accumulated. If more queries can be accumulated, the pulsing traffic will be large.
Query timeout: the time that these queries are accumulated. If the timeout is large, this means that attackers can send packets as a low rate by distributing packets among the timeout period.
Number of queries to Auth.: the number of queries sent to the authoritative server. If the number is small, this means that the attacker's cost of receiving traffic on the nameserver side can be minimal.
Max. response size to client: the size of a response sent to the client. If the size is large, the pulsing traffic will be large.
1k-response-returning time: the time used by the resolver to returning 1k response to the client. If the time is small or the returning speed is fast, the pulsing magnitude will be high.

PoC

In this test, we performed the DNSBomb attack in the following steps and settings.

We installed tested software on local machines and all of them are linked to a local network with a 10Gb/s network bandwidth.

Step 1: We send 1k queries to the tested resolver for one same domain and distribute the 1k queries among the Query timeout period.
Step 2: Upon receiving the first query, the resolver will request our own nameserver for responses. The number of request is only Number of queries to Auth..
Step 3: The nameserver holds the query from the resolver until nearing the Query timeout and returns a large-sized response according to the Max. response size value.
Step 4: After receiving the response, the resolver will return all 1k response to the client within the 1k-response-returning time.

Then we calculated the traffic bandwidth of attacker-side (the query we sent to the resolver) and victim-side (the response the resolver sent to the client). The amplification factor is traffic bandwidth of victim-side/traffic bandwidth of attacker-side.

The exploitation result is shown in Table 2.

Table 2. DNSBomb experiment results (We use a 10ms time window to calculate the network bandwidth.).

Software	Victim-side	Attacker-side	Amplification factor
BIND	140.6Kb/s	92.5Mb/s	673.9x

The attack traffic flow is showed in Figure 3.

Figure 3. Traffic flow under the DNSBomb Attack.

Real-world Impact

Figure 4. DNSBomb Attack Results on Different Servers.

We conducted controlled real-world experiments to evaluate how the DNSBomb attack DoS target servers or degrade the RoQ of services. First, we measure the network bandwidth occupation of DNSBomb, then use it to attack three types of servers, including a DNS resolver and HTTP/2- and HTTP/3-based websites.

Figure 4a shows that the normal bandwidth decreases from 958.8Mb/s to 0.0b/s when the pulsing traffic arrives at the 10s and lasts for about 50ms.
Results in Figure 4b indicate that the usual query latency ranges from 50 to 250ms and does not exceed 750ms. Under the DNSBomb attack, however, the client can never receive a valid response (1s latency).
Figure 4c displays that the normal HTTP request time cost is only less than 3ms. Once the DNSBomb pulsing traffic arrives, the request response from TCP port 80 (under attack) is returned at a cost of over 750ms or is lost entirely.
As illustrated in Figure 4d, when the pulsing traffic occurs, the request response increases by 2,000% from 2ms to 41ms.

We also demonstrated the attack impact in GEEKCON 2023 and exploited it to DoS a livestream server. Results showed that the users could hardly watch a fluent live.

Note: we did not disclose the software name or vendor name to keep it from being exploited. We just said that one anonymous software was being leveraged. What we did after found this vulnerability is try report it to affected vendors.

Mitigation

The DNSBomb attack is made possible by the inherent DNS resolution mechanisms for guaranteeing availability, protecting security, and enhancing reliability, instead of a classic vulnerability. Therefore, to mitigate DNSBomb, vendors have to compromise by reducing some resolution performance and standardize their implementations. Specifically:

The Query rate-limit should also be restricted to a small value such as AdGuard’s 100.
The Query timeout should be reduced to a modest value like Google’s 1.5s.
The Max. response size to client should be standardized to 1,232B.
The Response-returning speed should be small or equal to the Query timeout (that will degrade the performance).
The resolver should return some error messages in advance before receiving the response from the nameserver instead of accumulating more queries.

To demonstrate the effect of our recommended mitigation solutions, against one anonymous software, we conduct 6 experiments with different restrictions, including the base (no restrictions with 1,000 queries as before), Query rate-limit set to 1s, Query rate-limit set to 100, Max. response size to client set to 1,232B, 1k-response-returning time set to Query timeout, and all restrictions set.

Results in Table 3 indicate that the response time restriction has the best defensive effect, since it is the key to concentrating responses. In contrast, the Query rate-limit restriction is the worst (attackers could coordinate more resolvers or different queried domains). Additionally, the Query timeout and Max. response size to client restrictions can reduce the amplification factor to some degree.

Table 3. DNSBomb amplification factors under different mitigation solutions.

Software	Base	Timeout	Rate-limit	Pkt. Size	Res. Time	All
BIND	673.9x	122.5x	1,347.8x	673.9x	13.5x	47.2x

Reference

[1] Xiang Li's homepage: https://lixiang521.com/.

[2] Network and Information Security Laboratory, Tsinghua University. https://netsec.ccert.edu.cn/

[3] Aleksandar Kuzmanovic and Edward W Knightly. Low-Rate TCP-Targeted Denial of Service Attacks: The Shrew vs. the Mice and Elephants. In Proceedings of the 2003 Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and protocols for computer communication (SIGCOMM '03), 2003.

[4] Ryan Rasti, Mukul Murthy, Nicholas Weaver, and Vern Paxson. Temporal Lensing and Its Application in Pulsing Denial-of-Service Attacks. In Proceedings of 2015 IEEE Symposium on Security and Privacy (S&P '15), 2015.

[5] Run Guo, Jianjun Chen, Yihang Wang, Keran Mu, Baojun Liu, Xiang Li, Chao Zhang, Haixin Duan, and Jianping Wu. Temporal CDN-Convex Lens: A CDN-Assisted Practical Pulsing DDoS Attack. In Proceedings of the 32nd USENIX Security Symposium (USENIX Security '23), 2023.

[6] Fandom. Dragon Ball Wiki. https://dragonball.fandom.com/wiki/Kamehameha, 2023.

Report_-New_DNS-based_Pulsing_DoS_Attack-_BIND.pdf

Edited Feb 26, 2024 by Petr Špaček

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information