UDP-based amplification — the dangerous DDoS attack vector

Last month, Akamai, a popular Content Delivery Network (CDN) service provider, disclosed it had recently blocked the world’s largest Distributed Denial-of-Service (DDoS) attack. According to the report, the record-breaking attack occurred on 21 July 2022, peaking at 853.7 gigabits per second (Gbps) and 659.6 million packets per second (Mpps).

User Datagram Protocol (UDP) was the most popular vector used in the attack and appeared in the record spikes.

In this post, I will review a few common UDP-based DDoS attack vectors that I have tested in a lab environment, along with mitigation best practices. I will discuss how a vulnerable program can crash/terminate service as well as how an attacker can abuse UDP to generate Denial-of-Service (DoS) traffic and amplify the traffic, which will redirect to a victim by spoofing the originator’s IP address.

How DDoS attacks work

A DoS attack is where a malicious cyber threat actor tries to shut down a machine/device/network and make it inaccessible to its intended users by interrupting its normal functionalities and capabilities. A DoS condition is performed by flooding the targeted host or network with traffic until the target cannot respond or crashes, preventing access for legitimate users.

A DoS attack is characterized by using a single computer to launch the attack. A DDoS attack is a type of DoS attack that comes from many distributed sources, such as a botnet DDoS attack.

There are two types of notable DDoS attacks: Reflection attacks and amplification attacks.

In a reflection attack, the attacker spoofs a victim’s IP address and sends a request for information (primarily using UDP) to a server. The server then responds to the request that sends an answer to the victim’s IP address. This ‘reflection’ — using the same protocol in both directions — is why this is called a reflection attack.

An amplification attack is a kind of reflection attack, where the attacker sends a small request with a spoofed source IP address to a server and then the server responds to the victim with a larger/amplified response. By using this amplification, an attacker can use fewer resources to attack a large target; the higher the amplification factor, the fewer resources the attacker needs.

A reflection/amplification combination attack enables attackers to magnify the amount of malicious traffic they can generate and produce more devastating results. These types of DDoS attacks mostly rely on millions of exposed DNS, Network Time Protocol (NTP), and other UDP/TCP-based services.

The Bandwidth Amplification Factor (BAF) computes the bandwidth multiplier in terms of the number of UDP payload bytes that an amplifier sends to answer a request, compared to the number of UDP-payload bytes of the request. The related BAF for the DNS protocol is 28 – 54 and the NTP protocol is 556.9.

Crash the service or make a DoS condition with a known exploit

NTP is an Internet protocol used to synchronize computer clock time sources in a network. It relies on UDP’s port 123.

According to CVE-2016-7434 and ntp.org, the read_mru_list function in NTP before 4.2.8p9 allows remote attackers to cause a DoS crash via a crafted mrulist query. If NTP daemon (NTPd) is configured to allow mrulist query requests from a server that sends a crafted malicious packet, NTPd will crash on receipt of that crafted malicious mrulist query packet.

For example, in the following scenario, the victim’s machine runs a vulnerable version of the program (ntp-4.2.8p8) and the attacker sends a crafted malicious packet that causes the program to crash or terminate the services. The victim’s server (lab IP address: 192.168.85.133) enables the vulnerable version of the NTP service (Figure 1):

Now, the attacker (lab IP address: 192.168.85.130) uses the exploit code CVE-2016-7434 and tries to crash the service (Figure 2):

This terminates the NTP service on the victim’s machine (Figure 3):

From this scenario, we understand the importance of patching — in the absence of proper patching, an attacker can exploit the vulnerable services and can make DoS conditions (service is inaccessible to its intended users).

Recommendation: Always use updated software versions and perform proper patching.

NTP amplification attacks using CVE-2013-5211

Another type of NTP amplification attack, as per CVE-2013-5211, involves an attacker exploiting the ‘monlist’ feature on some NTP servers. In this attack, an attacker can multiply their initial request traffic, resulting in a large response.

The monlist request from a server with 600 addresses in its memory will be 206 times larger than the initial request. This means that an attacker with 1 GB of Internet traffic can deliver a 200+ GB attack — a massive increase in the resulting attack traffic.

We can detect NTP monlist vulnerabilities by using a Nmap Scripting Engine (NSE) script named ntp-monlist. For example, in our lab, we tried to send the MON_GETLIST request to the NTP server using nmap (Figure 4):

If the server responds to this request with MON_GETLIST and the size of each data item in the packet is equal to 0x48 (72 in decimal), then this implies that the monlist feature is enabled and the vulnerability is present, as shown in Figure 5.

If we analyze the captured packet from the victim (Figure 6), we can see that the MON_GETLIST request packet length is 92 bytes (in frame 19) compared to the amplified response (484 bytes) that was generated by the victim’s server (in frame 20).

Recommendation:

Upgrade all versions of NTPd that are publicly accessible to at least 4.2.7. If upgrading is not possible, follow US-CERT’s instructions and/or check and follow Team Cymru’s Secure NTP Template.

NTP amplification attacks using the readvar command

NTP ‘readvar’ is a control message command that when executed, returns a list of configuration system variables from an NTPd. This response size may reach 30 times (30x amplification) that of the source.

To detect this vulnerability, we can use the below command:

ntpq -c readvar [IP address]

Let’s analyze the packet capture of this query execution and response in Figure 7:

From the packet capture, this is clearly shown the ntpq -c readvar query size was 54 bytes and when the server responds with this query, the packet size becomes 442 bytes, which is eight times bigger/amplified than the initial query size.

Recommendation: Disabling this feature may help to reduce the likelihood of this vulnerability taking place. Also, we can check with the vendor for an upgrade to a fixed version.

See ntp.org for further instructions for restricting readvar. 

UDP fragmentation attack

An attacker may execute a UDP fragmentation attack against a target server to consume resources such as bandwidth and CPU. Using a tool like Scapy, we can generate a UDP fragmentation or Nestea attack like so:

send(IP(dst="192.168.85.133", id=42, flags="MF")/UDP()/("X"*10))
send(IP(dst="192.168.85.133", id=42, frag=48)/("X"*116))
send(IP(dst="192.168.85.133", id=42, flags="MF")/UDP()/("X"*224))

Note: The send() function will send packets at Layer 3 to the destination IP address (DST) field, which equals the victim’s IP (192.168.85.133) with the identification (id) set at 42, and the more fragments (MF) flag set along with UDP protocol and payload. The related packet capture from the victim is shown in Figure 8.

If the attacker sends a large number of fragmented UDP packets, the victim machine will process these, which will consume CPU resources as well as network bandwidth and may generate a DoS condition.

Recommendation: 

The most common method for mitigating this attack is by:

• Inspecting incoming packets for violations of fragmentation rules using a router
• Using a secured proxy server, firewalls, or intrusion detection systems
• Ensuring that any packet which violates the rules should never reach its target

Also, make sure the operating system is up to date and has all the latest security patches installed.

See CAPEC-495: UDP Fragmentation for OS level technical mitigation recommendations.

DNS amplification attacks

A DNS amplification attack is a popular form of DDoS, in which attackers use publicly accessible open DNS servers to flood a target system with DNS response traffic.

To do so, an attacker sends requests to open DNS resolvers with a spoofed IP address. The DNS responds with the query, and then the target receives a response from the DNS resolvers. In most of these types of attacks observed by US-CERT, the spoofed queries sent by the attacker are of the type, ‘ANY’, which returns all known information about a DNS zone in a single request. Because the size of the response is considerably larger than the request, the attacker can increase the amount of traffic directed to the victim. As a result, the target receives an amplification of the attacker’s initial traffic, and their network becomes congested with this type of traffic, finally causing a DoS.

In our lab environment (Figure 9), we created a scenario where the attacker sends a DNS query to a misconfigured open resolver with a spoof IP address. The misconfigured open resolver responds with the attacker’s DNS query and the ‘amplified response’ is sent to the victim’s spoofed IP address.

We used the following Scapy command to complete this DNS amplification attack (Figure 10):

send(IP(src="192.168.85.152",dst="192.168.85.142")/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname="www.apnic.net",qtype=255)),loop=1)

Note: ‘src’ is the source IP address, in this case, the victim IP address that has been spoofed. The DST is the IP address of the misconfigured open resolver, and the query type will use UDP on destination port (dport) 53. The qytpe value 255 is equivalent to ‘ANY’ and so returns all records of all types known to the nameserver, which makes the response bigger than the request. Setting loop=1 means this will go on endlessly until it crashes.

Figure 11 shows the DNS traffic we captured from the victim’s machine.

By analyzing the captured packet from the victim machine (Figure 12), we can see that the request packet length is 73 bytes and the server’s response is 224 bytes.

Recommendation: Unfortunately, due to the massive traffic volume that can be produced by one of these attacks, there is often little that the victim can do to counter a large-scale DNS amplification-based DDoS attack. However, it is possible to reduce the number of servers that an attacker can use to generate the traffic volumes by:

1. Source IP verification — the first step to reducing the effectiveness of DNS amplification is for Internet Service Providers to reject any DNS traffic with spoofed addresses. Enterprise networks can also take this step to stop spoofed packets from leaving their network.
2. Reducing the total number of open DNS resolvers — ideally, DNS resolvers should only provide their services to devices that originate within a trusted domain. Restricting a DNS resolver so that it will only respond to queries from trusted sources.

See the Cybersecurity & Infrastructure Security Agency alert (TA13-088A) for more details.

Debashis Pal is an Information Security Specialist from Bangladesh.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.