BT Home Flub Pwnin The BT Home Hub (5) - exploiting IGDs remotely via UPnP

Thu, 10 Jan 2008 11:46:14 GMT

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 _XMLHttpRequest_s 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!

[/files/2008/01/payload.xss](/files/2008/01/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.

Adrian PastorAdrian Pastor
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.
reznrezn
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.
MarkMark
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.
pdppdp
10x for the info. through, I am not sure whether it is me, but how is that related to the hack discussed above.
Adrian PastorAdrian Pastor
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.
goolgool
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/connchk/?ce=1&be=0&l0=4&l1=-1 hope can find bug in laste firmware, UPnP attack dosent work on last firmware E
pdppdp
gool, the UPnP attack does work on the latest firmware.
catweazlecatweazle
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)
catweazlecatweazle
DUH! Am so confused reading all the above have answered my own question! Of course this will happen! Sorry.
anonymousanonymous
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?
Adrian 'pagvac' PastorAdrian 'pagvac' Pastor
@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.
oceanocean
great post. hey anybody know how to exploit NAT in router. Port forwarding is also best way to exploit router