Threat Advisory | UDP-Based Amplification Attacks

August 20, 2015

Original release date by US Cert: January 17, 2014 | Last revised: August 19, 2015

A Distributed Reflective Denial of Service (DRDoS) attack is a form of Distributed Denial of Service (DDoS) that relies on the use of publicly accessible UDP servers, as well as bandwidth amplification factors, to overwhelm a victim system with UDP traffic.

UDP, by design, is a connection-less protocol that does not validate source IP addresses. Unless the application-layer protocol uses countermeasures such as session initiation, it is very easy to forge the IP packet datagram to include an arbitrary source IP address [1]. When many UDP packets have their source IP address forged to a single address, the server responds to that victim, creating a reflected Denial of Service (DoS) Attack.

Recently, certain UDP protocols have been found to have particular responses to certain commands that are much larger than the initial request. Previously, attackers were limited linearly by the number of packets directly sent to the target to conduct a DoS attack; now a single packet can generate tens or hundreds of times the bandwidth in its response. This is called an amplification attack, and when combined with a reflective DoS attack on a large scale, DDoS attacks can be conducted with relative ease.

Certain UDP protocols have been identified as potential attack vectors:

• DNS
• NTP
• SNMPv2
• NetBIOS
• SSDP
• CharGEN
• QOTD
• BitTorrent
• Kad
• Quake Network Protocol
• Steam Protocol
• RIPv1
• Multicast DNS (mDNS)
• Portmap

To measure the potential effect of an amplification attack, a metric called the bandwidth amplification factor (BAF) is used. BAF can be calculated as 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 [2] [3].

The list of known protocols—and their associated bandwidth amplification factors—were featured on US Cert and are listed below.

Protocol	Bandwidth	Vulnerable Command
DNS	28 to 54	see: TA13-088A [4]
NTP	556.9	see: TA14-013A [5]
SNMPv2	6.3	GetBulk request
NetBIOS	3.8	Name resolution
SSDP	30.8	SEARCH request
CharGEN	358.8	Character generation request
QOTD	140.3	Quote request
BitTorrent	3.8	File search
Kad	16.3	Peer list exchange
Quake Network Protocol	63.9	Server info exchange
Steam Protocol	5.5	Server info exchange
Multicast DNS (mDNS)	2 to 10	Unicast query
RIPv1	131.24	Malformed request
Portmap (RPCbind)	7 to 28	Malformed request

Attackers can utilize the bandwidth and relative trust of large servers that provide the above UDP protocols to flood victims with unwanted traffic, a DDoS attack.

DETECTION

Detection of DRDoS attacks is not easy because of their use of large, trusted servers that provide UDP services. Network operators of these exploitable services may apply traditional DoS mitigation techniques. In addition, watch out for abnormally large responses to a particular IP address, which may indicate that an attacker is using the service to conduct a DRDoS attack.

MITIGATION

Source IP Verification

Because the UDP requests being sent by the attacker-controlled clients must have a source IP address spoofed to appear as the victim’s IP, the first step to reducing the effectiveness of UDP amplification is for Internet service providers (ISPs) to reject any UDP traffic with spoofed addresses. The Network Working Group of the Internet Engineering Task Force (IETF) released Best Current Practice 38 in May 2000 and Best Current Practice 84 in March 2004. These documents describe how an ISP can filter network traffic on their network to reject packets with source addresses not reachable via the actual packet’s path [9] [10]. Recommended changes would cause a routing device to evaluate whether it is possible to reach the source IP address of the packet via the interface that transmitted the packet. If it is not possible, then the packet most likely has a spoofed source IP address. This configuration change would substantially reduce the potential for many popular types of DDoS attacks. As such, we highly recommend that all network operators perform network ingress filtering if possible. Note that such filtering will not explicitly protect a UDP service provider from being exploited in a DRDoS because all network providers must use ingress filtering to eliminate the threat completely.

To verify your network has implemented ingress filtering, we recommend downloading the open source tools from the Spoofer Project [11].

Traffic Shaping

Limiting responses to UDP requests is another potential mitigation to this issue. This may require testing to discover the optimal limit that does not interfere with legitimate traffic. The IETF released Request for Comment 2475 and Request for Comment 3260 that describe some methods to shape and control traffic [12] [13]. Most network devices today provide these functions in their software.

REFERENCES FROM U.S CERT POSTING

• [1] SIP: Session Initiation Protocol
• [2] Amplification Hell: Abusing Network Protocols for DDoS (link is external)
• [3] Amplification Hell: Revisiting Network Protocols for DDoS Abuse (link is external)
• [4] DNS Amplification Attacks
• [5] NTP Amplification Attacks Using CVE-2013-5211
• [6] VU#550620: Multicast DNS (mDNS) implementations may respond to unicast queries originating outside the local link
• [7] RIPv1 Reflection DDoS [Medium Risk] (link is external)
• [8] A New New DDoS Reflection Attack: Portmapper; An Early Warning to the Industry (link is external)
• [9] Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing
• [10] Ingress Filtering for Multihomed Networks
• [11] The Spoofer Project
• [12] An Architecture for Differentiated Services
• [13] New Terminology and Clarifications for Diffserv

Herjavec Group circulates US – Cert advisories as this notification warrants attention and may have significance to your Enterprise network environment. If the following advisory is applicable to your environment, Herjavec Group recommends your IT team review the technical details included and monitor your environment for any susceptible systems. Herjavec Group’s analysts are working with applicable vendor partners to apply detection and mitigration strategies where appropriate. For Managed Services customers, our Managed Services team will engage with the appropriate technical contacts in your respective organizations directly to provide alerts, escalations, actions and or reports based our service agreement with you. If you have questions or concerns, please engage your Herjavec Group account representative directly or contact Herjavec Group.