New DDoS Attack Method Demands a Fresh Approach to Amplification Assault Mitigation

Amplification attack vectors are some of the most commonly used tools in the DDoS attacker’s arsenal. In the last quarter of 2017, we saw NTP amplification employed in roughly 33 percent of all DDoS assaults against our customers, while DNS and SSDP amplification vectors played a part in 17 percent and 13.7 percent of attacks, respectively.
For bad actors, amplification vectors offer a shortcut to launching bandwidth-heavy assaults without the need for equally large botnet resources. From a mitigation point of view, however, they represent a diminished threat as, by now, most mitigation services have scaled to a point where attack bandwidth is no longer a chief concern—or any concern at all.
More importantly, the source port headers of amplification payloads follow a predictable pattern, making them easy to filter at a network border. For example, blocking all packets with source port 53 is considered a tried-and-true method for mitigating DNS amplification attacks.
Still, as the song goes, “the times they are a changin’.” Recently, while mitigating an SSDP amplification attack, we saw evidence of payloads with irregular source port data—something few in our industry consider possible and even fewer are likely to be prepared for.
In the following post, we’ll share our findings of the assault and provide a proof of concept (PoC) for a method that could have been used to launch the attack. In addition, we’ll provide evidence of another attack with similar characteristics spotted in the wild.
The implications of these findings are extensive, as they require mitigation providers to rethink the way they currently deal with amplification DDoS threats.

UPnP Protocol – A Long History of Security Issues

The attack method we’re about to describe is made possible by a well-known, but still not resolved, UPnP (Universal Plug and Play) protocol exploit.
For the uninitiated, UPnP is a networking protocol operating over UDP port 1900 for device discovery and an arbitrarily chosen TCP port for device control. The protocol is commonly used by IoT devices (e.g., computers, routers or printers) to discover each other’s presence and communicate over a LAN.
UPnP has raised security concerns over the years, because of the following:

1. Bad default settings that leave devices open to remote/WAN access.
2. Lack of an authentication mechanism, which add to the aforementioned issue.
3. The existence of UPnP-specific remote code execution vulnerabilities.

Examples of UPnP related vulnerabilities date back all the way to 2001, with the discovery of a buffer overflow exploit that was able to cause crashes and allow for remote code execution (RCE) in Windows XP computers and earlier Windows ME versions.
During the SANE 6 conference five years later, Armijn Hemel presented a paper titled “Universal Plug and Play: Dead Simple or Simply Deadly?” In it, he described how UPnP devices that are insecurely open to WAN access could be reconfigured remotely via XML SOAP API calls.
The concept has since been revisited by a number of security researchers, including reports from Rapid7 and, most recently, Akamai. It was also a topic in several DEFCON presentations, including this one by Ricky Lawshae:

Diving deeper into this body of research could prove interesting. For the purpose of this discussion, however, it’s enough to note that it shows how SOAP API calls can be used for remote execution of AddPortMapping commands, which govern port forwarding rules.

PoC: Evasive Amplification, Brought to You by UPnP Port Forwarding

Our interest in UPnP remote access exploits began with an SSDP amplification assault we mitigated on April 11 of this year. During the assault, which occurred in a number of successive waves, we noticed that a certain percentage of SSDP payloads, sometimes as much as ~12 percent, were arriving from an unexpected source port, and not UDP/1900.

Surprised by what we were seeing, and concerned with its future implications, we attempted to find an explanation. After ruling out several options, we were finally able to reproduce the assault by creating a PoC for a UPnP-integrated attack method that could be used to obfuscate source port information for any type of amplification payload.
Below are the details of our PoC, performed for DNS amplification attacks.

Step 1: Locating an open UPnP router

This can be done in any number of ways, from running a wide-scale scan with SSDP requests to simply using the Shodan search engine to look for the “rootDesc.xml” file commonly found on such devices.
In the screenshot below, you can see that running this query yielded us over 1.3 million results. While not all of these devices are necessarily vulnerable, finding an exploitable one is still very easy, especially if a bad actor used a script to automate the process.

Step 2: Accessing the device XML file

With the device located, the next step is to access the file via HTTP. Still using Shodan as an example, this can be done by replacing the ‘Location’ IP with the actual device IP, like so:

Step 3: Modifying port forwarding rules

Cataloged in rootDesc.xml are all of the available UPnP services and devices. For each, a <SCPDURL> is provided, showing all of the actions that the device will accept remotely.

First on that list of actions is AddPortMapping—a command that can be used to configure port forwarding rules.

Using the scheme within the file, a SOAP request can be crafted to create a forwarding rule that reroutes all UDP packets sent to port 1337 to an external DNS server (3.3.3.3) via port UDP/53. This is how it looks:

Some of you might be surprised that something like this could even work, as port forwarding is only supposed to be used for mapping traffic from external IPs to internal IPs and vice versa, not to proxy requests from external IPs to another external IP. In reality, however, few routers actually bother to verify that a provided “internal IP” is actually internal, and abides by all forwarding rules as a result.

Step 4: Launching a port-obfuscated DNS amplification

With the port forwarding rules in place, a DNS request is issued to the device, prompting the following sequence of events:

1. A DNS request is received by the UPnP device on port UDP/1337.
2. The request is then proxied to a DNS resolver over destination port UDP/53, due to port forwarding rules.
3. The DNS resolver responds to the device over source port UDP/53.
4. The device forwards the DNS response back to the original requestor, but not before changing the source port back to UDP/1337.

Running this script on our own device got us the smoking gun seen below—a DNS response for Imperva.com that was returned from an irregular source port (UDP/1337):

This was enough to serve as a proof of concept for our hypothesis. In an actual attack scenario, however, the initial DNS request would have been issued from a spoofed victim’s IP, meaning that the response would have been bounced back to the victim.
If so inclined, we could use the device to launch a DNS amplification DDoS assault with evasive ports. These payloads would originate from irregular source ports, enabling them to bypass commonplace scrubbing directives that identify amplification payloads by looking for source port data for blacklisting.

Implications and Further Evidence

The above PoC proves that UPnP devices can be used to obfuscate the source port data of amplification payloads. Notably, the evasion method is not limited to DNS amplification, as our own subsequent test showed it to be effective for SSDP, DNS, and NTP attacks. Furthermore, there is no reason to assume that other amplification vectors (e.g., Memcached) will not work just as well.
This adds up to a major paradigm shift in the way amplification attacks are mitigated today.
With source IP and port information no longer serving as reliable filtering factors, the most likely answer is to perform deep packet inspection (DPI) to identify amplification payloads—a more resource-intensive process, which is challenging to perform at an inline rate without access to dedicated mitigation equipment.
It should be noted that we also considered alternative hypotheses for the attack that prompted our investigation. For instance, that the occurrence in question could have been explained by an internal network setup or a purposeful forwarding configuration, which unintentionally resulted in port obfuscation.
Just as we were developing the PoC, however, our original thinking was reaffirmed by another assault with similar characteristics. Occurring on April 26, that assault was carried out via an NTP amplification vector, with some of the payloads originating from a source port other than UDP/123. The low volume at which these arrived makes us believe that they could be probing attempts.

With several indications of source port obfuscation, we were even more motivated to press on with publishing our research. It’s our hope that these findings will help the mitigation industry prepare itself for the above-described evasion tactics before they become more common.
We also hope that our findings will add to the existing body of research focusing on UPnP-related security threats, and help promote better security awareness among IoT manufacturers and distributors.
After all, this and many other UPnP exploits can be very easily avoided just by blocking the devices from being remotely accessible—an option that, in most cases, only exists as an oversight, since it serves no useful function or has any benefit for device users.