The Problem With Universal Plug and Play

The Problem With  Universal Plug and Play(UPnP) 

Allowing legitimate programs to alter your router settings as they need makes Joe User's life much easier - unfortunately, it also makes Joe Hacker's life easier, too. In order for UPnP to be truly "plug-n-play", there is no authentication built into the protocol; any program can use UPnP to alter a router's (or other UPnP device's) settings. 

At the beginning of this year, PDP (of GNUCITIZEN fame) published research he had performed regarding the security of UPnP. While security problems with UPnP are nothing new, it is a protocol that is normally only run inside a LAN, forcing an attacker to infiltrate the network before exploiting any UPnP vulnerabilities. However, PDP showed that it was possible to use Flash to send UPnP requests from within a client's browser to a UPnP enabled router and change the router's firewall settings. Given that the Flash file can be embedded inside a malicious page, or injected into a trusted page via XSS or SQL injection, an attacker could leverage this to remotely alter a router's configuration. What's worse is that in most cases, these configuration changes are not reflected in the router's administrative interface, leaving the victim completely un-aware that anything has happened. 

Of course, for wireless networks UPnP is dangerous even without the Flash attack, as an attacker can maintain physical distance from the network while still gaining access to the internal network. Once inside, he can begin altering the router's configuration settings via UPnP. 

How Serious is This? 

The seriousness of this attack depends on the UPnP implementation used by the router, as well as the router's configuration. For example, the configuration-altering Flash attack described above has to guess what a router's IP address is; this is usually fairly predictable, but some routers also assign themselves their own host names which takes any IP address guess work out of the picture. However, even if a router does not resolve to a host name, security through obscurity is not good practice, and simply changing a router's default IP address should not be considered a sufficient defense against such an attack. 

In addition, some UPnP implementations are at more risk than others; several UPnP-enabled IGDs allow the DNS settings to be directly altered via UPnP, which is just begging for a MITM/phishing attack. Still others, particularly those devices that use some form of embedded Linux, actually use the un-sanitized values they receive via UPnP requests as part of executed shell commands, leaving them open to command-injection attacks. A list of some known vulnerable routers can be found here. 

OK, so let's say that no host name resolves to the router IP, and its UPnP implementation is not vulnerable to DNS-hijacking or command injection. Unfortunately, we're not out of the woods yet; remember that the most common use of UPnP is to open up ports on a router. Because of this, almost all routers that support UPnP also support the AddPortMapping action; this essentially allows a device or piece of software to tell a router "forward traffic coming to port X on the WAN to internal host Y who is listening on port Z". Well what if we forward traffic from port 8080 on the WAN to yahoo.com on port 80? I know, I know, yahoo.com isn't an internal host! But some UPnP implementations don't verify that they are forwarding to an actual internal host, thus allowing an attacker to bounce his traffic through the router. Further, if the attacker knows the router's internal IP or host name, he may be able to forward any port on the WAN side of the router to port 80 on the LAN side of the router, effectively opening up the router's administrative interface to the world. 

An Overview of the UPnP Protocol 

The UPnP protocol uses a multicast address of 239.255.255.250 and TCP port 1900. Devices that offer UPnP services will periodically send out SSDP NOTIFY messages to 239:255:255:250:1900, announcing themselves to any UPnP clients that are listening. If you watch the traffic on your LAN with a UPnP router attached, you will likely notice that it sends out a burst of SSDP NOTIFY messages every few seconds; this is because most routers actually advertise themselves as multiple UPnP devices, and send one notification per device type. 

Likewise, UPnP clients can send SSDP M-SEARCH requests to 239:255:255:250:1900 to see if any UPnP devices respond. Clients can send an M-SEARCH request looking for any UPnP device, or they can specify that they are looking for a particular UPnP device, or they can query only for a device that supports a specific UPnP service. UPnP hosts that match the devices/services requested will respond with a SSDP RESPONSE message, which contains the same information sent in an SSDP NOTIFY message. 

An SSDP NOTIFY message sent by a UPnP host contains a 'Location' header which specifies the location of an XML file. This file contains XML data indicating, among other things, the UPnP device type(s) and services supported by the host, as well as paths to additional XML documents that describe the various services in detail. In order to discover the full UPnP capabilities of an IGD, you must parse through all the XML files to extract the devices types, services, and actions offered by the IGD. 

UPnP devices support various services that advertise what actions they support. A UPnP client can send a UPnP device an action request at any time; this could be a request to open up a port, change the default DNS server, or anything else that the UPnP device supports. Input/output data for action requests and responses are sent using SOAP, which uses XML to structure information sent between two parties. SOAP requests are essentially HTTP POST requests with some additional SOAP headers included in the HTTP headers. 

Auditing UPnP Devices Manually 

To discover if a router supports UPnP, you can go to the router's administrative interface and check to see if there is an option to enable/disable UPnP; while most routers have UPnP enabled by default, some do not. 

To actually audit a device's UPnP configuration, you can fire up Wireshark and look for SSDP NOTIFY packets being sent to the multicast address of 239.255.255.250 on port 1900; these notifications will be UPnP devices announcing themselves to the network. Once the SSDP NOTIFY messages are captured, you can examine Wireshark's dump of the SSDP headers to obtain the location of the root XML file. Once you retrieve that file (simply via an HTTP GET request), you can examine it to see what devices and services the UPnP host supports. Then, you can request additional XML files from the host (one file for each service) and parse those XML documents to determine what actions each service supports, and then correlate any related state variables (input/output variables) used for each action, as well as identifying which variables are used for input, and which are used for output (one action may use one variable as an input parameter, while another uses the same variable as an output parameter). 

Obviously, auditing UPnP hosts manually can become extremely time consuming and forces us to manually generate SSDP requests to UPnP devices in order to run UPnP actions against them. Using a tool to automate the process makes life much easier.