NCCIC / US-CERT   
      
   National Cyber Awareness System:   
      
   Alert (TA14-017A) UDP-Based Amplification Attacks   
      
   Original release date: January 17, 2014 | Last revised: August 19, 2015   
   Systems Affected   
   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   
   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, 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.   
      
   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 bandwith amplificatication   
   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 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. [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. 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, download 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   
   [1] SIP: Session Initiation Protocol   
   [2] Amplification Hell: Abusing Network Protocols for DDoS (link is external)   
   [3] Ampli?cation 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   
   Revisions   
   February 09, 2014 – Initial Release   
   March 07, 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   
      
   ----------------------------------------------------------------   
   -------------- -   
   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 ===   
      
      
   --   
   Guardien Fide   :^)   
      
      Ben  aka cMech  Web: http://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)