DDOS attack evolution: the power of UDP amplification

By Corey Nachreiner, CISSP, CTO at WatchGuard Technologies

Over the past three years, distributed denial of service (DDoS) attacks has grown significantly both in quantity and scale, breaking bandwidth records repeatedly. The most recent DDoS evolutions started in 2016 when an Internet of Things (IoT) botnet called Mirai launched a 620 Gbps DDoS attack against Krebsonsecurity.com and a 1 Tbps attack against a European hosting company (OVH). DDoS attacks of this magnitude often take out collateral victims apart from their intended target, and they’re only getting stronger.
But before IoT botnets, attackers launched record-breaking DDoS attacks using a technique called Domain Name Service (DNS) amplification or reflection. This technique uses three properties of the DNS service to force public servers to send huge amounts of traffic to unsuspecting victims. However, these three properties aren’t unique to DNS alone; they exist in many UDP-based network services, including previously lesser- known ones like Memcached. Recently, UDP amplification attacks took back the DDoS lead with the “Memcrashed” attack, during which criminals generated up to 1.7 Tbps of DDoS traffic using Memcached.
In this article, we’ll discuss the properties that make UDP-based amplification attacks possible and so effective… but first a quick technical refresher.

A quick networking and ddos primer

To understand UDP amplification attacks you first have to remember the differences between TCP and UDP traffic. At a high level, TCP traffic requires a full two-way negotiation between both devices before any real communications can begin. This negotiation is called the three-way handshake. As for DDoS attacks, this means that you can’t really spoof TCP-based DDoS attacks (with the exception of TCP negotiation attacks like SYN floods). In other words, a TCP attack usually has to come from a computer the attacker controls.
UDP, on the other hand, is a connectionless protocol. It doesn’t require a pre-negotiation, not necessarily a response from the receiving device. There are other connectionless protocols as well, such as ICMP, which have a couple of advantages for DDoS attacks that we’ll talk about later.

It also helps to understand how the security industry classifies DDoS attacks. Generally, they place attacks into three categories.

• Volume Attacks – These DDoS attacks are designed to overwhelm targets purely based on a huge deluge of network traffic. They don’t necessarily care if the target handles the traffic in any way; they simply send enough of it to disrupt all network services. UDP amplification attacks fall under this category, as do some other flooding attacks, like ICMP floods. In general, most volumetric attacks use connectionless protocols.
• Protocol Attacks – These attacks eat up the resources of critical network servers or devices (routers, firewalls, etc.) by taking advantage of different protocol-level dynamics. For example, in order to route TCP traffic, routers and firewalls have to maintain a state-table. SYN floods are a type of attack meant to fill up that state table with partially completed or “half-open” connections, so the device can’t take new connections. Other examples include The Ping of Death or Smurf attacks. Some call these “state exhaustion” attacks.
• Application Layer Attacks – These attacks concentrate on layer 7 of the OSI stack. To put it plainly, this means they focus on issues with specific applications such as web services (HTML), email (SMTP), or database services (SQL). Application layer DDoS attacks are often the hardest to recognize because they look so much like normal and legitimate traffic for that application. In some cases, application layer attacks leverage technical vulnerabilities or flaws in a specific application to slow things down or crash the server. In other cases, attackers simply send a whole lot of perfectly legitimate, but process intensive requests, such as GET and POST floods.

Unfortunately, sophisticated DDoS attackers today actually combine many of these DDoS attacks together in a single campaign. Now that we’ve covered the basics, let’s talk UDP amplification.

Dissecting reflective UDP amplification DDoS attacks
Attackers exploit many types of UDP amplification attacks that can leverage several different network services; ranging from DNS, NTP, SNMP, Memcached, and more. Though these attacks differ slightly on a technical level, they all share three common properties. They benefit from being UDP-based, they exploit network services that are commonly exposed to the public, and they offer an asymmetric scaling factor— sometimes exponentially. Let’s discuss why these three properties matter, and how they interact together.

• Leveraging UDP-based network services – Since UDP traffic is connectionless, it’s extremely easy to spoof. A hacker can simply send a UDP packet using your computer’s IP address, and since the protocol doesn’t require pre-negotiation, the recipient just accepts that packet as yours rather than the attacker’s. This spoofing offers two advantages to attackers. The first is anonymity. For example, attackers can send UDP packets directly to a victim but lie about where those packets are coming from using random source address IPs.
  The second advantage—and the more important one to UDP amplification—is to “reflect” a packet using UDP spoofing. In this case, rather than sending a packet directly to a victim, the attacker sends a packet to some third-party server but uses the victim’s IP address as the source of the packet. Since UDP is connectionless, the third-party server blindly sends its reply to the unknowing victim. This is why some experts call these attacks reflective, or UDP/DNS reflection.
• Bouncing off of public Internet services – To succeed at scale, UDP amplification attacks need public network services to take advantage of. You just learned how UDP traffic allows for spoofing, which in turn allows for reflective attacks. However, attackers need publicly accessible, third-party servers to reflect their attacks off of. Ideally, they need a lot of publicly accessible servers, because more servers can allow attackers to generate more traffic. In general, UDP amplification attacks work best with network services that are commonly found on the public Internet, which is why DNS—the most common public UDP service—was the first one to be targeted with UDP amplification attacks.
  However, DNS is not the only common public network service using UDP. After early DNS amplification attacks paved the way, DDoS attackers quickly found they could also leverage public NTP, SSDP, SNMP, TFTP, and many more UDP- based services in the same way. That said, one aspect of whether or not these UDP amplification attacks succeed is just how common a particular public UDP service is. Simply put, there are a lot of public DNS servers attackers could potentially reflect traffic off of, so they provide ample opportunity to scale a UDP attack. Meanwhile, you probably won’t find that many public Quake Network servers today, so even though that UDP service is technically vulnerable to this sort of attack, it wouldn’t generate the largest DDoS attacks.
• Offering an asymmetric scale factor – The final property in the UDP amplification equation is the asymmetric scaling factor. Simply put, this means that something in the specific protocol allows for a short request that results in a much longer reply—sometimes exponentially longer. For instance, the most common DNS amplification request involves the resource record type “ANY.”
  In a nutshell, sending a small DNS request of type ANY to an authoritative DNS server’s zone name returns a large reply containing all the records at the apex of the zone. If the server uses DNSSEC, the reply gets even bigger with keys and signatures, and other content. So, attackers can spoof and reflect a single packet that is only tens of bytes, to generate a response to the victim that is thousands of bytes. The spoofing allows reflection, and the asymmetric aspect of some protocols’ replies allow the true scale for these attacks.
  As with all other aspects of this attack, there are many UDP network services that have some sort of request/reply scaling factor. Another key factor for how bad a UDP amplification attack could be is the size of this scaling factor. Luckily, US-CERT recently released a great alert that quickly shows you the scaling factor of various UDP-based services vulnerable to these sorts of DDoS attacks. Here are a few examples:

Seeing those scaling multiples, you can probably guess why Memcached UDP amplification attacks now hold the DDoS record of 1.7 Tbps of bandwidth. If you can send a small spoofed request and get a public server to generate a reply 50 thousand times the size to anyone else on the  Internet,  it becomes trivial to eat up that victim’s bandwidth and resource.

To summarize, UDP amplification attacks succeed because UDP is spoof-able, that spoof-ability allows attackers to reflect requests off common public servers to unknowing victims, and some UDP services allow for tiny requests that generate exponentially large replies. While each of these UDP services has slightly different request characteristics, all UDP amplification attacks essentially prey on these three issues combined together.

Defense against UDP amplification attacks
Protection is a little more difficult to describe because some protections require broader industry participation. From a DDoS victim’s perspective, there is little one can do to avoid reflective UDP amplification attacks. As a starting point, you should adopt some sort of DDoS protection service that scrubs your traffic upstream.
For organizations that might expose public UDP services to the world, you should definitely be aware of these attacks, and which services are vulnerable to them. The US-CERT’s alert is a good resource for understanding the services you should know about. However, hardening your public servers against these attacks differs depending on the protocol. A general tip here is to avoid exposing any protocol features that are unnecessary or at least limit them to a specific access list.
Finally, there is something all network owners (most importantly, ISPs) can do to really nip amplification attacks in the bud: block spoofing at a network layer. Ultimately, UDP amplification attacks hinge on the ability to spoof traffic from others. If attackers can’t spoof traffic, they can’t reflect attacks to a victim. It’s trivial for network perimeter devices to detect spoofing. You know what IP address space you own. If your gateway device sees traffic coming from your network, claiming to be an IP you don’t own, you should block it. In fact, IETF has a published best practice (BCP 38) that specifically outlines how ISPs and network owners can and should block all spoofing at their perimeter. If the industry as a whole adopted this, UDP amplification would fade into history.
This won’t be the end of huge DDoS attacks. Between botnets – IoT or otherwise – and organizations that don’t follow best practices, these attacks will continue to evolve. Rather than being part of the problem, you can help drive us all toward the solution by making sure to implement anti-spoofing features on your gateway devices, and asking your ISP if they’re doing the same.

About the Author

Corey Nachriener

Recognized as a thought leader in IT security, Nachreiner spearheads WatchGuard’s technology vision and direction. Previously, he was the director of strategy and research at WatchGuard. Nachreiner has operated at the frontline of cyber security for 16 years, and for nearly a decade has been evaluating and making accurate predictions about information security trends. As an authority on network security and internationally quoted commentator, Nachreiner’s expertise and ability to dissect complex security topics make him a sought- after speaker at forums such as Gartner, Infosec and RSA. He is also a regular contributor to leading publications including CNET, Dark Reading, eWeek, Help Net Security, Information Week and Infosecurity, and delivers WatchGuard’s “Daily Security Byte” video on Facebook.