Summary
SSDP (Simple Service Discovery Protocol) – commonly known as Universal Plug and Play (UPnP) – allows devices to discover their neighbors, either through network service discovery (Search) or network service broadcasting (Notify).

Following record-breaking DNS and NTP attacks earlier this year, this ubiquitous protocol has become yet another victim of exploitation by hackers, due to vulnerabilities found within popular devices like routers and NAS. This article includes 1) an analysis on the nature of SSDP DDoS attacks, compared with others in the amplified reflexive attack family; 2) some statistics we’ve gathered from SSDP DDoS attack samples; and 3) advice on SSDP mitigation.

Special thanks go out to the security community for contributing samples of SSDP DDoS attacks and for their great help in analysing those.

The reflexive attack family
Recalling the DDoS attack trend in 2014, amplified reflexive attacks (rDDoS) have been breaking new records and are predicted to top 1 Tbps (1Tbps = 1000 Gbps) by year-end. Attackers, acutely aware of the total bandwidth used to launch attacks, are very concerned about the efficiency and anonymous nature of such reflexive attacks. As such, they always aim to maximize the reflection factor in each single request while affecting the highest possible amount of vulnerable public IPs.

The concept is similar to calculating the risk level in Information Security Management Systems (ISMS):

ALE = ARO X SLE
annualized loss expectancy (ALE) = annual rate of occurrence (ARO) x the single loss expectancy (SLE)

In rDDoS terms, it becomes: total attack power = number of vulnerable public servers x reflection ratio.

According to the latest research, though the average bandwidth reflection ratio of SSDP – 30x – is not as big as that of NTP or DNS[ns], its average packet reflection ratio is rather impressive – almost 10 times the request. Essentially, one spoofed request would lead to 10 unwanted SSDP replies from a vulnerable device.

Here’s a more scary scenario: a research conducted by rapid7 in 2013 indicated that 2.2 percent of public IPs, or 81 million, were vulnerable to SSDP DDoS attacks, which is significantly more than available nameservers or NTP servers.

According to shadowserver’s latest status, there are still 18 million vulnerable SSDP hosts online. Below is the overall map around the globe. It’s clearly a worldwide threat that affects millions of innocent intermediate victims.

[source: shadowserver.org]

SSDP Protocol
SSDP is not designed to be an Internet-routable protocol, period. In fact, it was never going to become a standard. The Internet-Draft compiled by ITEF expired in April 2000. Later on, it became part of the UPnP (Universal Plug and Play). Below is the official definition:

SSDP: Simple Service Discovery Protocol. A multicast discovery and search mechanism that uses a multicast variant of HTTP over UDP.

Discovery
The protocol specification in Chapter 1: Discovery states that “to limit network congestion, the time-to-live (TTL) of each IP packet for each multicast message SHOULD default to 2 and SHOULD be configurable. When the TTL is greater than 1, it is possible for multicast messages to traverse multiple routers.” Allowing multicast packets with a TTL of greater than 1 extends the discovery range but increases risks. The standard stated that it should destinate to a multicast address, such as 239.255.255.250 (link local scope ) or ff0X::c , but M-Search via unicast address is also accepted in Chapter 1.3. “Control points can also send a unicast search message to a known IP address and port 1900 or the port indicated by SEARCHPORT.UPNP.ORG, to verify the existence of UPnP device(s) and service(s) at the IP address.”

Response are sent in batches via unicast. The first packet is sent with its root id, and additional packets are sent depending on the services offered. In general, around 10 could be found from a conventional NAS or home router. Since it’s via UDP, there’s no acknowledgement from the sender that it was able to receive all responses. It’s not a ‘conditional response’ where the SSDP would stop sending the rest of the responses if no confirmation is received when the first packet is sent.

Advertisement

Personally, I think the advertisement feature of SSP is more useful, since clients in a network are aware of new devices being added into or removed from the network.

How SSDP M-Search is abused
Since M-Search could be done via a unicast, scanning a network that’s under a proper firewall configuration and proper router ACL does nothing.

However, how many users are actually aware of the UPnP (using SSDP protocol) feature in devices like NAS, media players, TVs or home routers? I believe that number is very low. Furthermore, some router firmwares aren’t designed with security in mind: WAN ports that connect to the Internet sometimes attempt to advertise its network service via SSDP or the public SSDP M-Search query.

A key advantage of abusing home users is their lack of security awareness; end-users are not aware their 24×7 router or NAS can be used to participant in the world’s next SSDP DDoS attack campaign. With a sufficient list of vulnerable network devices, an attacker can easily distribute and load-balance to launch attacks, almost undetected.

Generating a SSDP DDoS attack is very simple. In fact, just ONE LINE of code is needed for unspoofed attacks; the POC script is barely 4KB in size.

Below are a few snapshots of a single SSDP DDoS attack : one M-SEARCH packet of 122 bytes received 12 response packets that totaled 3719 bytes. This is 12x in packet count, or 30x in byte count!

Here is another graph demonstrating the amplification power of SSDP DDoS attacks, with 100 M-Search requests per second (unit, Byte):

Red represents requests from a client.
Green represents responses on a SSDP enabled device.

Visualized M-search request and response packet in size [source: Nexusguard]

 

SSDP DDoS attack detection and mitigation
Similar to other amplified reflexive attacks, detection and mitigation is easier than other direct attacks like SYN flood or GET flood. It is now a matter of having enough bandwidth for incoming amplified traffic. This is common among all reflective attacks: easy to detect and mitigate, and purely a game of power – who is stronger to withstand.

Below is a simple visualization of the difference between direct attacks and reflexive attacks.
Normal direct DDoS attacks mostly come from random source ports while reflexive attacks come from one or a few fixed ports (multiple ports for multiple types of reflexive attacks launched simultaneously). The lack of source port randomization could lead to easily-implemented detection and mitigation filters.

Recommendations

The common solutions to all types of amplified reflexive attacks (including SSDP DDoS attacks) are:
BCP38 ingress filter: Implement filtering as close as possible to the source to reduce the risk of IP spoofing abuse; this should be easy to execute.
Patch vulnerable devices: Vendors should be responsible for fixing the vulnerabilities permanently or creating work-around solutions that are secure by default.

Consult DDoS solution experts: Online business owners should always be prepared for unseen threats, or perform security assessments as early as possible to determine a suitable DDoS solution for their specific business need.