UPnP or Universal Plug and Play is a technology developed by the UPnP Forum in 1999. It is mainly designed for seamless interaction of devices, hence the name of "Plug and Play". It is grouped by smaller set of protocols designed for specific steps taken by UPnP. UPnP works with a combination of SSDP,HTTP,SOAP,XML and GENA.
IGD or Internet Gateway Device, is a specific part of the UPnP standard dedicated for seamless interaction between networking/connectivity devices. UPnP IGD devices allow LAN
equipments to do a number of "actions" or commands to be executed. The most common actions available are:
SetConnectionType
GetConnectionTypeInfo
ConfigureConnection
RequestConnection
RequestTermination
ForceTermination
SetAutoDisconnectTime
SetIdleDisconnectTime
SetWarnDisconnectDelay
GetStatusInfo
GetLinkLayerMaxBitRates
GetPPPEncryptionProtocol
GetPPPCompressionProtocol
GetPPPAuthenticationProtocol
GetUserName
GetPassword
GetAutoDisconnectTime
GetIdleDisconnectTime
GetWarnDisconnectDelay
GetNATRSIPStatus
GetGenericPortMappingEntry
GetSpecificPortMappingEntry
AddPortMapping
DeletePortMapping
GetExternalIPAddress
Since UPnP is made for seamless interaction, it has no authentication for the requests. On IGDv2 there are more security measures implemented, with a new device dedicated for security, but I have not interacted with
a lot of IGDv2 stacks. These actions or commands are easily executed on a machine from the LAN. The security risks of UPnP behaving this way by only accepting requests from the LAN is not perfect, but at least more acceptable.
Although it still could lead to other problems, like the GNUCITIZEN attack. UPnP works through a series of steps that include multicast/udp packets and unicast udp/tcp packets. The initial steps for the discovery of devices
rely on SSDP(Simple Service Discovery Protocol) which rely on multicast. The discovery points to a XML description file that describes the IGD device with different services for the device. This XML description is fetched using
HTTP packets, which goes to the second stage of the UPnP interaction and relying on unicast traffic.
There are some(too many, approx >30 million in 2012) devices in the wild that allow the execution of IGD actions through their WAN interface. It is easy/trivial to execute the actions mentioned above. Sometimes, even if the stack doesn't allow the execution of actions, there could be information disclosure issues.
No, far from it. But there are a lot of stacks out there in the open. Some stacks have provided fixes through firmware that block requests or at least don't allow execution of actions. Some stacks provide the functionality of enabling or disabling requests from WAN ports, but some ISP's use default configuration files that enable these actions by default on the WAN.
Broadcom and Speedtouch/Thomson/Technicolor, Although Armijn Hemel listed it as not posing a big threat, a lot of the speedtouch/thomson devices do accept WAN UPnP requests. RomPlug from Allegrosoft(Rompager), which is the most common stack in the wild, is not vulnerable.
There is was a live counter on the main page.
Umap is a tool designed for the scanning and execution of actions for UPnP devices on the WAN side. It scans for XML description files on specific common ports and tries to execute actions on the devices it finds. It acts as a TCP scanner for the LAN network of open UPnP devices and as a socks proxy that automatically requests portmappings and pipes data through.
Umap is very beta right now, it still needs tons some coding and some fixing. Here are some common issues:
-It says it's scanning, but its not doing anything: It is doing something, it's just not reporting anything back to you. Most requests fail, so I didn't want to saturate
users with failing messages.
-When I try to execute the action it says UPnP error: This usually means that either the UPnP Action didn't go through or that Umap isn't handling that stack well.
-When I use Socksv4 there are exceptions that say "Action Failed" and nothing happens: This usually means that the device is not accepting portmapping actions.
The IGDv1 says it recommends not implementing UPnP on the WAN. So it doesn't specifically say that OEM's should NOT implement it, just recommends that you don't. Maybe some of the OEM's decided to implement in case of future needs ? Some OEM's implemented the UPnP on top of the HTTP daemons that provided web-admin support, which would obviously make it easier for situations like these to happen.
No, some people have interpreted the news that way, but the devices affected are listed on www.upnp-hacks.org. That means some SPECIFIC models of Linksys with specific firmware's are affected. There could be many other devices affected, but we don't know yet. The most important stacks on the wild right now are the Speedtouch/Thomson and the Broadcom/Zyxel/TP variety. The Broadcom and Zyxel variety are rarely seen open. You are still able to retrieve XML description files on the WAN port, but actually executing the UPnP action rarely goes through.
NO! Those are XML description files from UPnP devices being fetched. The fact that you can retrieve the XML description files(although sometimes a problem on Information Disclosure) does not mean you can actually execute UPnP actions. We do not know the exact percentage of devices that are actually executing the actions, but random testing out of those 612k are showing high numbers. Some routers still have firewalls enabled by default, that block most incoming requests on WAN, encasing portmapping attacks to a smaller scope.
Those methods retrieve username/password for the PPP authentication. That means you will not be getting the username/pass for the admin interface, although it could be tied to customer numbers, real names, etc. I've also had some reports of username/passwords tied to admin interfaces, so it is always possible.
The first issues where reported on the Windows XP stack. They where a BoF and DoS by eEye and FTU Security. Since UPnP was a technology
originally launched by Microsoft, one of the first stacks implemented was the Windows XP platform stack. Since it was the early 2000's, there wasn't much to research at those days, because most OEM's still hadn't implemented UPnP stacks on CPE's.
In 2003, Bjorn Stickler reported some information disclosure issues on the Netgear FM114P, targeted for the LAN interface. In 2006 Armijn Hemel opened www.upnp-hacks.org,
he researched on most stacks and reported on some stacks. So a lot of research had already gotten in on the LAN issues of UPnP.
My research focuses on the WAN issues of UPnP. This is also the main difference of Umap in comparison to other tools and attacks. Umap skips the SSDP(Discovery) step of UPnP and tries to interact by only scanning XML description
files. If it gets a positive it interacts with SOAP requests.
I talked about my research at DC/19 and so did Dan Kaminsky who was also looking into UPnP. He has collaborated with the Umap XML description file list and other ideas since.
Recently there have been newer vulnerabilities reported on some UPnP stacks. The first group of vulnerabilities released by Rapid7 attack the libupnp stack and miniupnpd. The defensecode vulnerabilities, on the other hand, attack the Broadcom UPnP stack. The only PoC available is for the Rapid7 bugs, defensecode refused to release a PoC weighing in problems that may arise from a release of such a PoC, although expecting a single PoC to cover the list of devices mentioned by Defensecode is pretty improbable. The PoC released applies to a small group of devices, probably less than 1% of the whole UPnP scenario.