Quick Analysis of a DDoS Attack Using SSDP

Last week, one of our many clients came under an interesting attack. Enough that it was flagged for human intervention. The interesting aspect of the case was that it was a multi-faceted DDoS attack.

The first issue we noticed was a Layer 7 – HTTP Flood (DDoS) Attack attack generating thousands of HTTP requests per second. This is not uncommon, and we’ve written about several instances of this in the past. When they are large enough they trigger a number of system alarms that allow us to quickly run counter intelligence based on the logs and to create custom patterns, signatures, that we can then deploy to proactively protect our clients.

Once the Layer 7 DDoS attack was under control, we continued our investigation of the server and noticed that it was also suffering other types of DDoS attacks. Our attention turned to tcpdump. If you’re not familiar with TCPDUMP, it’s a command line packet analyzer that allows you to intercept and display all traffic that is hitting your computer. This allowed us to further investigate what the attacker was doing; further inspection revealed a large number of UDP packets hitting the server. Since we don’t run UDP on that server, it was easy to deduce that it was a DDoS attack.

If your site is currently experiencing these problems, get in contact with us. We can help and it’s helpful to see different iterations of these attacks in the wild. If you’d like to read more about DDoS attacks, you can do so here or here.

Simple Service Discovery Protocol (SSDP) DDoS

If you’re not familiar with SSDP, it is the Simple Service Discovery Protocol. It is often used for discovery of Plug & Play (UPnP) devices. It was introduced in 1999 and is used by many routers and network devices. If you really want to get all geeky feel free to read the last draft by the Internet Engineering Task Force on the subject.

The first packets we found had the source port 1900 (SSDP) and were hitting destination port 7 (echo). This is what it looked like:

19:11:48.918266 IP 5f44d7e8.dynamic.mv.ru.1900 > serverX.sucuri.net.echo: UDP, length 274
19:11:48.918271 IP > serverX.sucuri.net.echo: UDP, length 320
19:11:48.918275 IP > serverX.sucuri.net.echo: UDP, length 307
19:11:48.918279 IP > serverX.sucuri.net.echo: UDP, length 326
19:11:48.918283 IP c-69-141-76-209.hsd1.nj.comcast.net.1900 > serverX.sucuri.net.echo: UDP, length 300
19:11:48.918287 IP > serverX.sucuri.net.echo: UDP, length 307
19:11:48.918291 IP c-69-141-76-209.hsd1.nj.comcast.net.1900 > serverX.sucuri.net.echo: UDP, length 302
19:11:48.918294 IP > serverX.sucuri.net.echo: UDP, length 323
19:11:48.918301 IP > serverX.sucuri.net.echo: UDP, length 268

This was a new attack vector, leveraging SSDP. UDP-based DDoS is common, many in this business see it often. Often enough that rulesets exist to proactively block and mitigate attacks, but the use of SSDP is rare, at least for us. Interestingly enough, based on the Community Emergency Response Teams (CERT) blog, SSDP can lead to a 30x amplification of the attack, which might explain why attackers are using it now.

Below is a list of protocols versus amplification rates:


We love data and analysis as well as sharing our findings with the world, so we made sure to save some PCAPS (Packet Captures) to analyze:

$ capinfos ssdp.pcap
File name: ssdp.pcap
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
Packet size limit: file hdr: 65535 bytes
Number of packets: 1000 k
File size: 326 MB
Data size: 310 MB
Capture duration: 5 seconds
Start time: Wed Aug 27 19:11:48 2014
End time: Wed Aug 27 19:11:54 2014
Data byte rate: 59 MBps
Data bit rate: 476 Mbps
Average packet size: 310,68 bytes
Average packet rate: 191 kpackets/sec

As you can see, this simple attack hit 192,000 UDP packets per second and 1 million packets in 5 seconds, all while using around 476 Mbps of bandwidth, which really isn’t very big by itself, but had to be dealt with.

Below, you can see stats by number of packets in a 5s interval.


Looking into requests payloads we have a couple different samples:

HTTP/1.1 200 OK
Cache-Control: max-age=120
Server: Linux/2.4.22-1.2115.nptl UPnP/1.0 miniupnpd/1.0
ST: urn:schemas-upnp-org:device:InternetGatewayDevice:
USN: uuid:b1c5d60c-1dd1-11b2-8687-a0bc8f76d644::urn:schemas-upnp-org:device:InternetGatewayDevice:

HTTP/1.1 200 OK
CACHE-CONTROL: max-age = 120
ST: urn:schemas-upnp-org:service:WANIPConnection:1
SERVER: System/1.0 UPnP/1.0 IGD/1.0
USN: uuid:WANConnection{9679d566-230a-49d3-92e5-421e9223eaef}000000000000::urn:schemas-upnp-org:service:WANIPConnection:1

HTTP/1.1 200 OK
Server: Custom/1.0 UPnP/1.0 Proc/Ver

HTTP/1.1 200 OK
CACHE-CONTROL: max-age = 120
ST: urn:schemas-upnp-org:device:WANDevice:1
SERVER: System/1.0 UPnP/1.0 IGD/1.0
USN: uuid:WAN{84807575-251b-4c02-954b-e8e2ba7216a9}000000000000::urn:schemas-upnp-org:device:WANDevice:1

Based on this very small subset of data, you could say that it’s a good bet that home routers are being abused. In this attack we found 111,000 different IP sources. The SANS team also reported seeing SSDP attacks last week. This attack wasn’t very large, but it seems the attackers are just starting to work with SSDP, so we expect to see some much larger SSDP-based amplification attacks in the future.

For sysadmins, this sort of attack can easily overflow your bandwidth limits, so it is really difficult to block at the server-level. For good mitigation you have to consider blocks at the edge (border routers).

Note that sites using CloudProxy (our website firewall) are automatically protected against SSDP-based DDoS attacks, among many others.

Happy Networking.

  1. Another example:

    11:36:45.702671 IP (tos 0x0, ttl 46, id 0, offset 0, flags [DF], proto UDP (17), length 291) > 31.186.251.x.27016: UDP, length 263
    0x0000: 4500 0123 0000 4000 2e11 71ba 8efe 2fa8 E..#..@…q…/.
    0x0010: 1fba fbaf 076c 6988 010f 6476 4854 5450 …..li…dvHTTP
    0x0020: 2f31 2e31 2032 3030 204f 4b0d 0a53 6572 /1.1.200.OK..Ser
    0x0030: 7665 723a 2043 7573 746f 6d2f 312e 3020 ver:.Custom/1.0.
    0x0040: 5550 6e50 2f31 2e30 2050 726f 632f 5665 UPnP/1.0.Proc/Ve
    0x0050: 720d

Comments are closed.

You May Also Like