SIMPLE SERVICE DISCOVERY PROTOCOL BASED DISTRIBUTED REFLECTIVE DENIAL OF SERVICE ATTACK

SIMPLE SERVICE DISCOVERY PROTOCOL BASED DISTRIBUTED REFLECTIVE DENIAL OF SERVICE ATTACK Gursewak Singh 1, Bohar Singh 2 1 Computer Science and Application, Govt College Sri Muktsar sahib 2 Computer Science and Application, Govt College Sri Muktsar sahib, Abstract In today s digital world information about everything is available online with just one click. This kind of environment is created due to high demand of quick services with least possible effort and with this effort comes the threat of security and privacy breach. Denial of Service (DoS) attack is an attempt to make a machine or network resource unavailable to its intended user. A DoS attack generally consist of efforts to temporarily or indefinitely interrupt or suspend services of a host connected to the Internet. DDoS attack consists of attack on a target from multiple compromised sources. With the rapid increase in number of network devices, the potential power of a DRDoS attack using SSDP devices grows tremendously. This paper describes the potential power of a SSDP based DRDoS attack when using network devices as a reflector. In this paper we describe SSDP message format, SSDP message command and how SSDP works with UPnP standard in which device can dynamically join a network to obtain an IP address and convey its capabilities upon request. Attackers abuse this SSDP protocol to launch DRDoS attacks that amplify and reflect network traffic to their targets. This paper also describes how this type of attack can be prevented. Keywords Universal Plug and Play(UPnP), Simple Service Discovery Protocol(SSDP), Distributed Reflection Denial of service(drdos), m-search I. INTRODUCTION 1. Denial of Service(DoS) Attack: Now a days Denial of Service (DoS) type attacks are major problem which are designed to deplete resources so that other users or computer are unable to use the resources. Denial of Service attacks are of two types: Distributed Denial of Services (DDoS) attack and Distributed Reflective Denial of Service (DRDoS) attack. 1.1. Distributed Denial of Services (DDoS) attack: In a Distributed Denial of Service (DDoS)[3] attack, the attacker makes a more impact on the victim by having multiplied power of attack derived by a large number of computer agents. The attackers make this possible through making a large number of computer machines under his control over the internet before applying an attack. In fact, these computers are vulnerable in the public network and the attacker exploits their weaknesses by inserting malicious code or some other hacking technique so that they become under the control of the attacker. 1.2. Distributed Reflective Denial of Service (DRDoS) attack: Distributed Reflective Denial of Service (DRDoS) [4]attack is a more sophisticated type of DOS attacks. It uses legitimate hosts called reflectors to flood the victim by making slaves spoof the victim s address. A reflector may be any IPhost that will respond to other request messages, like SYN, SYN/ACK, ICMP request, DNS queries and so on. In the procedure of DRDoS attack an attacker first controls some zombies (machines or nodes) and locates a large number of reflectors. Then it sends attack commands to master zombies. When received attack commands, the master zombies let slaves send request packets with victim s address to the reflectors and the reflectors will send response packets to the DOI: 10.23883/IJRTER.2017.3549.ZAF08 143

victim based on the forged source addresses in those request packets. At last, victim is flooded by the numerous unsolicited response packets. 2. Simple Service Delivery Protocol (SSDP) SSDP is a network protocol based on the Internet Protocol Suite for advertisement and discovery of network services. SSDP[1] comes enabled on millions of home and office devices including routers, media servers, web cams, smart TVs and printers to allow them to discover each other on a network, establish communication and coordinate activities. SSDP permits networked devices, such as personal computers, printers, Internet gateways, Wi Fi access points and mobile devices to seamlessly discover each other's presence on the network and establish functional network services for data sharing, communications and entertainment. Attackers have been abusing SSDP to launch DRDoS attacks that amplify and reflect network traffic to their targets. The protocol is usually enabled in home network devices such as wireless access points, cable modems and gaming consoles. The Simple Object Access Protocol (SOAP) is used to deliver control messages to Universal Plug and Play devices and pass information back from the devices. Attackers have discovered that SOAP request scan be crafted to elicit a response that reflects and amplifies a packet, which can be redirected towards a target. By employing a great number of devices, attackers create large quantities of attack traffic that can be aimed at selected targets. Distributed Reflective Denial of Service (DRDoS) Attacks based upon Simple Service Discovery Protocol (SSDP) are continue to rise as compared to other protocols. It uses the User Datagram Protocol (UDP) as the underlying transport protocol. Services are announced by the hosting system with multicast addressing to a specifically designated IP multicast address 239.255.255.250 at UDP port number 1900. SSDP is the basis of the discovery protocol of Universal Plug and Play and is targeted for use in residential or small office environments. This Protocol is the part of the Universal Plug and Play (UPnP) Protocol standard. 2.1 Universal Plug and Play (UPnP) standard UPnP standard is the architecture for peer-to-peer (P2P) network connectivity of intelligent appliances, wireless devices, and PCs of all form factors. Although it s introduced as an extension to the plug and play peripheral model, UPnP is more than a simple extension to it. In UPnP[8], a device can dynamically join a network, obtain an IP address, convey its capabilities upon request, and learn about the presence and capabilities of other devices. Finally, a device can leave a network smoothly and automatically without leaving any unwanted state behind. The technologies leveraged in the UPnP architecture include Internet protocols such as IP, TCP, UDP, HTTP, and XML. Using Internet protocols is a strong choice for UPnP Device Architecture because of its proven ability to span different physical media, to enable real world multiple-vendor interoperation, and to achieve synergy with the Internet and many home and office intranets. @IJRTER-2017, All Rights Reserved 144

Figure 1:UPnP Protocol Stack At the highest layer, messages logically contain only UPnP vendor-specific information about their devices. Two general classifications of devices are defined by the UPnP architecture: controlled devices (or simply devices ), and control points. A controlled device functions in the role of a server, responding to requests from control points. Both control points and controlled devices can be implemented on a variety of platforms including personal computers and embedded systems. Multiple devices, control points, or both may be operational on the same network endpoint simultaneously. According to the latest specification UPnP Networking contains following five steps Discovery: Description: Control: Eventing: Presentation 2.2 SSDP message format SSDP uses part of the header field format of HTTP 1.1 as defined in RFC 2616. However, it is not based on full HTTP 1.1, as it uses UDP instead of TCP, and it has its own processing rules. This section defines the generic format of a SSDP message. SSDP messages must have a start-line and a list of message header fields. SSDP messages should not have a message body. If a SSDP message is received with a message body, the message body may be ignored. 2.2.1 SSDP Start-line Each SSDP message MUST have exactly one start-line. The start-line must be one of the following three: NOTIFY * HTTP/1.1\r\n M-SEARCH * HTTP/1.1\r\n HTTP/1.1 200 OK\r\n 2.2.2 SSDP message header fields This specifies that each message header field consist of a case-insensitive field name followed by a colon (":"), followed by the case-sensitive field value. 2.2.3 SSDP header field extensions UPnP working committees and UPnP vendors are allowed to extend SSDP messages with additional SSDP header to prevent name-clashes of header field definitions vendor-defined header field names must have the following format: Field-name = token. domain-name, where the domain-name must be Vendor domain name. @IJRTER-2017, All Rights Reserved 145

2.2.4 UUID format UUIDs are 128 bit numbers that MUST be formatted as specified by the following grammar. UUID = 4 * <hexoctet> - 2 * <hexoctet> - 2 * <hexoctet> - 2 * <hexoctet> - 6 * <hexoctet hexoctet = <hexdigit><hexdigit> hexdigit = 0 1 2 3 4 5 6 7 8 9 a b c d e f A B C D E F The following is an example of the string representation of a UUID: 2fac1234-31f8-11b4-a222-08002b34c003 II. WORKING OF SSDP Discovery process is the first step in UPnP protocol and is conducted by SSDP. When a new control point (control point in figure 2) is added to the network, it may multicast a discovery message searching for interesting devices, services, or both. All devices must listen to the standard multicast address for these messages and must respond if any of their root devices, embedded devices or services matches the search criteria in the discovery message. In addition, a control point may unicast a discovery message to a specific IP address on port 1900 or service at that specific IP address. This action presumes the control point already knows the device at this IP address is a UPnP 1.1 device (which listens on the appropriate port). The control point can use unicast search for a number of applications. A unicast search can quickly confirm a specific device and provide the corresponding discovery information of this device. All devices must listen to incoming unicast search messages on port 1900 and must respond if any of their root devices, embedded devices or services matches the search criteria in the discovery message. A multi-homed control point may multicast discovery messages on one, some or all of its UPnPenabled interfaces. Multi-homed devices must listen to the standard multicast address on all UPnPenabled interfaces for multicast discovery messages. Multi-homed devices must also listen to incoming unicast search messages on port 1900. The devices must respond if any of their root devices, embedded devices or services matches the search criteria in the discovery message. Figure 2: SSDP working process @IJRTER-2017, All Rights Reserved 146

When a device (say Root device 1) is removed from the network i.e. becomes unavailable to the network on any of its UPnP enabled interfaces, it should, if possible, multicast a number of discovery messages revoking its earlier announcements, effectively declaring that its root devices, embedded devices and services will no longer be available. When the IP address of a device is changed, it should revoke any earlier announcements and it must advertise using the new IP address. If it remains available to the network on any of its other UPnP-enabled interfaces, it must not multicast such discovery messages on the unaffected UPnP-enabled interfaces. Similarly, when one of the IP addresses of a multi-homed device is changed, it should revoke any earlier announcements on the previous IP address. SSDP Discovery Process divided into two process SSDP advertisement process and SSDP search process. 2.1 SSDP Advertisement Process When a device is added to the network, the device advertises its services to control points. It does this by multicasting discovery messages to a standard address and port (239.255.255.250:1900). Control points listen to this port to detect when new capabilities are available on the network. To advertise the full extent of its capabilities, a device MUST multicast a number of discovery messages corresponding to each of its root devices, embedded devices and services. Each message contains information specific to the embedded device (or service) as well as information about its enclosing device. Message must include duration until the advertisements expire; if the device remains available, the advertisements must be re-sent (with new duration). If the device becomes unavailable, the device should explicitly cancel its advertisements, but if the device is unable to do this, the advertisements will expire on their own. If a multi-homed device becomes unavailable on some but not all, of its UPnP-enabled interfaces, the device should explicitly cancel its advertisements on the affected UPnP-enabled interfaces but not on the unaffected UPnP-enabled interfaces. UPnP vendor UPnP Forum UPnP Device Architecture SSDP UDP IP Figure 4: Advertisement protocol stack At the highest layer, discovery messages contain vendor-specific information, e.g., URL for the device description and device identifier. Moving down the stack, vendor content is supplemented by information from a UPnP Forum working committee, e.g., device type. Messages from the layers above are hosted in UPnP-specific protocols, defined in this document. In turn, the SSDP messages are delivered via UDP over IP. SSDP uses port 1900 for M-SEARCH requests and for Notify messages various Types of messages used by SSDP are given below. 2.1.3 NOTIFY with ssdp:alive When a device is added to the network, it must multicast SSDP notify messages to advertise its availability of root device, any embedded devices, and any services. An SSDP Notify header contains the following four main fields: @IJRTER-2017, All Rights Reserved 147

Host Packet destination, multicast IP address: 239.255.255.250. Cache-Control The TTL of the notified services. It specifies the duration for which the advertisement is valid USN (Unique Service Name): A composite identifier for the advertisement. Location Reference to the UPnP device service description, also known as UPnP root device description. NT, NTS Presents the notify type (or notify subtype). For example, UPnP devices on startup use the SSDP notify type NTS:ssdp:alive, and on shutdown use notify NTS:ssdp:byebye. 2.1.3 NOTIFY with ssdp:byebye When a device and its services are going to be removed from the network, the device should multicast an ssdp:byebyemessage corresponding to each of the ssdp:alivemessages. If the device is removed abruptly from the network, it might not be possible to multicast a message. 2.1.3 NOTIFY with ssdp:update When a new UPnP-enabled interface is added to a multi-homed device, the device must increase its BOOTID.UPNP.ORG field value, multicast an ssdp:updatemessage for each of the root devices, embedded devices and embedded services to all of the existing UPnPenabled interfaces to announce a change in the BOOTID.UPNP.ORG field value, and re-advertise itself on all (existing and new) UPnP-enabled interfaces with the new BOOTID.UPNP.ORG field value. 2.2 SSDP SEARCH PROCESS When a control point is added to the network, the UPnP discovery protocol allows that control point to search for devices of interest on the network. It does this by multicasting on the reserved address and port (239.255.255.250:1900) a search message with a pattern, or target, equal to a type or identifier for a device or service. Responses from devices contain discovery messages essentially identical to those advertised by newly connected devices; the former are unicast while the latter are multicast. Control points can also send a unicast search message to a known IP address and port 1900. SSDP Search Protocol is same as Advertisement protocol. Search requests are delivered via multicast and unicast SSDP messages and search responses are delivered via a unicast SSDP messages defined. Search request with M-SEARCH When a control point desires to search the network for devices, it must send a multicast request with method M-SEARCH in the following format. Control points that know the address of a specific device may also use a similar format to send unicast requests with method M-SEARCH. SSDP M- SEARCH header contain the following two main fields: Host Destination, multicast IP address: 239.255.255.250. ST Search Target. Represents the type of service we search. Search Response To be found by a network search, a device must send a unicast UDP response to the source IP address and port that sent the request to the multicast address. Devices respond if the ST header field of the M-SEARCH request is ssdp:all, UPnP:rootdevice, uuid: followed by a UUID that exactly matches the one advertised by the device, or if the M-SEARCH request matches a device type or service type supported by the device. Multi-homed devices must send the search response using the same UPnP-enabled interface on which the search request was received. The URL specified in the LOCATION field value must specify an address that is reachable on that interface. Responses to M-SEARCH requests are intentionally parallel to advertisements, and as such, follow the same pattern as listed for NOTIFY with ssdp:alive (above) except that instead of the NT header field there is an ST header field here. @IJRTER-2017, All Rights Reserved 148

III. HOW SSDP BASED DRDOS ATTACK IS PERFORMED SSDP uses Simple Object Access Protocol (SOAP) to deliver control messages to UPnP devices and pass information back from the devices. Attackers have discovered that SOAP requests can be crafted to elicit a response that reflects and amplifies a packet, which can be redirected towards a target. By employing a great number of devices, attackers create large quantities of attack traffic that can be aimed at selected targets. The SSDP attack perform in two phases Scan Phase Attack phase Figure 4: SSDP Attack using spoofed M- SEARCH 3.1 Scan Phase First, the attacker conducts a scan for UPnP devices in order to find amplification factors. For this attacker sends an M-SEARCH request to UPnP devices and sets ST (search target) to ssdp:all (searching for all devices and services). Considering the number of UPnP devices exploitable around the globe, it is easy to see that such a reflection DDOS attack would have a huge impact on the Internet. Next, the attacker generates a list of active UPnP devices that respond to the attacker's M- SEARCH request. 3.2 Attack phase After gathering a list of vulnerable devices, the attacker sends a spoofed UDP M-SEARCH packet (containing the IP address of the victim) to the various devices found. The spoofed M-SEARCH packets with an ssdp:rootdevice or ssdp:all is sent and each UPnP device replies with an amplified answer (with a bandwidth amplification factor of up to 30) that contains all the services it provides. The attacker will send malicious requests to cause a reflected and amplified response to the attacker s target. The size of the response and amplification factor may vary depending on the contents of the device description file, such as response header, banner, operating system and UUID. 3.3Amplification factor As a measure of amplification, the bandwidth amplification factor (BAF) and packet amplification factor are used. Formulas for calculating BAF and PAF shown below: BAF = Number of UDP payload bytes that are sent by the server to the victim (response)/number of UDP payload bytes that are sent by the attacker to the server (request) PAF = Number of IP packets that are sent by the server to the victim (response)/number of IP packets that are sent by the attacker to the server (request) @IJRTER-2017, All Rights Reserved 149

IV. PREVENTION OF SSDP BASED DRDOS ATTACK The mitigation of this attack vector is complicated because of the very large numbers of vulnerable devices and their geographical distribution. But there are some recommendations for system hardening against SSDP based DRDOS Attack. One recommendation is to block source port 1900 traffic to your host to prevent bandwidth loads to services that do not use UPnP service, such as web hosting or possible exploitation attacks. If not needed, block wide area network (WAN) based UPnP requests to client devices, or do not allow UPnP access from the Internet at all. Disable UPnP services on devices where it is not a functional requirement. Proactively patch and update UPnP devices that are required to be open to the Internet. V. CONCLUSION SSDP is a protocol which allows various types of network devices like computers, printers, Wi-Fi access points etc. to discover each other on the network in order to establish functional network services for the data sharing, communication and entertainment. Attackers abuse this protocol to launch DRDoS attacks that amplify and reflect network traffic to their targets. With the enhancement in the Internet technology, where any smart connected device with a public IP address and operating system will contribute in increasing the number of devices that could be used to launch SSDP based reflection attacks. Many of these devices have Universal Plug and Play (UPnP) protocol enabled by default, which relies upon SSDP for its working, and hence leads to sharp and continued rise in SSDP based attacks. The mitigation of SSDP based DRDoS Attack is complicated because of very large numbers of vulnerable devices and their geographical distribution. So there is an urgent need to harden the protocols and their implementations to protect at least the most severe services affected by these attacks. In order to deal with the SSDP based DRDoS attack; there should be a multilayered defense that integrates protection against this higher magnitude volumetric attack. Only then an organization will be fully protected from these attacks. REFERENCES I. T. Cai, P. Leach, Y. Gu, Y. Y. Goland, and S. Albright. Simple service discovery protocol/1.0. Internet Engineering Task Force \http://tools.ietf.org/html/draft-cai-ssdp-v1-01", 1999 J II. M.-k. Choi, R. J. Robles, C.-h. Hong, and T.-h Kim. Wireless network security: Vulnerabilities, threats and countermeasures. International Journal of Multimedia and Ubiquitous Engineering,3(3):77-86, 2008. III. J. Czyz, M. Kallitsis, M. Gharaibeh, C. Papadopoulos, M. Bailey, and M. Karir. Taming the 800 pound gorilla: The rise and decline of ntp DDoS attacks. In Proceedings of the 2014 Conference on Internet Measurement Conference, pages 435-448. ACM, 2014. IV. M. Kuhrer, T. Hupperich, C. Rossow, and T. Holz. Hell of a handshake: Abusing tcp for reflective amplification DDoS attacks. In 8th USENIX Workshop on Offensive Technologies (WOOT 14), 2014. V. J. Mirkovic and P. Reiher. A taxonomy of DDoS attack and DDoS defense mechanisms. ACM SIGCOMM Computer Communication Review, 34(2):39-53, 2004. VI. D. Perakovi c, M. Periˇsa, and I. Cviti c. Analysis of the iot impact on volume of DDoS attacks. In PosTel 2015, 2015. VII. J. Postel. Rfc 768: User datagram protocol, august 1980. Status: Standard, 1980. VIII. A. Presser, L. Farrell, D. Kemp, and W. Lupton. Upnp device architecture 1.1. In UPnP Forum, volume 22, 2008. IX. Yonghui Li, Y. W. (2011). Traceback DRDoS Attacks. Journal of Information & Computational Science, 94-111. X. Helal, C. L. (2002). PROTOCOLS FOR SERVICE DISCOVERY IN DYNAMIC AND MOBILE NETWORK. International Journal of Computer Research, 11, 1-12. XI. N. Hoque, M. H. Bhuyan, R. C. Baishya, D. Bhattacharyya, and J. K. Kalita. Network attacks: Taxonomy, tools and systems. Journal of Network and Computer Applications, 40:307-324, 2014 XII. C. Rossow. Amplification hell: Revisiting network protocols for DDoS abuse. In NDSS, 2014. @IJRTER-2017, All Rights Reserved 150