Unresearched UPnP hacks

There are still a lot more potential hacks with UPnP, which I have not yet researched, due to lack of time.

XML/SOAP fuzzing

The XML processors on many devices are not powerful enough to run a proper XML parser. Many devices have a very bare bones parser (or just do string comparisons) which might not be able to handle big or malformed SOAP packets. Two hacks would be:

denial of service by sending a large (but well formed) SOAP packet
sending a malformed SOAP request

Many devices use Intel's libupnp, or its sucessor (pupnp) to provide this functionality. Sources for both libraries are available.

IGD AddPortMapping

In the IGD AddPortMapping hacks I have concentrated on the value of NewInternalClient but it is very well possible there are other attack vectors possible via other parameters (although linux-igd seems to be imune for this).

IGD DeletePortMapping

In the WANPPPConnection and WANIPConnection profiles there are more methods that take input, such as DeletePortMapping, which removes a portmapping. In some devices this is just another call to iptables and friends. It could be that there are more attack vectors there.

Abusing eventing

The eventing part of UPnP allows you to register a callback URL, which is called as soon as a state variable changes. The latest values of the state variables are sent using POST to the callback URL. I have not checked if this callback URL is restricted to be on the device that subscribed, or that it can be any URL. If it is the latter (which I think) then eventing can be used for attacking a site every time someone does something that makes the state of a state variable change, such as making or deleting a portmapping.

<icon> malware

The device description files often have an element <icon> that points to an icon that will be shown by for example Windows Explorer in 'My Computer' if UPnP browsing is enabled. It points to a graphics file. One of the child elements of <icon> is <mimetype> that describes the mime type of the graphics file. I don't know how Windows will handle it if the content of this file is different than the mime type describes. Windows Explorer should of course not take the mime type for granted.

Overwriting the <url> element to point to external files (graphics or malware) might also lead to unexpected behaviour. It is a bit far fetched, since being able to overwrite the XML files of the UPnP stack means that you probably have a lot more power on the router. The UPnP specification seems to not explicitely forbid remote URLs, so it is unlikely clients handle it properly.

<presentationURL>

In the device description file you can often find the <presentationURL> element. The value of this element points to the administrative web interface of the UPnP device. The UPnP specifications do not explicitely state that this URL has to point to the UPnP device itself.

Of course, if you can replace the XML files in the UPnP stack you most probably have a lot more power on the device already.