Hacking The Interwebs
Sat, 12 Jan 2008 12:57:22 GMT
"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 239.255.255.250: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 application/xml, a SOAPAction header and a request body that complies with the SOAP message format. These three request values cannot be changed with JavaScript unless we deal with the 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:
[/files/2008/01/test.mxml](/files/2008/01/test.mxml)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 ishttp://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
POST. - The next expression defines the request data. This is the actual SOAP Message which will add the portforwarding rule.
- We need to set the
contentTypetoapplication/xml. - Then we push the
SOAPActionheader into the Array of headers. - And finally we open the
URLRequestwithnavigateToURL. The respond will render within_self.
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.
Archived Comments
Looks like this has been touched on before: http://www.informit.com/articles/article.aspx?p=461084&rl=1 However, this post obviously shows how an attacker can do this remotely. Cisco doesn't believe in UPnP so won't be affected, althought the LinkSys range probably is. 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.
David, incorrect. Although UPnP research has been going on for some time now, what we show here is a completely different technique. For example, people used to believe that UPnP is exploitable only if you are within the LAN where the UPnP device is located, due to the fact that you need SSDP and presumably HTTPU. Well, it seams that this is not the case. UPnP is exploitable over the Web and this is a huge risk, and this is the new thing that needs to be flagged. UPnP is supported by most if not all home devices. Enterprise grade routers also have UPnP functionalities although they are turned off by default. UPnP is supported by printers and Network Cameras as well.
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.
pdp, "incorrect"? Not really, the UPnP vulnerabilities spoken of have been considered a risk for a little while now. This research does however, highlight the fact that it is exploitable from the outside rather then the inside (as I gave credit for in my previous comment). I do think there are more shades of gray here. Having a port NAT'ed to the outside world isn't nessesarily bad, as newer PCs now all come standard with an Internet Security package and a host-based firewall (XP SP2/Vista). This mitigates this risk. The UPnP DNS forgery attack could be a pain in the ass, I'll give you that one, as this opens up a different can of worms altogether.
David, there is no UPnP vulnerability. There are only speculations on the risk that exists if you allow your devices to run UPnP. I did point our readers to a very good UPnP security paper written several years back. The portforwarding rule attack was given as an example as this is probably one of the things that cannot be used right away by script kiddies and it is sufficient enough to prove a point. Though, the portforwarding rule attack can be used to construct
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.
another point that I am trying to make is that although many people have heard of UPnP very few know how to exploit it.
I'm really surprised that UPnP doesn't provide some network authentication key to prevent tampering. An HMAC of the client/server MAC addresses would prevent these attacks?
yes, unfortunately the current state with UPnP is what it is. Though, the technology does make sense. If you have a TV box that requires portforwarding for whatever reason, it is convenient to tell that to the router instead of relaying on the user to perform the configuration manually.
I have to agree that UPnP protocol is very useful and can help the end-user to setup his/hers home network with minimal effort. I always believed that if something can be made simple it will be more reliable. But at the same time simplicity is not excuse for lazinesses. Since I have purchased my first router I have some unanswered questions:
- 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.
David, that article mentions UPnP to be an *internal* threat. We mentioned how previously published UPnP security research focuses on *internal* attacks here: http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-5 Our research is focusing on exploiting UPnP *remotely* by simply having the victim user visit a webpage.
New UPnP stack implementations will probably make sure that the client's IP address matches the IP address for the "AddPortMapping" request. In other words, you should only be able to add port forwarding to *your* LAN IP address and no other internal IP address. However, this is not completely secure as the victim who visits the malicious webpage containing the exploit (preauth XSS + XHR(SOAP request) or Flex Flash SOAP request) will ultimately request the port-forwarding action to the target router. A huge problem (as we have mentioned already) is that the value of "NewInternalClient" can be an external IP address on many UPnP stacks (due to the protocol specs being vague?). This is very serious as it's TRIVIAL to setup a botnet of proxies to hide the cracker's attacks.
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?
All, Please understand that I realize this is a generally exploitable flaw in the way uPnP is used, which is terrible. But the rest of my post is just about Flash. (I suspect your idea is also executable in Java and quite possibly in other platforms, so please don't think I'm trying to diminish your efforts.) HOWEVER, unless I misunderstood something, what you've done is ALSO a (relatively limited) violation of the Flash Player's protection model. Adobe Flash Player goes out of their way to, really broadly, restrict an applet from talking to any but the original server without that new server's permission. For instance, to limit the impact of using Flash in DDOS attacks, as an unwilling proxy, etc. Briefly, my question is: any idea why sendToURL works from a nontrusted Flex app on a random server? Can you confirm that you tested it this way? (And it could simply be that "sendToURL" isn't protected by this presently for some reason...) [I don't KNOW how much you guys know about this Flash topic... so with apologies, I'm going to give a little more information just in case. A user can set any directories (globally) to be "trusted" by them if they want. The only really common case is that developers have to set their local directories this way to test local apps that communicate with the network. This is usually setup by default for the working directory when you install an Adobe creation app - e.g. Flex Builder. An applet you place in this directory can basically do anything. But a random applet loaded from site A in a browser can't make, say, a random webservices call to site B. Which implies you shouldn't be able to do this, unless the test applet was local or hosted ON the router already. "navigateToURL" is probably excluded, since it's behaving exactly as an HTML link and actually taking the browser to that page. ]
I fail to see how this is much of a "security vulnerability" so much as a biproduct of a simple, unobtrusive method to get a port forwarded as necessary. The only thing that shouldn't be doable is the change to DNS servers--which is kinda crappy :D Spammers could have a lot of fun with that one for sure. In terms of this being some dire critical thing--not really... Besides, it's not being exploited "remotely". It's very much being done so on the client-end. My definition of remote is by not having any application/processing done on a machine located within said network. You're relying on the user to click on harmful URLs. That's a local issue.
We've got slashdoted but the Slashdot article is quite incorrect. From the article:
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.
Mike,
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".
arete,
"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.
Flashblock (for FireFox/SeaMonkey) is a nice aid in this particular front. It won't prevent the attack from happening if you choose to play malicious flash content, but it will stop it from happening by tiny or hidden applets or ads that you wouldn't want running in the first place.
Since in most home setups the UPnP router is also the default gateway and DNS server for the hosts, a very effective way to discover it's IP address is to simply use the default gateway or default dns server IP as a target to find the right IP. Don't know if a flash application has access to this kind of data, but a java app definately does. Cyb.
Cite: "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." And, of course, 192.168.2.1 and 192.168.2.254. Cite: "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." This is what I can do using CSRF-attacks. This isn't possible with the described UPnP, is it ? Because this section sounds like that I'm able to exchange the IP-address of the DNS-server-entry using this new kind of attack. Maybe I've just overseen something ...
when you DHCP, the router will provide you with info about the DNS server. In most cases, it just tells you that your DNS is your router. Well, the attacker can basically the address of the DNS server with their own. That will effectively make all DNS requests to go through their DNS server. So when you resolve google.de, which is usually [216.239.59.104, 72.14.221.104, 66.249.93.104], you will receive [86.154.244.15] which has nothing to do with Google. Ok, ok, there are a few more things to it, but this is how it works in general. Keep in mind that it depends on the router model, as well.
the avm fritzboxes use 192.168.178.1 and .254 iirc. they are very common here.
Cite: "That will effectively make all DNS requests to go through their DNS server. So when you resolve google.de, which is usually [216.239.59.104, 72.14.221.104, 66.249.93.104], you will receive [86.154.244.15] which has nothing to do with Google." Yes, of course, I know. But I haven't thought, that changing this data is possible using UPnP, so I had to ask. Until now, I thought, that I can only set port-forwardings using UPnP and have to use CSRF-attacks for DNS stuff, ... But now I've seen http://www.gnucitizen.org/blog/flash-upnp-attack-faq and it's keeps scaring me.
yes Alex, we started investigating UPnP several months back and back then I was also surprised with the kind of things you can get done via this standard. check your home router UPnP service and I am sure that you will get even clearer picture of what's going on.
Every time I assist someone in setting up their home network (and that is really damned often) I pick up a Belkin wifi router, and give them a unique IP range in 172.18.---.---. Each place I set up uses a different third octet. I've always suspected that having a known IP configuration is a dangerous risk.
ironiridis, good but that doesn't matter. you can still locate the home router by name. a lot of them are just called home.
Afaik, this isn't going to work, unless your router has a crossdomain.xml file. Flash simply won't interact with any hosts appart from the server that either the .swf or hosted .html came from. http://livedocs.adobe.com/flex/201/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Book_Parts&file=05B_Security_176_02.html
So for those of us that are security conscious but not technically knowledgeable, what are the consequences if I turn off UPnP in my router. And specifically does that interfere with LAN connections in a household wireless network or are there any other consequenses other that those mentioned, (that is unworkable Skype and MSN).
Ed, read the following: http://livedocs.adobe.com/flex/2/langref/flash/net/package.html#navigateToURL()
What that picture means?
I find it very tenious that the reason that this isn't a security flaw in flash is because flash is behaving the way it was designed too. This is complete rubbish. It IS a security flaw in flash. I can see no justifiable circumstances why a flash script from the internet should be able to open a page to a private non-public ip address. It shouldn't be allowed.
"A multicast SSDP packet is submitted to 239.255.255.250: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." So, the question is, can listening be turned off on this port? What other protocols use this port?
TimP, the multicast packet is used only for discovery. This is the SSDP part of the UPnP stack and it has nothing to do with HTTP or HTTPU side of it. So not listening to multicast 239.255.255.250:1900 wont fix the problem.
If my router is hacked by a UPnP attack like the one described, is it making permanent changes to my router's configuration (ie ones which can be seen from the router's admin page), or "temporary changes" of the type that will be lost everytime the router is rebooted? ie is this attack simply that through upnp a particular computer's connection is now compromised until the router is next rebooted, clearing any ports opened\forwarded by a upnp request. If the browser's admin page is portforwarded to be accessible externally over the net, it is presumably still protected by whatever username\password you've set for accessing it... ie only accessible through a brute force password attack? I'm just trying to understand the full scope of what sounds like a serious vulnerability.
I'm no security expert, but it looks to me like a problem in the security model of flash. Shouldn't they sanitise the NavigateToURL URLRequest to disallow this kind of thing? Surely, if you can't do it from a raw web page without a XSS bug, then you shouldn't be able to do it from flash either. Flash should obey the same SOP policy with URLRequest objects with content type set to application/xml as XMLHttpRequest
pk, certain UPnP changes are permanent. For example, you can change your admin account password . Of course, this depends on whether your router supports it, but I've seen many routers that does have this feature which is very scary.
Sneaky, flash does comply with the same origin policies. keep in mind that we cannot read the request responds. the URLRequest object combined with navigateToURL is exactly like automatically submitting a FORM via JavaScript
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.
Thank you for this article
pdp, nevertheless, it must be possible for flash to sanitise the parameters to NavigateToURL in such a way as to make this attack impossible. If flash is the attack vector, then the solution must lie with it too. If there is a hole, then it is a lack of restrictions in comparison to XMLHttpRequest that makes the attack possible.
I guess adobe can just make sure that none can set the
SOAPAction header, but this is not a fix but a hack.
Flash is used as an example here but really any application the browser downloads and runs on their computer (i.e. javascript, activeX, Java, silverlight, etc.) could potentially do this. The only thing stopping this exploit from being executed would be the features in that language/technology.
FYI guys, it appears that the BT Home Hub responds to the following two domain names: api.home and bthomehub.home @Kudos - you're correct, any client-side technology supported by web browsers is a potential vehicle to carry out this CSRF SOAP attack. However, activeX controls are not such a sexy option as the user needs to agree to install it (although yes, he/she could be social-engineered to do so). Our Flash demo exploit shows no warning/confirmation message to the victim user whatsoever!
Great article. I checked my french home hub. Everything works except that the port used to send your SOAP request is specific to each home hub. You have to send a discovery message (broadcast & UDP) to obtain it (impossible in Flex/Flash/JavaScript no ?). A good way to prevent an exploitation.
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. That way, if you can't successfully do SSDP with the target, you can't make any uPnP requests either. It's still a boneheaded protocol though. Thoughts?
ebo, we don't have to. that information can be known in advance unless a random port is automatically assigned for each SSDP discovery. However, I don't think that this kind of thing exists mainly because UPnP has another mechanism known as GENA and for GENA to work you need the port, as well as the control point, to be static.
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.
Couldn't the router catch the dns ip change and redirect you to a router embedded html page which forced you to enter the router password and accept the change?
Interesting reading, but now need to know how to access Upnp to turn it off I'm using XP PRO.
pdp: Perhaps I am misreading the uPnP specs, but I don't think the format of the controlUrl is specified by the DCP for Internet Gateway Devices. So rather than using
http://host/upnp/control/igd/wanpppcInternet, it could use http://host//upnp/control/igd/wanpppcInternet, where is randomly generated at router startup.Kes, at the end of the day, the control part of the UPnP stack is just SOAP. So, developers can add whatever functionalities they want for the UPnP enabled routers. They can even add, let's say... a function to play SuperMario theme song with beep. I've seen already a bunch of routers that does support change of DNS plus a lot more interesting features. A lot of people talk about randomizing the URL and also the port number but this is not feasible to do. Remember, UPnP is not just SOAP. We also have GENA. And GENA is very different. If you randomize any of control points you will break GENA probably. OR at least, you will force the developers to perform a discovery for every single SOAP or GENA request. So, I don't think that that will happen.
To Madison A (and any others): You can turn off UPnP in Windows most easily using the "UnPlug'n Pray" application at Gibson Research: http://www.grc.com/unpnp/unpnp.htm directly to this app. Any given router will have a control page at which you can enable or disable UPnP. For instance, for a default setup Netgear router this is at http://192.168.0.1/upnp.htm
pdp: That's why I suggested only re-generating the random nonce at IGD startup. If a client device using GENA is started, it will perform an SSDP discovery and obtain the correct control point URLs. These will remain the same until the IGD is rebooted, at which point the IGD will send out a SSDP notification containing the new control point URLs.
It should also be remembered that many routers are reset to their default settings after power failures.
My position is that this isn't mainly Flash's fault, but I'm still curious about some details... which doesn't mean they couldn't hypothetically sanitize navigateToURL to limit different-origin requests to only having more-common control over the headers. Hypothetically. But as you point out, they definitely aren't the problem; anything that can generate a complex request is. On the other hand, pdp, you mostly skipped answering my question. Let me try to explain better. pdp responds: arete, "navigateToURL" is probably excluded... precisely, and ... This is exactly how Flash suppose to work. My point is roughly this: have you guys tested sendToURL in addition to navigateToURL from "untrusted" websites? IF this is confirmed to work, then your other descriptions are accurate. IF it doesn't work then, at least from Flash, some of the other implications are more limited... The user can clearly tell something is weird when navigateToURL happens. More importantly, you essentially only get one shot at navigateToURL. Those people that changed the IPs of their router and such WOULD be mostly safe, IF sendToURL doesn't work. Because once you load via navigateToURL you don't have the page with the Flash applet anymore to keep sending requests... I'm not SAYING Flash has limited sendToURL - but I'm saying that whether they have or not is an important piece of information that's currently missing.
arete, first of all it is completely possible to hide the execution of navigateToURL and also perform the exploit as many times as you need without the victim noticing anything. All the attacker needs to do is to open it within an iframe which is 1px wide and 1px heigh. The exploit is absolutely trivial in the form it is at the moment. second, the exploit can be performed through sendToURL as well. Here I coded and example that sends the malicious data against google so that you can use a packet sniffer or a proxy to see that it actually works: 
Of course, the second method is a lot stealthier and faster but I believe that it is a bug within Flash security model. This is the reason why I used the first method.
http://www.gnucitizen.org/static/blog/2008/01/sendtogoogletest.mxml
Is flash 9 mandatory? Or can this be done for flash 7 or flash 8 also?
It has been tested on Flash9. Not sure about earlier versions! Test it and post results here! 10x.
Thank you for your work, your expertise, and your integrity. I have been working with computers for only five years, and I started late in life, I'm sixty-six years old. In 2005 hackers invaded my first computer. It is my nature to resist such action so I fought back with everything I could learn (was not enough), and everything I could buy, such as software and repair persons help. I lost eight Windows-type computers in the struggle which was fierce and lasted two years. I then gave up on Windows OS and bought an iMac, which I am now actually using. I have a great deal of information (including a hard drive) which I am considering turning over to the FBI. I would welcome advice on this proposed action. I learned a great deal from your material, and believe the hackers broke in through the gateway router, an ActionTec model from Qwest. I have a different isp now, but am afraid I am going to suffer the same fate as before since the isp controls my router, and I cannot access it at all. I have never had an email like this reach its destination; here's hoping I get through. Thanks so much, Larry
It would be very convincing if you could offer a demo-website where the attack is successfully demonstrated. Of course in such a way that I can reset the changes in my router. I've no idea if this is realistic. Ids Zandleven
Ids, the code that I have provided is sufficient enough to test for the issue.
I think the most worrying aspect of this exploit is the possibility that someone could alter ones DNS settings by using UPnP. With this in mind I did some digging. I checked the "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0" at the UPnP Forum website. It appears that the UPnP specification actually consists of 13 "Service Templates". The service that controls port fowarding is called "WANIPConnection" and the service which controls LAN DNS is "LANHostConfigManagement". WANIPConnection says "The service is REQUIRED if an IP connection is used for WAN access" LANHostConfigManagement says "The LANHostConfigManagement is an OPTIONAL service". Interesting, the really dangerous service (LANHostConfigManagement) is OPTIONAL for a UPnP enabled router. Time to check mine out! Firstly I wrote a script to forward a few ports using the WANIPConnection service. After making sure my script worked, I moved on to LANHostConfigManagement. I tried several different actions, including the dangerous "SetDNSServer", and in each case my router replied "Invalid Action". From that I conclude that my router, which is a Netgear DG834, is not vulnerable to having its DNS settings altered by this exploit. It would be very interesting to know, at this point, which routers do support "SetDNSServer" in their UPnP implementation.
Oliver, very interesting and well researched. Keep in mind though that there are many UPnP options that can be altered. It might also be possible to alter the admin password and perform a CSRF or XSS attack knowing what the password would be. It also might be possible to alter the password and export the admin interface on the Internet facing side. Depending on the router model, some attacks may fail, other will definitely work.
Thanks for your reply pdp, no doubt hackers are always looking for new exploits, good work on exposing the flaws! I looked a bit more into it and found out a way of asking a UPnP router what services it offers. Just go to: http://[router-ip]:49152/gateway.xml Where [router-ip] is the ip of your router. It should display an XML document which shows all the supported UPnP services. One can then check the UPnP specifications to see what actions can be performed. A couple of variables I just discovered are "TotalBytesSent" and "TotalBytesReceived" - could be useful for making a bandwidth monitor for routers without SNMP :-)
I was wondering, are Apple Airport Extreme basestations also vunerable to this kind of 'exploits'?
Just noticed another domain name which the BT Home Hub responds to: bthomehub So far we got:
api.home bthomehub.home bthomehub@Oliver - the "http://[router-ip]:49152/gateway.xml" technique doesn't work on the BT Home Hub unfortunately.
@Adrian It seems that the url varies from device to device. The url is actually discovered by using the SSDP protocol ( http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol ) - which also means that you don't actually have to guess the IP of the router, because the SSDP asks each UPnP device to advertise itself and its LAN IP address. I've been investigating UPnP on my DG834 further, the most disruptive UPnP action it allows is to disconnect it from the internet. Whilst irritating, it would not pose a security threat.
Oliver, I don't want to get into more detail how this attack vector can be made ultra stable, but here are two thoughts for you:
- 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.
Just tested out what the UPnP services are like on the DD-WRT v24 firmware (a popular replacement firmware for the Linksys WRT54g). It implements only these services, and even then only the required functions: WANIPConnection WANPPPConnection WANCommonInterfaceConfig Layer3Forwarding The good news is that it is pretty secure: * It rejects any attempt to set a port forward to an external IP address destination. * It doesn't support the "getUserName" or "getPassword" commands, nor any way to reset or change them * It doesn't support the ability to change the DNS server * It doesn't support changing wifi settings
DD-WRT, is actually pretty good security-wise!
Without going through all the details and comments, I did have a simple question. If I understand this correctly, the control point URL is supplied in the answer to the broadcasted request, right? So wouldn't it be perfectly possible, within the current UPnP set, so set up this control point URL to contain an encryption key? This way you could set up a dynamic URL structure such as "http://HOSTNAME/upnp/IP_SPECIFIC_PASSKEY/control_point", without having to surcomfent the UPnP protocol.
I suspect the proof of this being possible is that it seems to have happened to me - I use the bthomehub and voip phone and have been stung for hundreds of calls made using the voip number, to numbers which were called when i know no one was home and no pc was left running, thus eliminating diallers. Getting proof to convince bt is the problem.
this is very interesting and quite unfortunate. you have to investigate to see what are the damages.
excellent article, I have something to contribute although I am not familiar with upnp very much but I have found some interesting things with ferret on my lan: It seems all new 2WIRE Home Gateways have upnp enabled when you enable remote access to admin your router via your web browser, I have found all these files: http://ubuntu-debs.googlecode.com/files/270HG-D_Gateway_upnp_xml.tar.gz via: http://qwestcustomer-ip-address/upnp/* I have reason to believe all these companies customers are effected: http://2wire.com/index.php?p=2 While I was taking a look at these xml files it looks like people can take full control of all these 2WIRE modems which hundreds of thousands of people use, including AT&T/qwest customers. I may be completely wrong. With access to xml files with commands to change passwords and modify firewall rulesets like I have found with my own router is scary lol. Let me know what you think of these files, can someone take full control over these routers?
if UPnP is enables and it supports interesting methods such as SetDnsServer, etc then it is almost certain that someone can own them. Keep in mind though that some devices show that this method is supported although when used it is evident that it hasn't been implemented.
@pdp: "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." Years ago, when I first setup my home router, I chose an IP network range that was different than any of those. I reasoned it would be more secure if I denied an attacker a default. But I never really knew of any attack that I was protecting myself from--until now. Thanks for the article.
Ken, keep also in mind that even if you choose a different IP address from the default one, your router still can be discovered by name. Most of the time it is simply called home. In the case of BT home hub it is know as api. Therefore, request to api or home will result to requests to your router no matter what the IP address is.
Sorry but this is nothing new, it was mentioned at the last brumcon
You are right when you say that 99% of the home routers can be found by probin 192.168.0.1, 192.168.0.254, 192.168.1.1 and 192.168.1.254. But that won't give you neither the port nor the Path for the request. There is NO standard port for UPnP HTTP SOAP. (I'm not talking about SSDP). And different vendors do use differents ports (for example : 2468, 5440, 6688). Also the path is almost always different depending on the router vendor. The Linksys WRT54G (fw v2.02.7) does prefix the URL used with the device UUID. You just cannot guess that ? : /uuid:000625d7-caf9-0006-25d7-caf90232011c/WANPPPConnection:1 linksys rocks :)
@nanard: how hard is it to setup a DB of most common UPnP port number/UPnP SOAP URL combinations? Home routers can be fingerprinted using JavaScript among other methods, so this attack is trivial to mount once you have a decent database.
all you need is a database of endpoints. that's all. you don't even need to fingerprint.
Hello blog very interesting. This week I found another talk about where things very interesting. Here I leave the address: http://informaniaticos.blogspot.com/
looks like an interesting read... but I cannot read Spanish, just yet.
This is an excellent forum. I have the following remarks to make: - I deliberately avoid getting the DNS server addresses from the router. They are configured in the PC network settings (to the OpenDNS servers). I use a very useful free security tool called Threatfire (www.threatfire.com). It allows me to set a rule to control which processes may access specified IP addresses, e.g. the router. This web site is very useful: http://cc.uoregon.edu/cnews/spring2003/upnp.html I have taken the advice dispensed within. Thank you very much. Your comments have helped me to a better understanding of the subject.
The link to the Test.mxml-file does not work. Could you please fix it? Or does anyone have a copy?
It has been fixed now! We are still moving stuff around!
Thank you--I learned from this article as well as the discussion.
Hi there... About the "discovery" problem for hackers (how to guess UUIDs and ports ?), maybe Adobe "solved" it with its freshly announced "Adobe Flash Platform for the Digital Home" ? (I think not, as I develop further on) I guess if it was available to anyone, this should provide developers APIs to read media (WebTVs) from real TVs/set-top boxes... why not from UPnP Media Servers ? Thus, things are getting easier, except if they restrain the supported requests to concern media stuff, and only it (no DNS change or port forwarding ?). Anyway the special player may not be available to anyone except device manufacturers. With flash apps not gotten from the internet but deployed in the boxes (no download, only stream play ?), no problem. I guess then that we won't be able to play free flash games from the web ;) Or only certified ones ? Keep in mind that all of it was just pure speculation and anticipation... One last word : Good discussion indeed with lots of information. I haven't studied the UPnP Security profile, but would it provide solutions ? I believe (am I wrong ?) no manufacturer has implemented it yet :)
Seer, thanks for the informative comment. I will have a look into the Adobe Flash Platform for the Digital Home which you've mentioned. Since I've been trying to hack my TV for some time now, this technology may prove to be very interesting. I am not sure if I understand your last question correctly. I believe that you are suggesting that none one is implementing UPnP in real devices at the moment. This is not true. UPnP is virtually everywhere from embedded devices to mobile phones. As I mentioned before, my brand new TV has support for UPnP and pretty much every home router I've seen is UPnP enabled.
Educational if esoteric discussion. I'm happy to say that my Netgear WGT624 does not enable UPnP by default, and I don't have a need to enable it as far as I can tell.
Fascinating! I'm just a user of computers, neither and IT specialist nor a programmer but it seems that what you're saying is, once the hacker has obtained entry through to your network, the damage is done and turning uPnP off will be too late because the hackers are in. Is that right, or if I disable UPnP, will I be saved? Excellent article though! regards Timbo
Can't we just hack the router without UPnP. I mean just fire queries to change DNS settings using default admin/password when 90% of the people never care to change it?
More than two years have gone since this post and one from the last message... and I would like to know if the situation has evolved somehow. Is it still dangerous using UPnP? Did somebody try to make it more secure? Thanks for your answer,
regarding upnp, the situation is still the same although we cannot exploit it with flash through the web... not yet... some day the browser will evolve enough to allow us to do that
I have been trying to figure how the DNS settings can be changed using the UPnP protocol. I have figured out discovering the host and also its description but I have not been able to get into the DNS settings change . Can anyone suggest a way I can proceed with it. Bharath
Can anyone tell me whether this vulnerability still exists or not? Thanks
navigateToURLmethod can be replaced withsendToURL. That will make the attack a lot more stealthier. Though, we thought thatnavigateToURLis a lot better for our demonstration, since you can see with your eyes what is happening in reality.