TA14-017A:UDP-Based Amplification Attacks

Original release date: January 17, 2014 | Last revised: April 13, 2016
Systems Affected
Certain application-layer protocols that rely on User Datagram Protocol (UDP)
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/RPC
Overview
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.

Description
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 in VOIP (voice over IP), 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 the victim IP address, the
destination server (or amplifier) responds to the victim (instead of the
attacker), 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 using multiple amplifiers and targeting a single victim, DDoS
attacks can be conducted with relative ease.

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—are listed below. US-CERT offers thanks to Christian Rossow for
providing this information. For more information on bandwidth amplification
factors, please see Christian's blog and associated research paper.

Protocol Bandwidth Amplification Factor 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

In March 2015, Software Engineering Institute CERT issued Vulnerability Note
(VU#550620) describing the use of mDNS in DRDoS attacks. Attackers can
leverage mDNS by sending more information than can be handled by the device,
thereby causing a DoS. [6]

In July 2015, Akamai Technologies' Prolexic Security Engineering and Research
Team (PLXsert) issued a threat advisory describing a surge in DRDoS attacks
using the Routing Information Protocol version one (RIPv1). Malicious actors
are leveraging the behavior of RIPv1 for DDoS reflection through specially
crafted request queries [7].

In August 2015, Level 3 Threat Research Labs reported a new form of DRDoS
attack that uses portmap.  Attackers leverage the behavior of the portmap
service through spoofed requests and flood a victim’s network with UDP
traffic. [8]

Impact
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.

Solution
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. To detect a DRDOS
attack, watch out for abnormally large responses to a particular IP address,
which may indicate that an attacker is using the service.

If you are a victim of DRDoS attack, there are a few things you can do to
detect such activity and respond:

Detect and alert large UDP packets to higher order ports.
Detect and alert on any non-stateful UDP packets. (A simple snort example is
below. You will need to customize this approach to your environment with
whitelist and known services.) Simple Snort rule example for stateless UDP
check
var HOME_NET [10.10.10.20]
preprocessor stream5_global: track_ip yes, track_tcp yes,track_udp
yes,track_icmp no,max_tcp 262144, max_udp 131072
preprocessor stream5_ip: timeout 180
preprocessor stream5_tcp: policy first, use_static_footprint_sizes
preprocessor stream5_udp: timeout 180, ignore_any_rules
alert udp HOME_NET 1024: -> any any (msg:"UDP Session start"; fl
wbits:set,logged_in; flowbits:noalert; sid: 1001;)
alert udp any any -> HOME_NET 1024: (msg:"UDP Stateless"; flowbi
s:isnotset,logged_in; sid: 1002)

If you are an upstream provider maintain updated contacts and methods with
downstream customers to send alerts by network.
In general, network and server administrators for Internet service providers
(ISPs) should use the following best practices to avoid becoming amplifier
nodes:

Detect spoofed packets using network flow. (In order to validate before
blocking it, read more in the Mitigation section on blocking spoofed traffic.)
Monitor for an unusual number of requests to UDP services at risk using
network flow or other summarized network data.
Use network flow to detect service anomalies (bytes-per-packet, 
ackets-per-second anomalies).
MITIGATION
If you are a victim of DRDoS attack there are a few things you can do to
mitigate this attack:

Use stateful UDP inspection to reduce impact on critical services on your
border firewall or border router (like reflexive ACL [9])
Using Border Gateway Protocol (BGP), create a Remotely Triggered Blackhole,
preferably in coordination with your upstream provider or ISP. [10]
Maintain a list of primary upstream provider emergency contacts to coordinate
response to the attack. If you are an upstream provider, conduct mitigation in
coordination with your downstream customers.
In general, network and server administrators for Internet service providers
(ISPs) should use the following as best practices to avoid becoming amplifier
nodes:

Keep your software and configuration up to date to deny or limit abuse (e.g.,
DNS response rate limit [11] [12] [13])
Disable and remove unwanted services or deny access to local services over the
Internet.
Enable network-based rate-limiting to legitimate services you provide over the
Internet using UDP-based protocols (e.g., quality of service (QoS) on
switching and routing devices)
Work with Customer Provider Edge manufactures for secure configuration and
software [14]
As a service provider, to avoid any misuse of Internet resources

Block spoofed packets by using ingress filtering (the Spoofer Project [15] and
IETF BCP 28 and BCP 39 guidelines [16])
Use traffic shaping on UDP service requests to ensure repeated access to
over-the-internet resources is not abusive.[17] [18]
References
[1] SIP: Session Initiation Protocol
[2] Amplification Hell: Abusing Network Protocols for DDoS
[3] Ampli?cation Hell: Revisiting Network Protocols for DDoS Abuse
[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]
[8] A New DDoS Reflection Attack: Portmapper; An Early Warning to the Industry
[9] Configuring IP Session Filtering (Reflexive Access Lists)
[10] Remotely-Triggered Black Hole (RTBH) Routing
[11] A Quick Introduction to Response Rate Limiting
[12] Network Ingress Filtering: Defeating Denial of Service Attacks Which
Employ IP Source Address Spoofing
[13] Ingress Filtering for Multihomed Networks
[14] Abuse of Customer Premise Equipment and Recommended Actions
[15] The Spoofer Project
[16] Abuse of Customer Premise Equipment and Recommended Actions
[17] An Architecture for Differentiated Services
[18] New Terminology and Clarifications for Diffserv
Revisions
February 9, 2014 – Initial Release
March 7, 2014 – Updated page to include research links
July 13, 2015 – Added RIPv1 as an attack vector
August 19, 2015 – Added Multicast DNS (mDNS) and Portmap (RPCbind) as attack
vectors
April 13, 2016 – Updated detection and mitigation information

----------------------------------------------------------------
-------------- -
OTHER RESOURCES:
Contact Us | Security Publications | Alerts and Tips | Related Resources
STAY CONNECTED:
Sign up for email updates

SUBSCRIBER SERVICES:
Manage Preferences  |  Unsubscribe  |  Help


----------------------------------------------------------------
-------------- -
This email was sent to Fido4cmech@lusfiber.net using GovDelivery, on behalf
of: United States Computer Emergency Readiness Team (US-CERT) · 245 Murray
Lane SW Bldg 410 · Washington, DC 20598 · (888) 282-0870 Powered by GovDelivery
=== Cut ===

--
Keep the faith   :^)

   Ben  aka cMech  Web: http|ftp|telnet://cmech.dynip.com
                 Email: fido4cmech(at)lusfiber.net
              Home page: http://cmech.dynip.com/homepage/
           WildCat! Board 24/7  +1-337-984-4794  any BAUD 8,N,1

--- GoldED+/W32-MSVC
 * Origin: FIDONet - The Positronium Repository (1:393/68)