Security Flaws in Universal Plug and Play: Unplug, Don't Play

KIA

KIA

Man of Honour
Joined
14 Nov 2004
Posts
13,862
This morning we released a whitepaper entitled Security Flaws in Universal Plug and Play. This paper is the result of a research project spanning the second half of 2012 that measured the global exposure of UPnP-enabled network devices. The results were shocking to the say the least. Over 80 million unique IPs were identified that responded to UPnP discovery requests from the internet. Somewhere between 40 and 50 million IPs are vulnerable to at least one of three attacks outlined in this paper. The two most commonly used UPnP software libraries both contained remotely exploitable vulnerabilities. In the case of the Portable UPnP SDK, over 23 million IPs are vulnerable to remote code execution through a single UDP packet. All told, we were able to identify over 6,900 product versions that were vulnerable through UPnP. This list encompasses over 1,500 vendors and only took into account devices that exposed the UPnP SOAP service to the internet, a serious vulnerability in of itself.

https://community.rapid7.com/commun...s-in-universal-plug-and-play-unplug-dont-play
https://community.rapid7.com/docs/DOC-2150
http://www.rapid7.com/resources/fre...ownloads/universal-plug-and-play-jan-2013.jsp
 
Comes as no great surprise.

All of these systems that are supposed to make life easier for the uninitiated always seem to turn out to be broken in some way.

Personally it's something I've always immediately disabled (along with WPS and the like).
 
Indeed. It was far too open when it was first created, nat-pmp wouldn't really have a reason to exist otherwise. Used to be enough to change the routers ip and limit devices mapping ports to only themselves to prevent software exploits :) It's largely to do with the bad presets on consumer routers and frankly poor update schedules and bad firewall rules are nothing new there.

Here's a simple summary of this (specifically for tomato routers):

The actual white paper (which contains all the technical details, source code, etc.) in PDF format is available here:

https://community.rapid7.com/docs/DOC-2150

This document covers a *lot* of problems, and that makes it very hard for any end-user to follow. I finished reading the document -- yes, in full -- and I'm aware of what the complaints are. I'll summarise them:

1. A couple of the complaints relate to routers or devices which have their UPnP daemons listening on the WAN IP and a firewall stack which is permitting inbound traffic on the WAN to UDP port 1900, as well as an arbitrary TCP port number (pertains to HTTP POST SOAP requests via UPnP).

This issue is purely the fault of bad firewall rules. Present-day TomatoUSB does not suffer from this problem. I've verified myself using a combination of iptables, lsof, and some general knowledge/familiarity with UPnP.

2. The other complaints relate to software design flaws/bugs in many UPnP implementations (and they are indeed real/true bugs). The only one that concerns TomatoUSB is MiniUPnP, which is the software used for the UPnP service/capability on present-day TomatoUSB.

These security issues were fixed in MiniUPnP 1.4(released in December 2009), and some fixed in 1.1 (released April 2008).

Present-day TomatoUSB uses MiniUPnP 1.6, which as of this writing is not known to have any issues.

3. The article also complains that the MiniUPnP version string is returned in the SSDP response -- this is true/correct, and still applies today. That response string (using tomato-K26USB-1.28.0501.2MIPSR2Toastman-RT-N-Ext.trx):

Code:
Server: UPnP/Tomato 1.28.0501 MIPSR2Toastman-RT-N K26 USB Ext UPnP/1.0 MiniUPnPd/1.6

However, there's really no problem with disclosing this string/version. In fact, the article author implies the version string has some implications, but it doesn't. It does, however, provide an easy way for an attacker who can circumvent issue #1 listed above (which TomatoUSB, as I said, is not susceptible to) to determine what version of the software you're using.

So, with regards to present-day TomatoUSB, I do not think there is any part of this disclosure we need to worry about.

Those who released the white paper also compiled a list of devices which were found vulnerable. Here's that list:

https://docs.google.com/spreadsheet/ccc?key=0ApUaRDtAei07dDhwelZDQlYyQVJhbWRtUEIwVEVyRFE#gid=0

Folks using original Tomato (as in the true original, not a fork) may be affected however -- I don't remember what MiniUPnP version is used in stock/vanilla Tomato. However, regardless of what version is used in original Tomato, UPnP SSDP is still not accessible via the WAN due to proper firewall rule configuration. :)

Source: http://www.linksysinfo.org/index.php?threads/upnp-flaw-draws-concern.67960/
 
Back
Top Bottom