Rapid7 study on UPnP protocol vulnerabilities

Introduction

The end of January 2013 was marked with the release of a security study by Rapid7 (author of the MetaSploit penetration testing framework) covering the security issues of implementations of the UPnP protocol.

Universal Plug and Play (UPnP) is a set of networking protocols aiming to facilitate the setup and communication between network hosts. This standard, supported by the UPnP Forum, allows different network devices to announce and discover services on a residential local area network. These services include for instance: media and content sharing, media streaming, internet gateways, etc. The standard also allows controlling them via specific requests sent to UPnP-compatible equipment.

During its study, Rapid7 drew an inventory (from June to November 2012) of all the UPnP devices visible on the Internet. The company also audited the source code of the two most popular implementations of the standard and managed to discover a whole set of vulnerabilities, some critical and allowing remote code execution on vulnerable UPnP systems with the highest privileges (root).

In this article, we first quickly introduce the reader to the internals of the UPnP protocol set. We then describe the security flaws discovered by Rapid7 company, explain their consequences, and the ways to counter them.

Presentation of the UPnP standard

UPnP is a set of protocols, and devices which integrate this technology generally support only part of all the UPnP features. The most frequent UPnP aware devices found in a local area network include:

• Residential Internet gateways (DSL boxes) which implement the UPnP “Internet Gateway Daemon” profile (IGD). UPnP IGD enables internal devices to open ports on UPnP aware gateways to allow specific incoming traffic (such as Skype or Windows remote assistant) when required.
• Media servers and renderers, which implement the UPnP “AudioVideo” profile (AV). UPnP AV allows media content sharing and playback between several connected devices.

All UPnP devices go through 2 specific phases to work:

• First, the discovery and announce of UPnP services on the network,
• And then, the use of these services.

To discover already present services or announce the local UPnP services, the UPnP standard relies on the Simple Service Discovery Protocol (SSDP). When a UPnP-compatible equipment is connected to the network, it announces its local services through a SSDP packet sent in multicast mode, and sends a search query to discover the services already connected on the network. The other peripherals then respond by sending an SSDP reply packet which describes their own services.

UPnP also relies on HTTP to achieve two functions:

• Provide further description of its services , via HTTP (the URL pointing to this description is given in the SSDP announce or reply)
• Allow remote hosts to access the announced services. This works with SOAP (Simple Object Access Protocol) over HTTP. For example, a SOAP request is sent to the UPnP IGD service to ask for a specific port forwarding.

 

Analysis of the exposure of SSDP services on the Internet

Rapid7 began its study with a data acquisition phase over a 5 month period. Their first approach was to find UPnP devices configured to reply to service discovery requests from the Internet (while this should only be possible from protected local area networks). Each routable IP address on the Internet was thus scanned by sending an SSDP discovery request. Rapid7 identified that way, 81 million devices allowing UPnP services disclosure from the Internet.

The company pursued its analysis by attempting to know if the discovered services were also controllable from the Internet by sending them HTTP/SOAP requests. Unfortunately, 17.25 million IP addresses were allowing the control of their UPnP services from the Internet!

The impact of such an exposure is huge: it is thus possible, thanks to the UPnP IGD profile, to remotely open a network port on a residential gateway and compromise the network security normally protected by the access router.

This service exposure over the Internet is generally caused by a misconfiguration of the UPnP services running on the equipment, which therefore exposes its network services to the wrong interface.

 

New vulnerabilities discovered by Rapid7 and the obsolescence of the deployed libraries

Rapid7 continued its study with a source code analysis of the two most popular implementations of the UPnP standard: libupnp and MiniUPnP. These two libraries indeed accounted for almost half of the devices found in the UPnP aware devices gathering phase.

Concerning libupnp (also known as “Portable SDK for UPnP” and previously known as “Intel SDK for UPnP”), more than half of detected hosts were running version 1.3.1 of the library, which is 6 years old, and a quarter of them were running version 1.2, which is 10 years old!

The audit of the source code for the most popular version (version 1.3.1) therefore revealed 7 buffer-overflow vulnerabilities. This may allow a remote attacker sending malicious SSDP traffic to corrupt memory, and to execute arbitrary code with UPnP process privileges. Quite often, this privileges are high because the actions they perform (such as performing a network port opening) that require high privileges.

Although it corrects many vulnerabilities, the most recent version of libupnp at the time of the study (1.6.17) still contained 2 buffer-overflow vulnerabilities. Rapid7 worked with the developer to release version 1.6.18 which fixes these 2 last flaws. However, at the time the Rapid7 study was released, almost all libupnp deployments were still vulnerable.

As a proof of concept, an exploitation code was produced by H.D. Moore (Rapid7) on February 2^nd 2013. It targets a vulnerability in libupnp up to version 1.6.17, and launches a reverse shell on vulnerable devices with the UPnP executable privileges (quite often “root”, for reasons described before).

Concerning the second most popular implementation of UPnP, MiniUPnP, Rapid7 audited the source code of the prevailing version (1.0). They discovered a vulnerability which affects the SSDP stack, and another vulnerability which affects the SOAP control stack. Both vulnerabilities have been silently fixed in 2009 with the release of MiniUPnP library version 1.4 (none of them was reported as a security fix in the release notes). While the first one only allows a denial of service of the application, the second vulnerability potentially allows the execution of arbitrary code in the same way as libupnp. Fixed since 2009, these flaws are still present on 7 out of 10 devices embedding MiniUPnP…

 

An issue difficult to address

In its report for this study, Rapid7 identified 6900 products that embed a UPnP service vulnerable to at least one UPnP flaw.

We are here facing a vulnerability affecting a massively spread component, and where it is the responsibility of vendors which uses this vulnerable component in their products to react promptly. While few editors seem to be reacting quickly (such as the Debian project with the release of a security fix described in CERT-IST AV-2013-095), we can unfortunately think that a lot of devices will remain unpatched for a long time, leaving their users unprotected. In such situations, the only solution is to disable UPnP features, or replace the device if UPnP cannot be disabled.

 

A protocol which remains vulnerable

Beyond the possible misconfiguration of the UPnP daemons running on a device (which is then bound to the wrong interface) and the discovery of security flaws in its implementation, the UPnP standard is inherently weak from the security point of view: no mechanism allowing the authentication or encryption of the exchanges (discovery and control) was designed in the standard. Even if the service is only listening on secure network interfaces, it is still possible for instance for a malware already present on the network to ask for a port opening on the residential router/firewall.

In 2008, the Flash UPnP attack showed this scenario was possible, and it reasonable to assume that other malwares are also capable to implement the same attack,  and therefore to bypass any firewalling feature implemented on the UPnP residential router. This results in the internal computers to be exposed to direct attacks from Internet.

 

Conclusion

The Rapid7 study and its communication about the UPnP vulnerabilities are interesting by several aspects:

• Although a protocol implementation may be up to date in terms of security fixes, one cannot exclude that a misconfiguration may exist in a component which integrates it. In the UPnP case, the SOAP service exposure on the Internet induces the ability for a remote attacker to control services on the device.
• Although fixes for known vulnerabilities exist, some editors are slow in integrating them in their software.  These UPnP vulnerabilities affect a large set of products, including customer products that were not designed to be updated.

We believe it is worth reminding that even if it is possible to fix these implementation or configuration vulnerabilities, the UPnP standard present security weaknesses inherent to its design. These weaknesses are known for a long time, and were already discussed in security-related works such as Armijn Hemel’s (founder of UPnP-Hacks.org) paper in the SANE-2006 conference, or Dror Shalel’s DEFCON15 presentation (in 2007). This is in particular the reason why UPnP is not wide-spread in enterprise networks.

For more information

·         Announcement for the publication of the UPnP research project on Rapid7 blog