Stupidly Simple DDoS Protocol (SSDP) generates 100 Gbps DDoS
In May, we shared statistics on the most popular attacks with reflection . Then the average size of the SSDP attack was around 12 Gbps, and the largest attack of the SSDP 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 line.
Packet Schedule Per Second:
')
Band usage:
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, TVs, or printers. For details, see the comparison between UPnP and Bonjour .
UPnP is poorly standardized, but here is an excerpt from the specifications for the
Answers to the frame
So it works in practice. For example, my Chrome browser regularly polls Smart TV, as I understand it:
This frame is sent to the multicast IP address. Other devices that listen to this address and support a specific multi-screen type
In addition to requests for specific device types, there are two “common” types of
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 an
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, then it will work fine via the Internet:
However, the most real harm is caused by the type
In this particular case, a single SSDP
The target made eight-fold multiplication of packets and 26-fold multiplication of traffic. Unfortunately, this is a typical case of SSDP.
The final step required for an attack is to convince vulnerable servers to send response packets to the victim’s address, not the attacker’s. To do this, the attacker needs to fake the sender's IP address in his requests.
We surveyed 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 the
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.
As we polled vulnerable SSDP servers, we can show the most popular
The most popular
Vulnerable IP addresses seem to belong mainly to home routers.
It goes without saying that it’s not a good idea to allow incoming 1900 / UDP traffic from the Internet to your home printer or other device. 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 your public IP address contains vulnerable SSDP services:
Unfortunately, most of the unprotected routers that were used in this attack are located in China, Russia and Argentina — places that have not historically been known for the promptness of Internet providers.
Cloudflare clients are fully protected from SSDP attacks and other multiply L3 attacks. These attacks are well reflected by 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 on 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 line.
Packet Schedule Per Second:
')
Band usage:
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:
$ 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
...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-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, TVs, or printers. For details, see the comparison between UPnP and Bonjour .
UPnP is poorly standardized, but here is an excerpt from the specifications for the
M-SEARCH frame — 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. It 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.
Answers to the frame
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 ST header field in theM-SEARCHrequest is “ssdp: all”, “upnp: rootdevice”, “uuid:”, and then follows a UUID that exactly matches the UUID of the device, or if theM-SEARCHrequest matches 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:
$ 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 WindowsThis frame is sent to the multicast IP address. Other devices that listen to this address and support a specific multi-screen type
ST (search-target) must respond.In addition to requests for specific device types, there are two “common” types of
ST requests:upnp: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 python2 import 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) ) while True: try: data, addr = s.recvfrom(32*1024) except socket.timeout: break print "[+] %s\n%s" % (addr, data) Two devices respond to my home network:
$ python ssdp-query.py [+] ('192.168.1.71', 1026) HTTP/1.1 200 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.44 06-17-2009 ST: upnp:rootdevice USN: uuid:Samsung-Printer-1_0-mrgutenberg::upnp:rootdevice [+] ('192.168.1.70', 36319) HTTP/1.1 200 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 an
M-SEARCH frame:- which we showed through the address for multicast
- directly to the UPnP / SSDP host at the 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.1 200 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.44 06-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-SEARCH , which came from the Internet. Only a slightly incorrect configuration of the firewall is required 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, then it will work fine via the Internet:
$ python ssdp-query.py 100.42.xx [+] ('100.42.x.x', 1900) HTTP/1.1 200 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 Multiplication packages
However, the most real harm is caused by the type
ssdp:all ST . His answers are much larger in size: $ python ssdp-query.py 100.42.xx ssdp:all [+] ('100.42.x.x', 1900) HTTP/1.1 200 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.1 200 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
M-SEARCH packet caused 8 packets in response. View in tcpdump:$ sudo tcpdump -ni en7 host 100.42.xx -ttttt
00:00:00.000000 IP 192.168.1.200.61794 > 100.42.xx1900: UDP, length 88
00:00:00.197481 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 227
00:00:00.199634 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 299
00:00:00.202938 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 295
00:00:00.208425 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 275
00:00:00.209496 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 307
00:00:00.212795 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 289
00:00:00.215522 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 291
00:00:00.219190 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 291The target made eight-fold multiplication of packets and 26-fold multiplication of traffic. Unfortunately, this is a typical case of SSDP.
IP spoofing
The final step required for an attack is to convince vulnerable servers to send response packets to the victim’s address, not the attacker’s. To do this, the attacker needs to fake the sender's IP address in his requests.
We surveyed 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:
$ 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%Request packets were 110 bytes in size. Response packets — on average, 321 bytes (± 29 bytes).
According to our measurements, using the
ssdp:all M-SEARCH , an attacker can get:- 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
As we polled vulnerable SSDP servers, we can show the most popular
Server header values: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
...The most popular
ST header values ​​are:298497 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
...Vulnerable IP addresses seem to belong mainly to home routers.
Open SSDP is a vulnerability
It goes without saying that it’s not a good idea to allow incoming 1900 / UDP traffic from the Internet to your home printer or other device. 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 must answer if there is at least some possibility of using unicast
M-SEARCHrequests in the real world. As far as I understand,M-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. M-SEARCHshould be sent only 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 in order to disperse traffic congestion during major SSDP attacks.
- ISPs must collect netflow samples. This is necessary to determine the true source of the attack. With netflow, it will be easy to 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 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 your public IP address contains vulnerable SSDP services:
Unfortunately, most of the unprotected routers that were used in this attack are located in China, Russia and Argentina — places that have not historically been known for the promptness of Internet providers.
Total
Cloudflare clients are fully protected from SSDP attacks and other multiply L3 attacks. These attacks are well reflected by 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 on their networks, enable BGP flowspec support, and configure network flow collection (netflow).
The article was prepared jointly by Marek Majkowski and Ben Cartwright-Cox.
Source: https://habr.com/ru/post/332812/
All Articles