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 _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.
Archived Comments
Adrian Pastor
