<html>
<body>
<blockquote type=cite class=cite cite=""><font size=3><br>
Date: Thu, 20 Aug 2015 16:37:07 -0500<br>
To: w3hwn@comcast.net<br>
From: "US-CERT" <US-CERT@ncas.us-cert.gov><br><br>
<img src="https://public.govdelivery.com/system/images/37745/original/BANNER_NCCIC_USC_01.png" width=700 height=100 alt="NCCIC / US-CERT">
<br><br>
National Cyber Awareness System:<br><br>
<a href="https://www.us-cert.gov/ncas/alerts/TA14-017A">Alert (TA14-017A)
UDP-Based Amplification Attacks</a><br>
Original release date: January 17, 2014 | Last
<a href="https://www.us-cert.gov/ncas/alerts/TA14-017A#revisions">
revised</a>: August 19, 2015 <br>
</font><h2><b>Systems Affected</b></h2><font size=3><br><br>
Certain UDP protocols have been identified as potential attack vectors:
<ul>
<li>DNS
<li>NTP
<li>SNMPv2
<li>NetBIOS
<li>SSDP
<li>CharGEN
<li>QOTD
<li>BitTorrent
<li>Kad
<li>Quake Network Protocol
<li>Steam Protocol
<li>RIPv1
<li>Multicast DNS (mDNS)
<li>Portmap
</ul><br>
</font><h2><b>Overview</b></h2><font size=3><br><br>
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.<br><br>
</font><h2><b>Description</b></h2><font size=3><br><br>
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
[<a href="http://tools.ietf.org/html/rfc3261">1</a>]. 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.<br><br>
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.<br><br>
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
[<a href="http://www.christian-rossow.de/articles/Amplification_DDoS.php">
2</a>]
[<a href="http://www.christian-rossow.de/publications/amplification-ndss2014.pdf">
3</a>].<br><br>
The list of known protocolsand their associated bandwidth amplification
factorsare listed below. US-CERT offers thanks to Christian Rossow for
providing this information. For more information on bandwith
amplificatication factors, please see Christian's
<a href="http://www.christian-rossow.de/articles/Amplification_DDoS.php">
blog</a> and associated
<a href="http://www.christian-rossow.de/publications/amplification-ndss2014.pdf">
research paper</a>.<br>
<b>ProtocolBandwidth Amplification FactorVulnerable Command</b><br>
DNS 28 to 54 see:<a href="http://www.us-cert.gov/ncas/alerts/TA13-088A">
TA13-088A</a> [4] <br>
NTP 556.9 see:
<a href="http://www.us-cert.gov/ncas/alerts/TA14-013A">TA14-013A</a> [5]
<br>
SNMPv2 6.3 GetBulk request <br>
NetBIOS 3.8 Name resolution <br>
SSDP 30.8 SEARCH request <br>
CharGEN 358.8 Character generation request <br>
QOTD 140.3 Quote request <br>
BitTorrent 3.8 File search <br>
Kad 16.3 Peer list exchange <br>
Quake Network Protocol 63.9 Server info exchange <br>
Steam Protocol 5.5 Server info exchange <br>
Multicast DNS (mDNS) 2 to 10 Unicast query <br>
RIPv1 131.24 Malformed request <br>
Portmap (RPCbind) 7 to 28 Malformed request <br><br>
In March 2015, Software Engineering Institute CERT issued Vulnerabilty
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.
[<a href="http://www.kb.cert.org/vuls/id/550620">6</a>]<br><br>
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
[<a href="http://www.stateoftheinternet.com/">7</a>].<br><br>
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 victims network with UDP
traffic.
[<a href="http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-an-early-warning-to-the-industry/">
8</a>]<br><br>
</font><h2><b>Impact</b></h2><font size=3><br><br>
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.<br><br>
</font><h2><b>Solution</b></h2><font size=3><br><br>
<br>
</font><h3><b>DETECTION</b></h3><font size=3><br><br>
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.<br><br>
</font><h3><b>MITIGATION</b></h3><font size=3><br><br>
<b>Source IP Verification<br>
</b><br>
Because the UDP requests being sent by the attacker-controlled clients
must have a source IP address spoofed to appear as the victims 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 packets path
[<a href="http://tools.ietf.org/html/bcp38">9</a>]
[<a href="http://tools.ietf.org/html/bcp84">10</a>]. 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.<br><br>
To verify your network has implemented ingress filtering, download the
open source tools from <a href="http://spoofer.caida.org/">the Spoofer
Project</a> [<a href="http://spoofer.caida.org/">11</a>].<br><br>
<b>Traffic Shaping<br>
</b><br>
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
[<a href="http://tools.ietf.org/html/rfc2475">12</a>]
[<a href="http://tools.ietf.org/html/rfc3260">13</a>]. Most network
devices today provide these functions in their software.<br><br>
</font><h2><b>References</b></h2><font size=3><br><br>
<ul>
<li><a href="http://tools.ietf.org/html/rfc3261">[1] SIP: Session
Initiation Protocol</a>
<li>
<a href="http://www.christian-rossow.de/articles/Amplification_DDoS.php">
[2] Amplification Hell: Abusing Network Protocols for DDoS (link is
external)</a>
<li>
<a href="http://www.christian-rossow.de/publications/amplification-ndss2014.pdf">
[3] Amplification Hell: Revisiting Network Protocols for DDoS Abuse
(link is external)</a>
<li><a href="http://www.us-cert.gov/ncas/alerts/TA13-088A">[4] DNS
Amplification Attacks</a>
<li><a href="http://www.us-cert.gov/ncas/alerts/TA14-013A">[5] NTP
Amplification Attacks Using CVE-2013-5211</a>
<li><a href="http://www.kb.cert.org/vuls/id/550620">[6] VU#550620:
Multicast DNS (mDNS) implementations may respond to unicast queries
originating outside the local link</a>
<li>
<a href="http://www.stateoftheinternet.com/resources-web-security-threat-advisories-2015-ripv1-reflection-ddos.html">
[7] RIPv1 Reflection DDoS [Medium Risk] (link is external)</a>
<li>
<a href="http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-an-early-warning-to-the-industry/">
[8] A New New DDoS Reflection Attack: Portmapper; An Early Warning to the
Industry (link is external)</a>
<li><a href="http://tools.ietf.org/html/bcp38">[9] Network Ingress
Filtering: Defeating Denial of Service Attacks Which Employ IP Source
Address Spoofing</a>
<li><a href="http://tools.ietf.org/html/bcp84">[10] Ingress Filtering for
Multihomed Networks</a>
<li><a href="http://spoofer.caida.org/">[11] The Spoofer Project</a>
<li><a href="http://tools.ietf.org/html/rfc2475">[12] An Architecture for
Differentiated Services</a>
<li><a href="http://tools.ietf.org/html/rfc3260">[13] New Terminology and
Clarifications for Diffserv</a>
</ul><br>
</font><h2><b>Revisions</b></h2><font size=3><br><br>
<ul>
<li>February 09, 2014 Initial Release
<li>March 07, 2014 Updated page to include research links
<li>July 13, 2015 Added RIPv1 as an attack vector
<li>August 19, 2015 - Added Multicast DNS (mDNS) and Portmap (RPCbind) as
attack vectors
</ul><hr>
OTHER RESOURCES: <br>
<a href="http://www.us-cert.gov/contact-us/">Contact Us</a> |
<a href="http://www.us-cert.gov/security-publications">Security
Publications</a> | <a href="http://www.us-cert.gov/ncas">Alerts and
Tips</a> | <a href="http://www.us-cert.gov/related-resources">Related
Resources</a> <br>
STAY CONNECTED: <br>
<a href="http://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/new">
<img src="https://service.govdelivery.com/banners/GOVDELIVERY/SOCIAL_MEDIA/envelope.gif" width=25 height=25 alt="Sign up for email updates">
</a> <br><br>
SUBSCRIBER SERVICES:<br>
<a href="http://public.govdelivery.com/accounts/USDHSUSCERT/subscribers/new?preferences=true">
Manage Preferences</a> |
<a href="https://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/one_click_unsubscribe?verification=5.950164116ce9221a178d1afcfce6b64a&destination=w3hwn@comcast.net">
Unsubscribe</a> |
<a href="https://subscriberhelp.govdelivery.com/">Help</a><br>
<hr>
This email was sent to w3hwn@comcast.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
<a href="http://www.govdelivery.com/portals/powered-by">
<img src="https://service.govdelivery.com/banners/GOVDELIVERY/logo_gd_poweredby.gif" width=115 height=35 alt="Powered by GovDelivery">
</a> </font></blockquote></body>
</html>