Stupidly Simple DDoS Protocol (SSDP) generates 100 Gbps DDoS
- Transfer
In May, we shared statistics on the most popular attacks with reflection . At that time, the average size of the SSDP attack was around 12 Gbps, and the largest SSDP attack with a reflection was:
Everything changed a couple of days ago, when we noticed an unusually large multiplication of SSDP packets. This is worthy of a more thorough investigation, since the attack overcame the symbolic 100 Gbit / s.
Packet Schedule Per Second:
Use of the band:
Batch flood lasted 38 minutes. Judging by the data flow sample, 930 thousand reflecting servers were used. According to our estimates, each reflector sent 120 thousand packages to Cloudflare.
Reflective servers located around the world, most of all in Argentina, Russia and China. Here are the unique IP addresses by country: The distribution of IP addresses by ASN is quite typical. It largely correlates with the world's largest home Internet service providers:
This attack consists of UDP packets from port 1900. This port is used by the SSDP and UPnP protocols . UPnP is one of the Zeroconf (Zero Configuration Networking) protocols that create an IP network without configuration or special servers. Most likely, your home devices support it to make it easier to find them from a computer or phone. When a new device joins (like your laptop), it can interrogate the local network for specific devices, such as Internet gateways, audio systems, televisions, or printers. For details, see the comparison between UPnP and Bonjour .
UPnP is poorly standardized, but here is an excerpt from the specifications about the frame
Frame Responses
So it works in practice. For example, my Chrome browser regularly polls Smart TV, as I understand it: This frame is sent to the IP address for multicasting. Other devices that listen to this address and support a specific multi-screen type (search-target) must respond. In addition to requests for specific device types, there are two “common” types of requests :
To simulate these requests, you can run such a Python script (based on this work) :
Two devices respond to my home network:
Now that we understand the basics of SSDP, it will be easy to understand the essence of the attack with reflection. There are actually two ways to deliver a frame
The second method also works. We can specifically specify the IP address of my printer:
Now the problem is easily understood: SSDP does not check if the sender of the message is on the same network as the device. It will gladly respond to the request
If you give our script such a target with the wrong firewall configuration, it will work fine via the Internet:
However, the type does the most real harm
In this particular case, a single SSDP packet
The final step required for the attack is to convince the vulnerable servers to send response packets to the victim’s address, not the attacker’s. To do this, an attacker needs to fake the sender's IP address in his requests.
We polled the IP addresses of the reflectors that were used in the above 100 Gbps attack. It turned out that out of 920,000 addresses, only 350,000 (35%) still respond to test SSDP requests.
We sent, on average, 7 packets to responding to trial requests: Request packets were 110 bytes in size. Response packets - on average, 321 bytes (± 29 bytes). According to our measurements, using a type , an attacker can get:
It can be calculated that the attack on 43 million packets per second and 112 Gbit / s was initiated using:
In other words, one well-connected 10 Gbps server capable of IP spoofing can generate a significant SSDP attack.
Since we polled vulnerable SSDP servers, we can show the most popular header values
It goes without saying that allowing inbound 1900 / UDP traffic from the Internet to your home printer or other device is not a good idea. This problem has been known since at least January 2013:
The authors of SSDP did not explicitly think about the potential of UDP as a packet multiplier. There are some obvious recommendations for using SSDP in the future:
At the same time, we recommend:
Moreover, we made a website for online verification. Check it out if you want to find out if there are vulnerable SSDP services on your public IP address:
Unfortunately, most of the unprotected routers that were used in this attack are located in China, Russia, and Argentina — places that are historically not famous for the promptness of Internet service providers.
Cloudflare clients are fully protected against SSDP and other L3-class multiplication attacks. These attacks are well reflected by the Cloudflare infrastructure and do not require additional actions. However, increasing the size of SSDP can be a serious problem for other Internet users. We need to urge our ISPs to prohibit IP spoofing in their networks, enable BGP flowspec support, and configure network flow collection (netflow).
The article was prepared jointly by Marek Majkowski and Ben Cartwright-Cox.
- 30 MP / s (million packets per second)
- 80 Gbit / s (billion bits per second)
- 940 thousand IP addresses to reflect
Everything changed a couple of days ago, when we noticed an unusually large multiplication of SSDP packets. This is worthy of a more thorough investigation, since the attack overcame the symbolic 100 Gbit / s.
Packet Schedule Per Second:
Use of the band:
Batch flood lasted 38 minutes. Judging by the data flow sample, 930 thousand reflecting servers were used. According to our estimates, each reflector sent 120 thousand packages to Cloudflare.
Reflective servers located around the world, most of all in Argentina, Russia and China. Here are the unique IP addresses by country: The distribution of IP addresses by ASN is quite typical. It largely correlates with the world's largest home Internet service providers:
$ cat ips-nf-ct.txt|uniq|cut -f 2|sort|uniq -c|sort -nr|head
439126 CN
135783 RU
74825 AR
51222 US
41353 TW
32850 CA
19558 MY
18962 CO
14234 BR
10824 KR
10334 UA
9103 IT
...$ cat ips-nf-asn.txt |uniq|cut -f 2|sort|uniq -c|sort -nr|head
318405 4837 # CN China Unicom
84781 4134 # CN China Telecom
72301 22927 # AR Telefonica de Argentina
23823 3462 # TW Chunghwa Telecom
19518 6327 # CA Shaw Communications Inc.
19464 4788 # MY TM Net
18809 3816 # CO Colombia Telecomunicaciones
11328 28573 # BR Claro SA
7070 10796 # US Time Warner Cable Internet
6840 8402 # RU OJSC "Vimpelcom"
6604 3269 # IT Telecom Italia
6377 12768 # RU JSC "ER-Telecom Holding"
...However, what is SSDP?
This attack consists of UDP packets from port 1900. This port is used by the SSDP and UPnP protocols . UPnP is one of the Zeroconf (Zero Configuration Networking) protocols that create an IP network without configuration or special servers. Most likely, your home devices support it to make it easier to find them from a computer or phone. When a new device joins (like your laptop), it can interrogate the local network for specific devices, such as Internet gateways, audio systems, televisions, or printers. For details, see the comparison between UPnP and Bonjour .
UPnP is poorly standardized, but here is an excerpt from the specifications about the frame
M-SEARCH- the basic detection method:When a control point is added to the network, the UPnP discovery protocol allows this control point to search for devices of interest on the network. He does this by multicasting a search message to a reserved address and port (239.255.255.250:1900) with a pattern, or a target, corresponding to the type of identifier for a device or service.
Frame Responses
M-SEARCH:To be found by a search query, the device must send a unicast UDP response to the source IP address and port that sent the message using multicast. The answer is required if the request header field in the ST header isM-SEARCH“ssdp: all”, “upnp: rootdevice”, “uuid:”, followed by a UUID that exactly matches the device's UUID, or if the requestM-SEARCHmatches the device type or service type supported by the device.
So it works in practice. For example, my Chrome browser regularly polls Smart TV, as I understand it: This frame is sent to the IP address for multicasting. Other devices that listen to this address and support a specific multi-screen type (search-target) must respond. In addition to requests for specific device types, there are two “common” types of requests :
$ sudo tcpdump -ni eth0 udp and port 1900 -A
IP 192.168.1.124.53044 > 239.255.255.250.1900: UDP, length 175
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 1
ST: urn:dial-multiscreen-org:service:dial:1
USER-AGENT: Google Chrome/58.0.3029.110 Windows STSTupnp:rootdevice: root searchssdp:all: Search for all UPnP devices and services
To simulate these requests, you can run such a Python script (based on this work) :
#!/usr/bin/env python2import socket
import sys
dst = "239.255.255.250"if len(sys.argv) > 1:
dst = sys.argv[1]
st = "upnp:rootdevice"if len(sys.argv) > 2:
st = sys.argv[2]
msg = [
'M-SEARCH * HTTP/1.1',
'Host:239.255.255.250:1900',
'ST:%s' % (st,),
'Man:"ssdp:discover"',
'MX:1',
'']
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
s.settimeout(10)
s.sendto('\r\n'.join(msg), (dst, 1900) )
whileTrue:
try:
data, addr = s.recvfrom(32*1024)
except socket.timeout:
breakprint"[+] %s\n%s" % (addr, data)Two devices respond to my home network:
$ python ssdp-query.py
[+] ('192.168.1.71', 1026)
HTTP/1.1200 OK
CACHE-CONTROL: max-age = 60
EXT:
LOCATION: http://192.168.1.71:5200/Printer.xml
SERVER: Network Printer Server UPnP/1.0 OS 1.29.00.4406-17-2009
ST: upnp:rootdevice
USN: uuid:Samsung-Printer-1_0-mrgutenberg::upnp:rootdevice
[+] ('192.168.1.70', 36319)
HTTP/1.1200 OK
Location: http://192.168.1.70:49154/MediaRenderer/desc.xml
Cache-Control: max-age=1800
Content-Length: 0
Server: Linux/3.2 UPnP/1.0 Network_Module/1.0 (RX-S601D)
EXT:
ST: upnp:rootdevice
USN: uuid:9ab0c000-f668-11de-9976-000adedd7411::upnp:rootdevice Firewall
Now that we understand the basics of SSDP, it will be easy to understand the essence of the attack with reflection. There are actually two ways to deliver a frame
M-SEARCH:- which we showed through the address for multicast
- Directly to UPnP / SSDP host at regular address (unicast)
The second method also works. We can specifically specify the IP address of my printer:
$ python ssdp-query.py 192.168.1.71
[+] ('192.168.1.71', 1026)
HTTP/1.1200 OK
CACHE-CONTROL: max-age = 60
EXT:
LOCATION: http://192.168.1.71:5200/Printer.xml
SERVER: Network Printer Server UPnP/1.0 OS 1.29.00.4406-17-2009
ST: upnp:rootdevice
USN: uuid:Samsung-Printer-1_0-mrgutenberg::upnp:rootdevice Now the problem is easily understood: SSDP does not check if the sender of the message is on the same network as the device. It will gladly respond to the request
M-SEARCHthat came from the Internet. It requires only slightly incorrect configuration of the firewall when port 1900 is open to the outside world - and this is the ideal target for multiplying the flood of UDP. If you give our script such a target with the wrong firewall configuration, it will work fine via the Internet:
$ python ssdp-query.py 100.42.x.x
[+] ('100.42.x.x', 1900)
HTTP/1.1200 OK
CACHE-CONTROL: max-age=120
ST: upnp:rootdevice
USN: uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::upnp:rootdevice
EXT:
SERVER: TBS/R2 UPnP/1.0 MiniUPnPd/1.2
LOCATION: http://192.168.2.1:40464/rootDesc.xmlMultiplication packages
However, the type does the most real harm
ssdp:allST. His answers are much larger in size:$ python ssdp-query.py 100.42.x.x ssdp:all
[+] ('100.42.x.x', 1900)
HTTP/1.1200 OK
CACHE-CONTROL: max-age=120
ST: upnp:rootdevice
USN: uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::upnp:rootdevice
EXT:
SERVER: TBS/R2 UPnP/1.0 MiniUPnPd/1.2
LOCATION: http://192.168.2.1:40464/rootDesc.xml
[+] ('100.42.x.x', 1900)
HTTP/1.1200 OK
CACHE-CONTROL: max-age=120
ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1
USN: uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::urn:schemas-upnp-org:device:InternetGatewayDevice:1
EXT:
SERVER: TBS/R2 UPnP/1.0 MiniUPnPd/1.2
LOCATION: http://192.168.2.1:40464/rootDesc.xml
... и ещё 6 ответных пакетов....In this particular case, a single SSDP packet
M-SEARCHcaused 8 packets in response. View in tcpdump: The
target has performed eight-fold multiplication of packets and 26-fold multiplication of traffic. Unfortunately, this is a typical case of SSDP.$ sudo tcpdump -ni en7 host 100.42.x.x -ttttt
00:00:00.000000 IP 192.168.1.200.61794 > 100.42.x.x.1900: UDP, length 88
00:00:00.197481 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 227
00:00:00.199634 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 299
00:00:00.202938 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 295
00:00:00.208425 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 275
00:00:00.209496 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 307
00:00:00.212795 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 289
00:00:00.215522 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 291
00:00:00.219190 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 291IP spoofing
The final step required for the attack is to convince the vulnerable servers to send response packets to the victim’s address, not the attacker’s. To do this, an attacker needs to fake the sender's IP address in his requests.
We polled the IP addresses of the reflectors that were used in the above 100 Gbps attack. It turned out that out of 920,000 addresses, only 350,000 (35%) still respond to test SSDP requests.
We sent, on average, 7 packets to responding to trial requests: Request packets were 110 bytes in size. Response packets - on average, 321 bytes (± 29 bytes). According to our measurements, using a type , an attacker can get:
$ cat results-first-run.txt|cut -f 1|sort|uniq -c|sed -s 's#^ \+##g'|cut -d " " -f 1| ~/mmhistogram -t "Response packets per IP" -p
Response packets per IP min:1.00 avg:6.99 med=8.00 max:186.00 dev:4.44 count:350337
Response packets per IP:
value |-------------------------------------------------- count
0 | ****************************** 23.29%
1 | **** 3.30%
2 | ** 2.29%
4 |************************************************** 38.73%
8 | ************************************** 29.51%
16 | *** 2.88%
32 | 0.01%
64 | 0.00%
128 | 0.00%ssdp:allM-SEARCH- 7x multiplication of packets
- 20x traffic multiplication
It can be calculated that the attack on 43 million packets per second and 112 Gbit / s was initiated using:
- 6.1 million packets per second
- channel 5.6 Gbit / s
In other words, one well-connected 10 Gbps server capable of IP spoofing can generate a significant SSDP attack.
More about SSDP servers
Since we polled vulnerable SSDP servers, we can show the most popular header values
Server:
The most popular header values :
Vulnerable IP addresses seem to belong mainly to home routers.104833 Linux/2.4.22-1.2115.nptl UPnP/1.0 miniupnpd/1.0
77329 System/1.0 UPnP/1.0 IGD/1.0
66639 TBS/R2 UPnP/1.0 MiniUPnPd/1.2
12863 Ubuntu/7.10 UPnP/1.0 miniupnpd/1.0
11544 ASUSTeK UPnP/1.0 MiniUPnPd/1.4
10827 miniupnpd/1.0 UPnP/1.0
8070 Linux UPnP/1.0 Huawei-ATP-IGD
7941 TBS/R2 UPnP/1.0 MiniUPnPd/1.4
7546 Net-OS 5.xx UPnP/1.0
6043 LINUX-2.6 UPnP/1.0 MiniUPnPd/1.5
5482 Ubuntu/lucid UPnP/1.0 MiniUPnPd/1.4
4720 AirTies/ASP 1.0 UPnP/1.0 miniupnpd/1.0
4667 Linux/2.6.30.9, UPnP/1.0, Portable SDK for UPnP devices/1.6.6
3334 Fedora/10 UPnP/1.0 MiniUPnPd/1.4
2814 1.0
2044 miniupnpd/1.5 UPnP/1.0
1330 1
1325 Linux/2.6.21.5, UPnP/1.0, Portable SDK for UPnP devices/1.6.6
843 Allegro-Software-RomUpnp/4.07 UPnP/1.0 IGD/1.00
776 Upnp/1.0 UPnP/1.0 IGD/1.00
675 Unspecified, UPnP/1.0, Unspecified
648 WNR2000v5 UPnP/1.0 miniupnpd/1.0
562 MIPS LINUX/2.4 UPnP/1.0 miniupnpd/1.0
518 Fedora/8 UPnP/1.0 miniupnpd/1.0
372 Tenda UPnP/1.0 miniupnpd/1.0
346 Ubuntu/10.10 UPnP/1.0 miniupnpd/1.0
330 MF60/1.0 UPnP/1.0 miniupnpd/1.0
...ST298497 upnp:rootdevice
158442 urn:schemas-upnp-org:device:InternetGatewayDevice:1
151642 urn:schemas-upnp-org:device:WANDevice:1
148593 urn:schemas-upnp-org:device:WANConnectionDevice:1
147461 urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
146970 urn:schemas-upnp-org:service:WANIPConnection:1
145602 urn:schemas-upnp-org:service:Layer3Forwarding:1
113453 urn:schemas-upnp-org:service:WANPPPConnection:1
100961 urn:schemas-upnp-org:device:InternetGatewayDevice:
100180 urn:schemas-upnp-org:device:WANDevice:
99017 urn:schemas-upnp-org:service:WANCommonInterfaceConfig:
98112 urn:schemas-upnp-org:device:WANConnectionDevice:
97246 urn:schemas-upnp-org:service:WANPPPConnection:
96259 urn:schemas-upnp-org:service:WANIPConnection:
93987 urn:schemas-upnp-org:service:Layer3Forwarding:
91108 urn:schemas-wifialliance-org:device:WFADevice:
90818 urn:schemas-wifialliance-org:service:WFAWLANConfig:
35511 uuid:IGD{8c80f73f-4ba0-45fa-835d-042505d052be}000000000000
9822 urn:schemas-upnp-org:service:WANEthernetLinkConfig:1
7737 uuid:WAN{84807575-251b-4c02-954b-e8e2ba7216a9}000000000000
6063 urn:schemas-microsoft-com:service:OSInfo:1
...Open SSDP is a vulnerability
It goes without saying that allowing inbound 1900 / UDP traffic from the Internet to your home printer or other device is not a good idea. This problem has been known since at least January 2013:
The authors of SSDP did not explicitly think about the potential of UDP as a packet multiplier. There are some obvious recommendations for using SSDP in the future:
- The authors of SSDP should answer whether there is at least some possibility of using unicast requests in the real world
M-SEARCH. As far as I understand, itM-SEARCHmakes practical sense only as a multicast request on a local network. - Support for unicast requests
M-SEARCHmust either be canceled or limited in speed, as the DNS Response Rate Limit applies . - Replies
M-SEARCHshould only be sent to recipients on the local network. Answers outside the local network make little sense and open up the possibility of using the described vulnerability.
At the same time, we recommend:
- Network administrators must ensure that incoming port 1900 / UDP is blocked on the firewall.
- Internet providers should never allow IP spoofing on their network. IP spoofing is the true root cause of the problem. See the notorious BCP38 .
- Internet service providers must allow their users to use the BGP flowspec to limit incoming traffic to 1900 / UDP to disperse traffic congestion during major SSDP attacks.
- ISPs must collect netflow samples . This is to determine the true source of the attack. With netflow, you will simply answer questions like: “Which of my clients sent 6.4 million packets per second to port 1900?” To maintain confidentiality, we recommend collecting traffic samples with a maximum sample interval: 1 out of 64,000 packets. This is sufficient to detect DDoS attacks, and at the same time, sufficient confidentiality of individual user sessions is maintained.
- Developers should not roll out their own UDP protocols without taking into account the problem of packet multiplication. UPnP needs to be standardized and examined normally.
- End users are advised to run a script to scan their networks for devices with the UPnP function and consider whether to allow them access to the Internet.
Moreover, we made a website for online verification. Check it out if you want to find out if there are vulnerable SSDP services on your public IP address:
Unfortunately, most of the unprotected routers that were used in this attack are located in China, Russia, and Argentina — places that are historically not famous for the promptness of Internet service providers.
Total
Cloudflare clients are fully protected against SSDP and other L3-class multiplication attacks. These attacks are well reflected by the Cloudflare infrastructure and do not require additional actions. However, increasing the size of SSDP can be a serious problem for other Internet users. We need to urge our ISPs to prohibit IP spoofing in their networks, enable BGP flowspec support, and configure network flow collection (netflow).
The article was prepared jointly by Marek Majkowski and Ben Cartwright-Cox.