Tip

Gauging UPnP security risks: Is UPnP secure enough for enterprise use?

Much like any light switch or "on" button, the Universal Plug and Play (UPnP) protocol has been an often used, yet frequently overlooked, aspect of the end user's day-to-day utilization of network devices. UPnP, not

    Requires Free Membership to View

    Login

to be confused with the more generalized Plug 'n' Play, allows network devices to connect with one another via IP without any configuration on the part of the end user. For example, when an end user plugs a computer into an Ethernet LAN, UPnP is most likely the backbone set of protocols used for device discovery.

The most useful aspect of the UPnP protocol suite may also be its biggest vulnerability.

The concept of simply plugging something in and having it function properly without any further configuration by the end user has led to a far richer experience for the non-power user than would otherwise be realized. Unfortunately, the most useful aspect of the UPnP protocol suite may also be its biggest vulnerability. Researchers at vulnerability management vendor Rapid7 discovered that millions of end-user devices respond to anonymous UPnP discovery requests over the Internet, a simple yet profound discovery that raised awareness of the security risk posed by UPnP to consumers.

Still, enterprises were left wondering, "Is UPnP secure for us?" Let's discuss.

The UPnP security risk explained

Typically, UPnP is used in conjunction with a Dynamic Host Configuration Protocol (DHCP) server, though it does not necessarily require one. In a DHCP-centric architecture, the end user may plug in a device through whatever medium is allowed by the network, and if DHCP is enabled on said end device, the device immediately begins broadcasting Simple Service Discovery Protocol messages in the hopes of locating a DHCP server.

If a DHCP server is located, an exchange of information is performed and the end device is allocated an IP address. If a DHCP server is not located, the end device will often be configured in such a way that allows for it to autoconfigure its own IP address in a manner that does not conflict with other devices on the network that have also autoconfigured their own IP address.

When legitimate applications from the Internet attempt to enter a given network, UPnP provides port-mapping functionality that allow for these applications to properly traverse the Network Address Translation mechanisms at the firewall. This is usually done under the umbrella of the Simple Object Access Protocol, where the utilization of XML entries within HTTP messages is typically allowed to pass unquestioned. Previously thought of as a convenience rather than a vulnerability, this feature was the subject of Rapid7's research and the resulting consternation among security professionals. This consternation revolves around two primary issues.

From the editors: More on DHCP security

Does high DHCP churn carry any security implications?

Learn how to defend against rogue DHCP server malware.

First, HTTP messages are almost universally exchanged over TCP port 80. Therefore, firewalls at the enterprise level typically allow for the passage of network traffic of port 80. The reason for this de facto authorization is because most Internet-connected enterprise networks have some sort of Web server that is accessed by the general public, and therefore TCP port 80 is left open.

Second, UPnP is not a vendor-specific protocol, so any patches, mitigations or updates will not originate from some central repository and later pushed out to the masses. Mitigations will and have been released by various vendors recently, but little is known at this point with regard to issues such as backward compatibility, cross-platform functionality and overall functionality.

Bottom line: This looks like a hairy situation. From an enterprise perspective, network administrators would be wise to disable any and all UPnP functionality where feasible. So, unless an administrator's network utilizes VoIP or some other service that requires port forwarding (e.g., network address translation, SSH tunneling, etc.), disabling UPnP would go a long way toward avoiding any unnecessary risk until the networking and IT security industry's powerbrokers put their heads together and a viable fix is put forth.

About the author
Brad Casey holds an M.S. in information assurance from the University of Texas at San Antonio, and has extensive experience in the areas of penetration testing, public key infrastructure, VoIP and network packet analysis. He is also knowledgeable in the areas of system administration, Active Directory and Windows Server 2008. He spent five years doing security assessment testing in the U.S. Air Force, and in his spare time, you can find him looking at Wireshark captures and playing with various Linux distros in VMs.

This was first published in April 2013

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top