Universal Plug and Play (UPnP) technology enables next-generation devices to communicate among themselves, and benefit from one another's services automatically without any user intervention. It allows a device to join the network, convey its capabilities to other devices on the network, and benefit from the capabilities of other devices on the network. UPnP makes life easier in the networking world, where the devices automatically make decisions to enhance the user experience and accomplish the task without any user intervention. For example, UPnP clients on your network can auto-detect UPnP media servers on the network, and can browse and stream media from them.
We will now look at a typical UPnP workflow:
- Initially, UPnP device joins the network and gets an IP address.
- Then, it searches for other UPnP devices on the network or notifies its presence to others.
- Once discovered, the UPnP-enabled devices will exchange details of other services to be offered and their capabilities.
- Further, if a device decides to make use of a service on another device, it sends control commands to the device following UPnP standards.
Thus, UPnP supports zero configuration networking. The lack of authentication in UPnP is a disadvantage that attracts more attacks from inside and outside the network.
Almost all the vendors of consumer and SOHO wireless devices support UPnP in their devices and by default most of the access points have UPnP enabled. Now let us look at how UPnP works and how an attacker can perform malicious activity by leveraging UPnP.
Let's look at an example of how UPnP could be leveraged on a wireless device. Assume that we are hosting a web server on a local address, say 192.168.1.10, behind an embedded NAT router. The router does have a public IP on the external side, say 210.240.234.248, which is typically provided by ISP. One of our clients needs access to the data that is hosted on the local web server from outside; in this scenario, we can provide the client with the IP of the router, which is 210.248.234.248, to access our local web server, but simply providing the IP of the router fails because whenever the router receives a packet on port 80 it does not know which host to forward the packet to. The easiest solution to this problem is port forwarding, also sometimes called port mapping; the local administrator tells the router to forward the packets received on port 80 on the external side to port 80 on the internal machine with the IP 192.168.1.10. By configuring the router this way, whatever packets are sent to port 80 on the router's public IP (external) will be routed to the local web server. Now the client can access the data that is hosted on the local web server.
If UPnP is enabled on the router, the entire process of port mapping can be done automatically without the intervention of the administrator. Instead of manually configuring the router to add a port-mapping capability, the web server will now request the router to add a port-mapping action through UPnP messages via Simple Object Access Protocol (SOAP) commands. How does the web server know that the router has the capability to port map? This is where UPnP comes into play. Behind the scenes, the web server (UPnP client or control point) sends a multicast discovery message on the network to detect UPnP-aware devices, which is known as the discovery phase in UPnP. When a UPnP server, in this case the router, receives the request, it automatically sends a response back with a device description and services it can offer. The device description and service description is in XML format at a specific location on the device; the location of the XML will be included in the response.
Control points, in this example the web server, may invoke actions on a device's services and receive results or errors back. The action, results, and errors are encapsulated in SOAP, sent via HTTP requests, and received via HTTP responses. The control URL to send SOAP commands will be provided to the client in the service description XML. The web server sends a suitable control message to the control URL for the service, in this case it is the ADDPORTMAP service to the router. The router accepts the request to add a port-mapping rule and returns a response back to the server. Thus, the entire process of port mapping is done automatically without user intervention through UPnP.
The first step in UPnP networking is discovery. When the UPnP-capable device enters into a network, it advertises its services to other devices via notify messages. Control points on the network can also search for services via MSearch messages. The exchange in both cases is a discovery messages that contains the link to the service URL and control URL of the device offering the services. After exchanging the discovery messages, each device comes to know about the capabilities of the other on the network.
Step 2 in UPnP networking is description. After a control point has discovered a device, the control point still knows very little about the device. To learn additional information about the device, control points can point to the device description URL presented to them in the initial discovery messages. The device description URL contains links to the service URL and control URL which are used to enumerate the services offered by the device.
The UPnP device description is in XML, which includes vendor-specific information like model number, serial number, and links to other resources on the vendor's website. It also contains URLs for service, control, eventing, and presentation. For each service, the description includes a list of the commands, or actions, to which the service responds, and parameters, or arguments, for each action.
The third step in UPnP networking is control. After retrieving the description of the device, the control point can send actions to a device's services. To do this, a control point sends a suitable control message to the control URL for the service provided in the device description. Control messages are expressed in XML using SOAP. They may invoke actions on a device's services and receive results or errors back.
SOAP commands perform a set of predefined actions on the device, as these SOAP commands can be issued by any UPnP client on the network. As the UPnP commands are not authenticated, there is a possibility that an attacker can send forged SOAP commands to the device. One way to deliver the forged SOAP command to the device is via CSRF; this attack will be successful only when the device is susceptible to a CSRF attack. The following code forges a UPnP request via CSRF:
<html>
<form action="http://192.168.0.1:5000/Public_UPNP_C3" method="post" ENCTYPE="text/plain">
<textarea id="1" name="1"><?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:AddPortMapping xmlns:m="urn:schemas-upnp-org:service:WANIPConnection:1">
<NewPortMappingDescription>hax3</NewPortMappingDescription>
<NewLeaseDuration>0</NewLeaseDuration><NewInternalClient>192.168.0.1</NewInternalClient><NewEnabled>1</NewEnabled><NewExternalPort>887</NewExternalPort><NewRemoteHost></NewRemoteHost><NewProtocol>TCP</NewProtocol><NewInternalPort>23</NewInternalPort>
</m:AddPortMapping>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope></textarea>
<input type="submit" >
</form>
<script> document.forms[0].submit();</script>
</html>The remaining steps in the UPnP process are Eventing and Presentation, which are used to know about the status of service and associated state variables. UPnP does not require authentication; if enabled on a WAN interface, anyone can send SOAP commands to execute on the device.
Note
Read more about UPnP here: http://elinux.org/UPnP.
Let us now take a look at some documented attacks on UPnP that have been discovered in wireless equipment.
Cisco Linksys WRT54GX with firmware 2.00.05, when UPnP is enabled, configures the SOAP server to listen on both WAN and LAN interfaces. Enabling the SOAP server on the WAN interface allows remote attackers to administer the firewall from the Internet. By using this technique, anyone from the Internet will be able to request the router to make configuration changes and allow access to the machines inside the network.
Broadcom UPnP stack on the Cisco Linksys WRT54G with firmware before 4.30.5, WRT54GS v1 through v3 with firmware before 4.71.1, allows remote attackers to send a UPnP AddPortMapping action in a SOAP request to the WAN interface. This enables the attacker to control the device's firewall through the WAN interface.
The UPnP IGD implementation in Edimax EdiLinux on the Edimax BR-6104K with firmware before 3.25 allows remote attackers to send UPnP actions via the WAN interface, related to an external forwarding vulnerability. When combined with other attacking techniques, this will add a greater advantage to the overall success of the attack.
In recent years, researchers from Rapid7 have discovered exploitable vulnerabilities in the UPnP libraries commonly used on the network devices. This discovery has put millions of devices on the Internet at risk. Exploitation does not require authentication: sending a single UDP packet to the device can potentially compromise the device.
The specifics from the CVE read as follows:
"Stack-based buffer overflow in the unique_service_name function in ssdp/ssdp_server.c in the SSDP parser in the portable SDK for UPnP Devices (aka libupnp, formerly the Intel SDK for UPnP devices) before 1.6.18 allows remote attackers to execute arbitrary code via a long UDN (aka upnp:rootdevice) field in a UDP packet."
Essentially, this affects any device running vulnerable versions of libupnp and could allow unauthenticated code execution via UPnP interfaces. This CVE incorporates three different vulnerabilities, each of which could allow the wireless device or router to be compromised.