BT Home Flub: Pwnin the BT Home Hub (5) - exploiting IGDs remotely via UPnP
It’s known that UPnP is inherently insecure for a very simple reason: administrative tasks can be performed on a Internet Gateway Device (IGD) without needing to know the admin password whatsoever! This on its own is quite scary and I personally feel that although there is some research in the public domain, there is much more attention that needs to be paid to UPnP.

UPnP allows you to perform administrative functions. Some functions are very standardized and supported by most devices. Examples include obtaining network settings, and enabling port forwarding rules. Other functions are make/model specific. Some very scary functions such as obtaining administrative username and password pairs have been reported in the past. As a reminder, this works without submitting any administrative password whatsoever since UPnP is a authenticationless protocol. On top of this, most IGDs support UPnP by default.
After having read several UPnP security research materials I realized that all the described attacks assume that the attacker (be it human or malware) comes from inside the network. This post describes how to exploit IGDs remotely via UPnP even when no services are publicly available (WAN interface).
Preauth XSS + SOAP payload = remote UPnP exploitation
If you sniff yourself while running software that uses UPnP in the background to help you configure your router, you’ll see that UPnP is nothing more than SOAP. Our AJAX knowledge tells us about a feature that allows us to craft arbitrary XML requests: the XMLHttpRequest object. Trouble is, such object can only be used within the context of the site that the requests are submitted to. So if we host the malicious scripting code on a third-party site, and a victim user located in the same LAN as the target IGD visits such page, the request wouldn’t go through due to XMLHttpRequest same-origin policy restriction. Or put in a different way: you aren’t allowed to make XMLHttpRequests to any server except the server where your web page came from.
However, if you find a pre-auth XSS vulnerability on the target device you can bypass such restriction. For instance, many devices such as the BT Home Hub and Speedtouch routers offer certain pages before authenticating. Some of these pages are cgi scripts which are vulnerable to XSS. Although offering certain “useless” functionalities before logging into the router might not seem like a big deal, it can actually lead to UPnP being exploited remotely, even if the web admin console is not visible from the Internet!
The following is a non-malicious proof-of-concept exploit which sets up a port-forwarding rule from port 1337 on the WAN interface to port 445 on the internal IP address 192.168.1.64. Such IP address is the first usable IP address reserved for clients connected to Speedtouch and BT Home Hub routers. The exploit has been tested on BT Home Hub - Firmware version 6.2.6.B. Just to make things clear, UPnP is enabled by default on the BT Home Hub, just like most IGDs. If your Internet gateway is a BT Home Hub, clicking on the following link should add a new forward rule called EVILFORWARDRULE: ATTACK.
In order to check if the port-forwarding rule was added successfully you can use UPnP Port Forwarding Utility and simply click on “Update list now” after the device has been discovered (device name should show on the top-left corner a few seconds later after launching the tool). You could of course use the technique and code explained in this post on any Internet gateway that supports UPnP and is a vulnerable to a preauth XSS vulnerability. If you manage to successfully test this attack on the BT Home Hub or any other device please let us know!
http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-5/payload.xss
Zombie routers and the unvalidated NewInternalClient
bug
A bit of more UPnP hacking lead me to realize that the BT Home Hub is vulnerable to the (in)famous unvalidated NewInternalClient bug. This bug allows you to choose external IP addresses instead of a LAN IP addresses as intended when setting up port-forwarding rules via UPnP. In this case, I reused the previous code and changed the internal IP address (192.168.1.64) in the NewInternalClient tag with the IP address of a random Internet web server and the value of the NewInternalPort tag to 80. This effectively allows an attacker to use the vulnerable BT Home Hub router as a proxy - aka onion router. In other words, when probing the router’s NATed IP address on port 1337, the attacker is effectively probing the IP address and port number specified by the port-forwarding rule - except the routers IP address would be shown in logs of the target web server, as opposed to the attacker’s real IP address. I thought this is a nice real example of how a vulnerable router can be used as a zombie by simply having a user visit a page with malicious scripting (XSS + UPnP SOAP request). Imagine running your favourite vulnerability scanner against a target site, while using the victim user’s router as a proxy - sweet!
There are other UPnP functionalities besides port forwarding rules that look potentially interesting from a hacking point of view. For instance, SetDNSServer allows you to guess what, set the gateway’s DNS server. Imagine someone changing your router’s DNS server setting by simply visiting a webpage. After that you visit yourfavoritebank.com and guess what, you’re actually visiting a malicious server that is harvesting all your banking login details! I’ll leave the exercise of writing a remote UPnP exploit that changes the DNS server setting on the BT Home Hub (or any other vulnerable router) to the reader.
GNUCITIZEN is a Cutting Edge, Ethical Hacker Outfit, Information Think Tank, which primarily deals with all aspects of the art of hacking. Our work has been featured in established magazines and information portals, such as Wired, Eweek, The Register, PC Week, IDG, BBC and many others. The members of the GNUCITIZEN group are well known and well established experts in the Information Security, Black Public Relations (PR) Industries and Hacker Circles with widely recognized experience in the government and corporate sectors and the open source community.
GNUCITIZEN is an ethical, white-hat organization that doesn’t hide anything. We strongly believe that knowledge belongs to everyone and we make everything to ensure that our readers have access to the latest cutting-edge research and get alerted of the newest security threats when they come. Our experience shows that the best way of protection is mass information. And we mean that literally!!! It is in the public’s best interest to make our findings accessible to vast majority of people, simply because it is proven that the more people know about a certain problem, the better.
Comments
Something that worries me about many network devices that support UPnP is that when you change settings via UPnP they sometimes cannot be undone via the web console! Instead you need to undo them via UPnP.
UPNP requests executed via DNS Rebinding sounds like a really ugly thing. One that wouldn’t be difficult to code up into a convenient little applet.
Bt have kindly updated HH to version E, if you changed your password from the default (please!) the exploit now just goes into a loop with no changes made. AFAIK the HH now requires a serial number input in order to change the pass also.
10x for the info. through, I am not sure whether it is me, but how is that related to the hack discussed above.
Hi Mark. I’m a bit confused about your comment. Changing passwords shouldn’t make a difference on this exploit as the payload uses a UPnP which is a authentication-less protocol (no password required!).
Please elaborate so I can understand your problem better.
i found that u can get straight to menu in last firmware without serial chk but it will ask for user and password
http://192.168.1.254/cgi/b/con.....&l1=-1
hope can find bug in laste firmware, UPnP attack dosent work on last firmware E
gool, the UPnP attack does work on the latest firmware.
gool: I run an Alcatel Speedtouch 510 (4.3.2.6.0 firmware; 9 volt supply version)router and set it to disable UPnP, turned firewall on to standard level and when I retrieve your link it opens the 510 Connectivity Check menu window.
This is quite scary as I thought UPnP was blocked by the 510.
What ’should’ your link do?
(Using Mac OS Leopard)
DUH! Am so confused reading all the above have answered my own question! Of course this will happen!
Sorry.
Hi
This must sound really dumb to you guys but I have to ask it .. how are you allowed to make a request to 192.*.* if you are from some evil.com site ?
@anonymous: that question is NOT dumb at all! The only reason why it’s possible to contact an internal system (home router in this case) is because:
1. you visit evil.com which loads HTML/JS code in your browser
2. your browser executes such code
3. since your browser is located in the *internal* network (LAN), it CAN communicate with your home router, even if the HTTP service is only available internally
In other words: your browser becomes your worst enemy. It’s nothing else than a proxy which links both the external world (WAN/Internet) and the internal one (LAN/intranet).
Makes sense? Let me know if you have any other questions.