UPnP The Saga Continues

This post is a quick introduction to some other UPnP related issues. Yes, we have been targeting UPnP in the last couple of weeks mainly because is a big problem many people have forgotten or don't know about.

We've already covered what UPnP is and how it works in most basic form. We've also showed how it can be exploited with nothing more but a simple XSS on your home router. Then we've improved upon our techniques with the so-called Flash UPnP hack. But what we have deliberately left out from the picture is that, in many cases, UPnP is remotely exploitable without interaction required from the victim and all the attackers need to know is the IP address of the exploitable device. DUH!

In the course of the past several weeks we've been exploring Google through the Google Hacking Database and the Johnny.Ihackstuff.Com Forums. With their help we manged to discover hundreds of devices that are visible on the Web and can be accessed to from the browser. After countless of hours in research, we manged to find the locations of the UPnP description files and from there the UPnP control points which can be exploited with one-shot attack from the comfort of the attacker's chair. "Is that good?" Not good at all.

Why on first place these devices are indexed by Google? And why on earth someone would allow UPnP across the Web? We have some ideas why the situation is so. First of all, we believe that some IP addresses have been used for hosting legitimate sites which Google and other Search Engines have indexed successfully. Then these IP addresses has been put back into rotation for DSL users. Due to the fact that the devices hooked on these IP addresses listen on any HTTP port, Google and friends have continued spidering their services. And this is pretty much the reason why they are there. However, it is more interesting to know why they allow communication on HTTP ports which are UPnP enabled. This unfortunately can be explained with the following: Bad Administration and lack of understandings!

So there you go! Try it yourself and you will see that the number of devices that export UPnP services across the Web is pretty high. It is a matter of visiting the Google Hacking Database or the Forums in order to get lists, and also to find out the locations of the UPnP descriptions. And form that point on the possibilities are endless.

It shouldn't be that simple! This is another reason to verify that UPnP is switched off!

Archived Comments

AJ

Is the attack directed at the ip address of your LAN interface or a multicast address., and if so would changing the default addresses give any protection

pdp

AJ, has nothing to do with LAN or multicast addresses. The attack is directed to devices that have public IP addresses and UPnP enabled on public HTTP ports.

AJ

The proof-of-concept that is shown goes after the known ip address of the router.

pdp

AJ, I seriously do not understand what you are trying to say. In the previous posts we showed how to exploit UPnP on most routers as most devices have such facilities but only available for the local network. In this post we warn that there are many externally facing devices that has UPnP functionalities enabled as well. The first scenario requires the browser to perform the request since the attacker does not have local access. The second scenario provides the attacker with the ability to send the right type of require straight to the device without the need of any convoluted attack setup.

iilab

Is that true?

Markus

Why you dont send a email to them? Maybe they change it then

Avee

My Thomson WL780i resolves http://speedtouch/ to the router itself. No need to find out its IP-Address.

pdp

yes, as well as BT Home Hub is just http://api.home and most routers will respond to http://home