After the preliminary study of denial-of-service (DoS) cyberattacks, together with some of their variants set out in the article “DrDoS: characteristics and functioning“, this new article will address how the SSDP protocol is used as a tool to conduct a DoS cyberattack, specifically the Reflected Denial-of-Service (DrDoS) variant.
The purpose of the Simple Service Discovery Protocol (SSDP) is to find Universal Plug and Play (UPnP) devices and connect them to another device within a private or public network. A UPnP device can be a PC, a printer or a mobile device.
This protocol is widely used around the world, and uses unicast or multicast transmissions, based on the User Datagram Protocol (UDP) over port 1900, to announce that a device exists or to detect the aforementioned peripherals on a network. Without this protocol, communication between equipment and peripherals would become more difficult.
An example of how this protocol works is when a UPnP printer, connected to a network and with a specific IP address, announces its services to the rest of the computers in the network a message at the multicast address. Once a device hears this discovery message from the printer, this device asks the printer for a complete description of its services. Finally, the printer responds directly with the full list.
Illustration 5. SSDP architecture diagram
The SSDP protocol has certain vulnerabilities that could allow a cybercriminal to launch a DrDoS attack on a network without much effort. Based on this protocol, this type of cyberattack is very high-impact compared to the resources used to execute it.
The functions of SSDP are to announce and discover devices using the UPnP protocol stack, a protocol that attackers seek to exploit by exploiting a vulnerability in the end-user’s query about the types of services provided, before forwarding the responses to the victim’s address.
Figure 6. Schematic diagram of SSDP attack
This attack is possible thanks to the “M-SEARCH” command, whose function is to make multicast searches on the reserved address and port (22.214.171.124:1900 in IPv4 or ff0X::c, where x I means the range of addresses to which the multicast is performed) of a search message, with a pattern or destination equal to a type or identifier for a device or service. Once the command is executed, a search is made for devices of interest on the network.
The simplicity of the cyberattack lies in the fact that an unfalsified attacker only requires one line of code to trigger it. This is why this type of attack continues to exist.
- Scanning phase: a scan of UPnP devices is performed to find amplification factors, i.e., active UPnP devices responding to the M-SEARCH request, and a list of them all is compiled.
- Attack phase: the attacker sends a spoofed multicast search packet (M-SEARCH) containing the victim’s IP address to the previous devices found. Forged M-SEARCH packets with the announcement messages “upnp: rootdevice” or “ssdp: all” are sent, and each UPnP device responds with an amplified message (the bandwidth amplification factor is up to 30.8), containing all the services it provides.
Moreover, for this type of attack, it is possible to use a botnet to ensure that the entire network is flooded, becoming totally overwhelmed by the volume of traffic it will be subjected to and causing a denial of service of the website resources.
Other consequences include loss of revenue, loss of consumer confidence or diversion of attention to steal data or install malicious software (malware).
The first step to prevent an SSDP-based DrDoS attack is to check whether an SSDP server can be used as an amplifier. To do this, observe whether any service is published on port 1900 UDP, which is the default port for SSDP. If there is, it is vulnerable, that is, it could be used as an amplifier. The following nmap command can give us the information we are looking for:
nmap -sV --script=broadcast-upnp-info <target>
The server is vulnerable if the command returns a list of network services and ports.
After you check this this, here are some recommendations to avoid being the target of, or taking part in, either an SSDP attack, via the M-SEARCH command, or a DrDoS attack:
- Block the incoming UDP port 1900 in the firewall.
- Deploy SSDP servers behind the firewall. Rules must be established in the firewall to detect and filter requests directed by user datagram protocols to the SSDP server port, as well as anti-spoofing rules for those with spoofed source IP addresses.
- Ask the Internet Service Provider (ISP) for anti-spoofing filters. ISPs have measures in place to reject SSDP traffic with spoofed addresses, not accessible via the packet’s real route. This will prevent your own SSDP server from receiving and handling requests susceptible to a DrDoS attack.
- Deploy intrusion detection and blocking systems (IDS/IPS). Security Information and Event Manager (SIEM) solutions make it possible to identify anomalies in SSDP traffic and detect them quickly to make immediate response to limit the impact of the attack.
- Set out an action protocol for SSDP DDoS incidents. Having specific guidelines on how to identify these attacks and how to act if these attacks occur is key to avoid causing further problems or failures affecting components.
- Allow ISP customers to use BGP flowspec. This would limit the speed of incoming traffic on source port UDP 1900 and alleviate congestion during large SSDP attacks.
- Keep systems updated and equipment and peripherals patched. This is how to prevent the exploitation of new or old vulnerabilities in systems.
Detection and evidence
Evidence that an SSDP server is undergoing a DrDoS attack or is taking part in a DrDoS attack against a third party can be found in unusual and heavy UDP traffic on port 1900 and the IP address “126.96.36.199:1900”, since this is the address used by SSDP to discover devices.
A protocol packet analysis application will show in detail the number of M-SEARCH requests being sent over the network, allowing to determine if the number of requests are anomalous for the equipment and the elapsed time.
For early detection, it is advisable to use device status monitoring tools that supervise the use of device resources (processor, memory, disk, etc.), since unusual consumption of server resources is further evidence to bear in mind. Alerts from IDS/IPS would also allow early detection.
Response and recommendations
If it is confirmed that a DrDoS attack on own SSDP servers is taking place, it is important to follow the pre-set incident management and action protocol for this type of attack. This protocol should include the following actions:
- Collect as much data as possible about the incident. It will be necessary to identify the source and destination IP addresses, ports and URLs from which the attack may have originated.
- Block and filter unwanted traffic. The foregoing data collection can be used to set up filtering rules on firewalls and routers to prevent requests from reaching your own SSDP servers. It is also a good idea to contact your ISP and hosting provider so that they can apply their respective filters against unauthorised traffic.
- Contact INCIBE-CERT. They will assist you in taking mitigation and recovery measures against such attacks.
Once service and communications have been restored to normal and devices are fully operational after the cyberattack, the causes of the attack should be analysed, identifying vulnerabilities and weaknesses to improve bastioning and prevention measures against a fresh attack.
Also, regardless of the impact of the cyberattack, the incident must be reported to the authorities, like any other type of technological crime, so that it can be investigated and prosecuted.