Unresearched UPnP hacks
There are still a lot more potential hacks with UPnP, which I have not yet researched, due to lack of time.
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
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).
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.
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.
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.
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
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.