Hacking The Interwebs
"With great power comes great responsibility", but those with great power usually aren't that responsible. Nevertheless, we try to be responsible as much as we can. In the following post, ap and I are going to expose some secrets, which may make you question our values at first, will definitely make you feel worried about "Why is all this possible?", and may even make you hate us in your guts for what we have done.
It is important to understand the magnitude of the problem we are planning to talk about, and that we cannot go to any vendor to ask for a solution, because it is not a bug what we have to deal with, but rather a combination of design problems. It is an issue, which needs to be resolved right now and the only way to do that is to go public with whatever we've got on our table.
During the last week we've tried to prepare you for this very moment by exposing bits and pieces on how UPnP works and why it is so important to keep it in mind when testing and securing networks. We've also talked about how the Universal Plug and Play can be combined with simple XSS attacks in order to create a powerful mechanism for remotely reconfiguring vulnerable routers without any means of authentication or authorization with the targeted device. Today, we are going to show you that UPnP can be exploited across the Web without the need of XSS at all. This is the next logical, evolutionary step of UPnP exploitation which by far has the highest level of severity.
We've talked earlier that the UPnP stack consists of several technologies: SSDP (Simple Service Discovery Protocol), GENA (Generic Event Notification Architecture), SOAP (Simple Object Access Protocol) and XML. The UPnP control process starts with the discovery stage. Here, a multicast SSDP packet is submitted to 18.104.22.168:1900. Any device that listens on this multicast port will then respond with information about their service description if they are happy with the body of the discovery packet. The UPnP control actuator will then read the description and look for available methods. Each method is associated with a control point (URL and a header) and method parameters which may or may not be required. Once the method information is obtained, the UPnP actuator will pick the method that suits best the given task that needs to be performed and submit a SOAP message to the control point in order to actualize it. "This is how UPnP works in general!"
When attacking UPnP from within the network where the UPnP enabled device is located, we pretty much proceed with the method described above. If we want to attack a UPnP enabled device across the Web, then we have a few problems that needs to be solved. First of all, from the Web, we cannot send and process SSDP. SSDP is based on UDP and it deals with multicast packets which is something browsers and Web technologies in general will probably never learn how to work with. The only stage that we can safely perform from the Web is the actual SOAP request, which is the very last stage of the control mechanism described in the previous paragraph.
Adrian did an amazing job explaining how someone can reconfigure your BT Home Hub router via a pre-auth XSS. In his post, Adrian describes a mechanism where the victim visits a malicious page, which makes use of a XSS vulnerability that exists within the BT Home Hub router, in order to add a portforwarding rule within the targeted device firewall. Once the XSSed SOAP request is actualized, the attacker will be able to get access to an internal service over the portforward. Given the fact that the attacker can change the primary DNS server of the target router, as well, the problem seams to be more then scary and very, very concerning. At this stage you are probably thinking that closing the XSS hole on the router pre-auth pages will definitely solve the problem for good, but I am afraid to inform you that you will be wrong.
To the point: SOAP Messages are nothing but POST requests with
contentType equal to
XMLHttpRequest object. Though, in order to successfully use this object, we need to comply with the Same Origin Policies (SOP) and that will mean that we need an XSS vulnerability, as Adrian proposed in his article. However, it is less known that these values can be easily set with Flash. The following code demonstrates the attack vector:
The Test.mxml Flash Application performs several operations.
- At first, the MXML script creates an
URLRequestobject to the targeted UPnP control point URL. In our case, this is
http://192.168.1.254/upnp/control/igd/wanpppcInternet, which is the PPP control point of BT Home Hub. Keep in mind that other devices can be exploited as well by changing that URL to match their setup.
- Then we define the request method which has to be
- The next expression defines the request data. This is the actual SOAP Message which will add the portforwarding rule.
- We need to set the
- Then we push the
SOAPActionheader into the Array of headers.
- And finally we open the
navigateToURL. The respond will render within
Shockwave Flash 9.0 r115 (the latest at the time of writing but not automatically deployed) seams to incorrectly supply the request headers. This may make the attack to fail if you use Firefox, Opera or Safari and the attacked router or UPnP device is picky about CR and CRLF line endings. Earlier flash versions does not have this problem/bug. Keep in mind that most devices will accept the request although the line endings are mixed up a bit.
When the victim visits the malicious SWF file, the above 6 steps will silently execute in the background. At that moment the attacker will have control over the service the portforwarding rule was assigned for. Keep in mind that no XSS is required, it is a matter of visiting the wrong resource at the wrong time. Also, keep in mind that 99% of home routers are vulnerable to this attack as all of them support UPnP to one degree or another.
I repeat myself far too much, but I guess I have another opportunity to mention that adding a portforwarding is only one of the many things someone can do to your router. The most malicious of all malicious things is to change the primary DNS server. That will effectively turn the router and the network it controls into a zombie which the attacker can take advantage of whenever they feel like it. It is also possible to reset the admin credentials and create the sort of onion routing network all the bad guys want. We hope that by exposing this information, we will drastically improve the situation for the future. I think that this is a lot better than keeping it for ourselves or risking it all by given the criminals the opportunity to have in possession a secret which no one else is aware of.
The only way to protect yourself is to turn off UPnP. Yes, that will make your life harder and probably your skype or msn wont work as flawlessly as before but it is a trade-off you have to learn to live with.
navigateToURLmethod can be replaced with
sendToURL. That will make the attack a lot more stealthier. Though, we thought that
navigateToURLis a lot better for our demonstration, since you can see with your eyes what is happening in reality.
Without looking at UPnP in detail, I would say the one limiting factor is knowing the Router IP address: We can get the internal range from the browser, but I still haven't seen an effective technique to enumerate and identify live hosts via the browser, which means we have to guess/brute force (.1, .254 etc) or rely on defaults.I see what you are saying but you can hit on the router within 4 tries. Home routers are located on 192.168.0.1, 192.168.1.1, 192.168.0.254 or 192.168.1.254 and this is the case with %99.9 if not %100 of all cases. The attack has been tried in our laboratory successfully. It has been already tested on several router models and they all are vulnerable. Different models have different UPnP functionalities although they all have Layer3 forwarding services. This is a common service that comes with most if not all routers. As I explained before, this is what Skype and MSN are using in order to establish voice or video connections (P2P). Of course, this can also be abused and used for evil purposes. So, I don't want to confuse the readers, neither I do want to create FUD, but the risk is serious and it needs to be taken quite seriously.
onion ring-like networks, or as Adrian referred to as
NewInternalClientbug. It also might be possible, although I haven't tested it personally, to portforward the device Web administration interface on the outside, therefore, effectively enabling attackers to login into your router. Through UPnP you can also reset the Admin password. As such, an attack that consists of two-three requests in total can portforward the web administration interface, assign dynamic DNS entry and change the admin password.
- How difficult will be to randomly generate new network ID during the first power cycle of the new router? All routers I have seen are using 192.168.0.x or 192.168.1.x networks.
- Why UPnP protocol don't have simple, but in my opinion very effective (not perfect), authentication like Bluetooth? I don't thing entering the PIN will be problem for the most of the consumers.
Without looking at UPnP in detail, I would say the one limiting factor is knowing the Router IP address: We can get the internal range from the browser, but I still havenâ€™t seen an effective technique to enumerate and identify live hosts via the browser, which means we have to guess/brute force (.1, .254 etc) or rely on defaults.Can we use IPv6 for this? As in http://[ff01::2] or http://[ff02::2] but those are multicasts, does that matter for a browser?
Looks like Firefox & Safari users are safe for now.This is not true. Firefox and Safari users are as vulnerable as IE users. It is not browser dependent. It is based on Flash. So, wherever flash runs, so that the exploit.
The change is permanent on your router. This means that when you try to visit yourbank.com, instead of going on the real think you will end up on the attackers web server? Or what if someone portforwards interesting service off your network onto the router's Internet facing side? This is an extremely serious issue that needs to be resolved.
In terms of this being some dire critical thing, not really...
Besides, it's not being exploited "remotely".
"navigateToURL" is probably excluded, since it's behaving exactly as an HTML link and actually taking the browser to that page.precisely, and this is the point. there is nothing within the provided POC that is hackish. This is exactly how Flash is supposed to work.
form.submit()The only difference is that Flash allows you to supply additional headers and also to provide the request body in XML format. So, in theory, Flash does not break the same origin policies.
SOAPActionheader, but this is not a fix but a hack.
A possible workaround (for uPnP implementors) would be to generate a random, long nonce at router startup which is included within each control point URL.Kez, yes, could work. But it needs to be implemented within UPnP specifications cuz otherwise it will break the way UPnP works at the moment.
http://host/upnp/control/igd/wanpppcInternet, it could use
http://host//upnp/control/igd/wanpppcInternet, where is randomly generated at router startup.
api.home bthomehub.home bthomehub
- Various router models comply to specific router names (DNS), i.e. api, api.home, home, etc.
- Flashs sendToURL is executed within the context of the Flash movie and therefore can be made to submit 100 requests in a coupe of seconds.