The UPnP protocol has a long standing history of security problems, not the least of which being that it allows unauthenticated devices to connect to and through your home network.
TLDR; UPnP is a flawed protocol which has been leveraged numerous times to conduct widespread attacks via large numbers of insecure devices. Do not enable UPnP on your network. Or do, but understand the potential consequences of your decision.
The rest of what follows is a rant/opinion/soapbox based on a number of years of experience in the real world of IT Security and Risk Analysis, and the cumulative research on the subject that goes with such.
Setting the Scene
In the past, I have been in the fortunate position to advocate for devices to be shipped in a known secure state with insecure options switched off by default. Some manufacturers (and/or ISPs) unfortunately opt for what is easiest for the consumer (or the company help desk), rather than what presents the device in the best secured state.As an analogy, consider the humble motor vehicle. As a driver, I do not understand (nor care about) the technical aspects of the traction control system. I know (and expect) that the car comes with TCS turned on by default, and a switch which allows me to turn it off (assumably for something more noble than having a bit of fun in a wet, empty car park). Why do we expect (or accept) less from the devices that protect our digital lives and memories?
When providing devices to a market of consumers who lack the technical knowledge to make appropriate decisions regarding security, I believe the moral obligation falls upon the provider to ensure the consumer is protected (from their lack of knowledge).
Devices should ship in a known secure state. If this condition is able to be satisfied, then the consumer themselves can take action to change the configuration to less secure options (after being notified of the potential consequence of their actions). I was therefore unimpressed (but unsurprised) when my teenage son began asking for UPnP to be turned on so he could resolve the connection problems he was having with the Xbox Live service.
UPnP – A History
‘Universal Plug and Play‘ (UPnP) was devised as a simple method by which networked devices could discover each other and establish useful service connections using any of a range of other protocols. Put simply, UPnP was designed to make connecting bits of home/small office equipment a lot easier than it was. This is a good thing, consumers of products want to use their stuff, not spend hours (or days) trying to coax it to work on their infrastructure.
Released as ISO/IEC 29341 in 2008, UPnP had been causing problems for its creators long before then. In fact, in 2001, the FBI, on the back of a Microsoft Security Bulletin ‘strongly recommended’ that users disabled Windows Universal Plug n’ Play Support an opinion they later reversed, despite the vulnerabilities remaining unresolved.
The problem was, UPnP (by default) has no authentication model. In 2001 it was highlighted as problematic, yet it was 2003 before any device security services were standardised and 2011 before a device protection model was standardised. No authentication model meant that any UPnP enabled device would happily accept communication from any source, because it considers all other devices (and users) to be trustworthy.
Unfortunately, other devices (and users) are not trustworthy, and years on UPnP vulnerabilities are still being discovered and exploited in such devices as security DVRs (wait.. security DVRs?!) – yup, ‘fraid so.
Back in 2001 the first attacks (or more accurately, the first reports of vulnerabilities) began. eEye Digital Security (now ‘BeyondTrust’) released it’s findings of “major security vulnerabilities” in Windows XP detailing three vectors of attack;
- remotely exploitable buffer overflow,
- Denial of Service (DoS), and a
- Distributed Denial of Service (DDoS) attack.
In 2003 Björn Stickler managed to get a netgear router to spit out its WAN connection username and password without any authentication, by using UPnP.
By 2006, UPnP was providing some excellent fodder for research. Armijn Hemel, the author of that research paper (awarded best paper in the conference), went on to create the site upnp-hacks.org to continue to highlight the issues with the protocol. In fact, he called it back in 2008 when picked routers as being the next soft underbelly to be targeted by crackers.
Possibly the most noted work on UPnP was authored by Daniel Garcia, and presented in 2011 at Defcon 19 (PDF “UPnP Mapping”) where he showed devices accepting UPnP requests over the WAN (Internet facing) interface which then allowed connection to internal hosts and the proxy of connections back out to the Internet. Security firm Rapid7 conducted a scan of all possible IPv4 addresses and discovered millions of networked devices that could be compromised remotely with a single data packet.
Turning off UPnP
To be fair, the researchers working on the vulnerabilities are practicing responsible disclosure, so that by the time their findings are released, the affected vendors have been allowed an appropriate amount of time to respond and mitigate the issues. However, not all manufacturers provide much of a lifecycle for their products so firmware or software updates may cease to be available long before the end of the usable life of the product.
For this reason, and because one cannot know that all vulnerabilities have been discovered (or reported), it is often safest to simply turn off UPnP and create your own port mappings. A port mapping, simply put, is a rule to direct traffic to (or from) the devices that need it.
At the very least, you should disable UPnP actions from being executed on WAN facing interfaces.
You can check your devices here, and test them by running any of a number of scanning tools such as Gibson Research Corporations ‘Shields Up’, or Rapid7’s ‘Router Security Check’. Within your network, ‘ScanNow’ will look for any devices still responding to UPnP directives.
As above, the best option is to disable UPnP and take control of your network (and its devices) by opening required ports and protocols and directing traffic to statically mapped equipment.
There are a number of resources to help with this, one of which being Port Forward but for the most part, device manufacturers are getting on board and providing instructions as to how to open ports or direct traffic. Software and service providers are also making instructions available to configure what is required to provide the connectivity.