Last updated at Thu, 11 May 2023 02:08:29 GMT

October is National Cyber Security Awareness month and Rapid7 is taking this time to celebrate security research. This year, NCSAM coincides with new legal protections for security research under the DMCA and the 30th anniversary of the CFAA - a problematic law that hinders beneficial security research. Throughout the month, we will be sharing content that enhances understanding of what independent security research is, how it benefits the digital ecosystem, and the challenges that researchers face.

When we began brainstorming ideas for NCSAM, I suggested something related to distributed denial of service (DDoS) attacks, specifically with a focus on the UDP amplification vulnerabilities that are typically abused as part of these attacks.  Rarely a day goes by lately in the infosec world where you don't hear about DDoS attacks crushing the Internet presence of various companies for a few hours, days, weeks, or more.  Even as I wrote this, DDoS attacks are on the front page of many major news outlets. A variety of services that I needed to write this very blog post were down because of DDoS, and I even heard DDoS discussed on the only radio station I am able to get where I live. Timely.

What follows is a brief primer on and a look at what resources Rapid7 provides for further understanding UDP amplification attacks.

Background

A denial of service (DoS) vulnerability is about as simple as it sounds -- this vulnerability exists when it is possible to deny, prevent or in some way hinder access to a particular type of service.  Abusing a DoS vulnerability usually involves an attack that consumes precious compute or network resources such as CPU, memory, disk, and network bandwidth.

A DDoS attack is just a DoS attack on a larger scale, often using the resources of compromised devices on the Internet or other unwitting systems to participate in the attack.

A distributed, reflected denial of service (DRDoS) attack is a specialized variant of the DDoS attack that typically exploits UDP amplification vulnerabilities.  These are often referred to as volumetric DDoS attacks, a more generic type of DDoS attack that specifically attempts to consume precious network resources.

A UDP amplification vulnerability occurs when a UDP service responds with more data or packets than the initial request that elicited the response(s). Combined with IP packet spoofing/forgery, attackers send a large number of spoofed UDP datagrams to UDP endpoints known to be susceptible to UDP amplification using a source address corresponding to the IP address of the ultimate target of the DoS.  In this sense, the forged packets cause the UDP service to "reflect" back at the DoS target.

The exact impact of the attack is a function of how many systems participate in the attack and their available network resources, the network resources available to the target, as well as the bandwidth and packet amplification factors of the UDP service in question. A UDP service that returns 100 bytes of UDP payload in response to a 1-byte request is said to have a 100x bandwidth amplification factor.  A UDP service that returns 5 UDP packets in response to 1 request is said to have a 5x packet amplification factor. Oftentimes a ratio is used in place of a factor. For example, a 5x amplification factor can also be said to have a 1:5 amplification ratio.

For more information, consider the following resources:

Sonar UDP Studies

Rapid7's Project Sonar has been performing a variety of UDP scans on a monthly basis and uploading the results to scans.io for consumption by the larger infosec/network community for nearly three years. Infosec practitioners can use this raw scan data to research a variety of aspects related to UDP amplification vulnerabilities, including geographic/sector specific patterns, amplification factors, etc.  There are, however, some caveats:

  • Although we do not currently have studies for all UDP services with amplification vulnerabilities, we have a fair number and are in the process of adding more.
  • Not all of these studies specifically cover the UDP amplification vulnerabilities for the given service.  Some happen to use other probe types more likely to elicit a response.  In these cases, the existence of a response for a given IP simply means that it responded to our probe for that service, is likely running that service in question, but doesn't necessarily imply that the IP in question is harboring a UDP amplification vulnerability.
  • Our current usage of zmap is such that we will only record the first UDP packet seen in response to our probe.  So, if a UDP service happens to suffer from a packet-based UDP amplification vulnerability, the Sonar data alone may not show the true extent.

Currently, Rapid7's Project Sonar has coverage for a variety of  UDP services that happen to be susceptible to UDP amplification attacks.

Dennis Rand, a security researcher from Denmark, recently reached out to us asking for us to provide regular studies of the qotd (17/UDP), chargen (19/UDP) and RIPv1 services (520/UDP). When discussing his use cases for these and the other existing Sonar studies, Dennis had the following to add:

"I've been using the dataset from Rapid7 UDP Sonar for various research projects as a baseline and core part of the dataset in my research has been amazing.

This data could be used by any ISPs out there to detect if they are potentially being part of the problem.  A simple task could be to setup a script that would pull the lists every month and the compare it against previous months, if at some point the numbers go way up, this could be an indication that you might have opened up for something you should not, or at least be aware of this fact in you internal risk assessment.

Also it is awesome to work with people who are first of doing this for free, at least seen from my perspective, but still being so open to helping out in the research, like adding new service to the dataset help me to span even wider in my research projects."

For each of the studies described below, the data provided on scans.io is gzip-compressed CSV with a header indicating the respective field values, which are, for every host that responded, the timestamp in seconds since the UNIX epoch, the source address and port of the response, the destination address and port (where Sonar does its scanning from), the IP ID, the TTL, and the hex-encoded UDP response payload, if any.  Precisely how to decode the data for each of the studies listed below is an exercise currently left for the reader that may be addressed in future documentation, but for now the descriptions below in combination with Rapid7's dap should be sufficient.

DNS (53/UDP)

This study sends a DNS query to 53/UDP for the VERSION.BIND text record in the CHAOS class. In some situations this will return the version of ISC BIND that the DNS server is running, and in others it will just return an error. Data can be found here in files with the -dns-53.csv.gz suffix.  In the most recent run of this study on 10/03/2016, there were 7,963,280 endpoints that responded.

NTP (123/UDP)

There are two variants of this study.

The first sends an NTP version 2 MON_GETLIST_1 request, which will return a list of all recently connected NTP peers, generally up to 6 per packet with additional peers sent in subsequent UDP responses. Responses for this study can be found here in files with the ntpmonlist-123.csv.gz suffix.  This probe used in this study is the same as one frequently used in UDP amplification attacks against NTP.  In the most recent run of this study on 10/03/2016, 1,194,146 endpoints responded.

The second variant of this study sends an NTP version 2 READVAR request and will return all of the internal variables known to the NTP process, which typically includes things like software version, information about the underlying OS or hardware, and data specific to NTP's time keeping. The responses can be found here in files with the ntpreadvar-123.csv.gz suffix. In the most recent run of this study on 10/03/2016, 2,245,681 endpoints responded.

Other UDP amplification attacks in NTP that continue to enable DDoS attacks are described in R7-2014-12.

NBNS (137/UDP)

This study has been described in greater detail here, but the summary is that this study sends an NBNS name request.  Most endpoints speaking NBNS will return a wealth of metadata about the node/service in question, including system and group/domain names and MAC addresses.  This is the same probe that is frequently used in UDP amplification attacks against NBNS.  The responses can be found here in files with the -netbios-137.csv.gz suffix.  In the most recent run of this study on 10/03/2016, 1,768,634 endpoints responded.

SSDP/UPnP (1900/UDP)

This study sends an SSDP request that will discover the rootdevice service of most UPnP/SSDP-enabled endpoints.  The responses can be found here in files with the -upnp-1900.csv.gzsuffix.  UDP amplification attacks against SSDP/UPnP often involve a similar request but for all services, often resulting in a 10x packet amplification and a 40x bandwidth amplification.  In the most recent run of this study on 10/03/2016, 4,842,639 endpoints responded.

Portmap (111/UDP)

This study sends an RPC DUMP request to version 2 of the portmap service.  Most endpoints exposing 111/UDP that are the portmap RPC service will return a list of all of the RPC services available on this node.  The responses can be found here in files with the -portmap-111.csv.gz suffix.  There are numerous ways to exploit UDP amplification vulnerabilities in portmap, including the same one used in the Sonar study, a portmap version 3 variant that is often more voluminous, and a portmap version 4 GETSTAT request.  In the most recent run of this study on 10/03/2016, 2,836,710 endpoints responded.

Quote of the Day (17/UDP)

The qotd service is essentially the UNIX fortune bound to a UDP socket, returning quotes/adages in response to any incoming 17/UDP datagram.  Sonar's version of this study sends an empty UDP datagram to the port and records any responses, which is believed to be similar to the variant used in the UDP amplification attacks.  The responses can be found here in files with the -qotd-17.csv.gzsuffix.  In the most recent run of this newly added study on 10/21/2016, a mere 2,949 endpoints responded.

Character Generator (19/UDP)

The chargen service is a service from a time when the Internet was a wholly different place.  The UDP variant of chargen will send a random number bytes in response to any datagram arriving on 19/UDP.  While most implementations stick to purely ASCII strings of random lengths between 0 and 512, some are much chattier, spewing MTU-filling gibberish, packet after packet.  The responses can be found here in files with the -chargen-19.csv.gz suffix.  In the most recent run of this newly added study on 10/21/2016, only 3,791 endpoints responded.

RIPv1 (520/UDP)

UDP amplification attacks against the Routing Information Protocol version 1 (RIPv1) involve sending a specially crafted request that will result in RIP responding with 20 bytes of data for every route it knows about, with up to 25 routes per response for a maximum response size of 504 bytes, but RIP instances with more than 25 routes will split responses over multiple packets, adding packet amplification pains to the mix.  The responses can be found here in files with the -ripv1-520.csv.gzsuffix.  In the most recent run of this newly added study on 10/21/2016, 17,428 endpoints responded.

metasploit modules

Rapid7's Metasploit has coverage for a variety of these UDP amplification vulnerabilties built into "scanner" modules available to both the base metasploit-framework as well as the Metasploit community and Professional editions via:

Each of these modules uses the Msf::Auxiliary::UDPScanner mixin to support scanning multiple hosts at the same time. Most send probes and analyze the responses with the Msf::Auxiliary::DRDoS mixin to automatically calculate any amplification based on a high level analysis of the request/response datagram(s).

Here is an example run of auxiliary/scanner/ntp/ntp_monlist:

msf auxiliary(ntp_monlist) > run  
[+] 192.168.33.127:123 NTP monlist request permitted (5 entries)  
[+] 192.168.32.139:123 NTP monlist request permitted (4 entries)  
[+] 192.168.32.139:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): No packet amplification and a 37x, 288-byte bandwidth amplification  
[+] 192.168.33.127:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): No packet amplification and a 46x, 360-byte bandwidth amplification  
[+] 192.168.32.138:123 NTP monlist request permitted (31 entries)  
[+] 192.168.33.128:123 NTP monlist request permitted (23 entries)  
[+] 192.168.32.138:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): 6x packet amplification and a 285x, 2272-byte bandwidth amplification  
[+] 192.168.33.128:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): 4x packet amplification and a 211x, 1680-byte bandwidth amplification  
[+] 192.168.33.200:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): 2x packet amplification and a 2x, 8-byte bandwidth amplification  
[*] Scanned 256 of 512 hosts (50% complete)  
[+] 192.168.33.251:123 NTP monlist request permitted (10 entries)  
[+] 192.168.33.251:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): 2x packet amplification and a 92x, 728-byte bandwidth amplification  
[+] 192.168.33.254:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): 2x packet amplification and a 2x, 8-byte bandwidth amplification  
[*] Scanned 512 of 512 hosts (100% complete)  
[*] Auxiliary module execution completed  
msf auxiliary(ntp_monlist) >

There is also the auxiliary/scanner/udp/udp_amplification module recently added as part of metasploit-framework PR 7489 that is designed to help explore UDP amplification vulnerabilities and audit for the presence of existing ones.

Nexpose coverage

Rapid7's Nexpose product has coverage for all of the ntp vulnerabilities described above and in R7-2014-12, along with:

Additional information about Nexpose's capabilities with regards to UDP amplification vulnerabilities can be found here.

Future Research

UDP amplification vulnerabilities have been lingering since the publication of RFC 768 in 1980, but only in the last couple of years have they really become a problem.  Whether current and historical efforts to mitigate the impact that attacks involving UDP amplification have been effective is certainly debatable.  Recent events have shown that only very well fortified assets can survive DDoS attacks and UDP amplification still plays a significant role.  It is our hope that the open dissemination of active scan data through projects like Sonar and the availability of tools for detecting the presence of this class of vulnerability will serve as a valuable tool in the fight against DDoS.

If you are interested in collaborating on Metasploit modules for detecting other UDP amplification vulnerabilities, submit a Metasploit PR. If you are interesting in having Sonar perform additional relevant studies, have interests in related research, or if you have questions, we welcome your comments here as well as by reaching out to us at research@rapid7.com.

Enjoy!