Executive Summary

Title Router devices do not implement sufficient UPnP authentication and security
Name VU#361684 First vendor Publication 2015-08-31
Vendor VU-CERT Last vendor Modification 2015-08-31
Severity (Vendor) N/A Revision M

Security-Database Scoring CVSS v3

Cvss vector : N/A
Overall CVSS Score NA
Base Score NA Environmental Score NA
impact SubScore NA Temporal Score NA
Exploitabality Sub Score NA
Calculate full CVSS 3.0 Vectors scores

Security-Database Scoring CVSS v2

Cvss vector :
Cvss Base Score Not Defined Attack Range Not Defined
Cvss Impact Score Not Defined Attack Complexity Not Defined
Cvss Expoit Score Not Defined Authentication Not Defined
Calculate full CVSS 2.0 Vectors scores


Vulnerability Note VU#361684

Router devices do not implement sufficient UPnP authentication and security

Original Release date: 31 Aug 2015 | Last revised: 31 Aug 2015


Home routers implementing the UPnP protocol do not sufficiently randomize UUIDs in UPnP control URLs, or implement other UPnP security measures.


The UPnP protocol allows automatic device discovery and interaction with devices on a network. The UPnP protocol was originally designed with the threat model of being on a private network (not available to the WAN) restricted to only authorized users, and therefore does not by default implement authentication. Later efforts developed a UPnP Security standard, but according to UPnP Forum's Device Protection standard documentation, "support and deployment of this standard has been extremely limited", due to cumbersome user experience and lack of industry buy-in of advanced features such as Public Key Infrastructure (PKI).

According to the reporter, poor adoption of the security standard may broadly open up opportunities for an attacker with private network access to guess the UPnP Control URLs for many devices currently on the market. If the guess is correct, the attacker may utilize UPnP to make changes to the home router's configuration such as opening ports and enabling services that allow an attacker further access to the network. A correct guess is likely, due to many manufacturers' use of standardized UPnP Control URL names.

Some vendors have reported that their devices randomize the UUID in the Control URL, making guessing the correct URL much more difficult, but many vendors have not taken this action. For more information, see the Vendor Information section below. It is currently unclear how widespread the deployment of UPnP security standards is in these devices.

One possible method of gaining enough access to the private network to utilize UPnP is through a DNS Rebinding attack, which is well-known in the security community. Previously, it has been reported that Flash may be utilized to gain control of UPnP.

The reporter has more information on this issue at http://www.filet-o-firewall.com.


An attacker able to gain access to the private network by enticing a user to visit a specially-crafted web page may be able to silently open ports in a user's firewall or perform other administrative actions on the gateway router.


The CERT/CC is currently unaware of a full solution to this problem. However, the following workarounds may help mitigate risks.

Do not follow unknown links

Exercise caution when following links to URLs you do not recognize.

Disable UPnP

Consider disabling UPnP services on your home network. Some users may require UPnP services on their network; if so, users must exercise judgment and weigh risks versus rewards of operating such a network. When purchasing networking equipment, consider devices that have implemented the latest UPnP standards and security.

Furthermore, if you are a developer or manufacturer of devices using UPnP, consider the following:

Randomize the UUID in the control URL

Randomizing appropriate UPnP UUIDs and URLs may help mitigate brute force attacks, but likely is not a full solution.

Implement latest UPnP standards

Consider implementing the latest UPnP standards such as Device Protection in order to provide better security to devices utilizing UPnP.

Vendor Information (Learn More)

VendorStatusDate NotifiedDate Updated
ACCESSUnknown14 Jul 201514 Jul 2015
Alcatel-LucentUnknown14 Jul 201514 Jul 2015
AT&TUnknown14 Jul 201514 Jul 2015
Avaya, Inc.Unknown14 Jul 201514 Jul 2015
Belkin, Inc.Unknown14 Jul 201514 Jul 2015
Check Point Software TechnologiesUnknown14 Jul 201514 Jul 2015
CiscoUnknown14 Jul 201514 Jul 2015
D-Link Systems, Inc.Unknown14 Jul 201514 Jul 2015
Extreme NetworksUnknown14 Jul 201514 Jul 2015
F5 Networks, Inc.Unknown14 Jul 201514 Jul 2015
Force10 NetworksUnknown14 Jul 201514 Jul 2015
GoogleUnknown19 Jun 201519 Jun 2015
HitachiUnknown14 Jul 201514 Jul 2015
Huawei TechnologiesUnknown14 Jul 201514 Jul 2015
IBM CorporationUnknown14 Jul 201514 Jul 2015
If you are a vendor and your product is affected, let us know.View More »

CVSS Metrics (Learn More)



  • http://www.filet-o-firewall.com
  • http://upnp.org/index.php/sdcps-and-certification/standards/device-architecture-documents/
  • http://www.gnucitizen.org/blog/hacking-the-interwebs
  • http://crypto.stanford.edu/dns/
  • http://blog.trendmicro.com/trendlabs-security-intelligence/protecting-your-router-against-possibl-dns-rebinding-attacks/


Thanks to Grant Harrelson for reporting this issue to us.

This document was written by Garret Wassermann.

Other Information

  • CVE IDs:Unknown
  • Date Public:31 Aug 2015
  • Date First Published:31 Aug 2015
  • Date Last Updated:31 Aug 2015
  • Document Revision:76


If you have feedback, comments, or additional information about this vulnerability, please send us email.

Original Source

Url : http://www.kb.cert.org/vuls/id/361684

Alert History

If you want to see full details history, please login or register.
Date Informations
2016-10-14 13:25:02
  • Multiple Updates
2015-09-01 00:28:32
  • Multiple Updates
2015-08-31 21:27:34
  • First insertion