Schneier on Security
A blog covering security and security technology.
« CYA Security |
| U.S Terrorism Arrests/Convictions Significantly Overstated »
February 22, 2007
Sid Stamm, Zulfikar Ramzan, and Markus Jakobsson have developed a clever, and potentially devastating, attack against home routers.
And then the attacker basically owns the victim's web connection.
The main condition for the attack to be successful is that the attacker can guess the router password. This is surprisingly easy, since home routers come with a default password that is uniform and often never changed.
They've written proof of concept code that can successfully carry out the steps of the attack on Linksys, D-Link, and NETGEAR home routers. If users change their home broadband router passwords to something difficult to guess, they are safe from this attack.
Additional details (as well as a nifty flash animation illustrating it) can be found here. There's also a paper on the attack. And there's a Slashdot thread.
Cisco says that 77 of its routers are vulnerable.
Posted on February 22, 2007 at 12:40 PM
• 78 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
"This is surprisingly easy, since home routers come with a default password that is uniform and often never changed."
Since when is user stupidity a surprise? Software/hardware developers should expect it already.
It has long been standard security practice that when logging in to a new system with a default password, the first required step is to have the user create a new password. If routers did this and refused to function until a customized password was set, none of these problems would occur.
It seems like having remote/WAN administration turned off (the default setting on my Netgear router iirc) would prevent this, even if you kept the password.
All though how many cautions the router company's provide to change the default password some people simply don't care about it. They always think "who is going to hack on to my wireless network" well they are wrong.! Therefore the best solution is if the company's which manufactures the routers truly care about the users security they should put a random password strings before release of the product instead of the default password. To further nail down the physical security of the password it self, it could be hidden inside a scratchable silver coating. With the present problem i think thats the most practically solution to the problem.
I take it this is clever because the attack code is execute within the (meager) perimeter?
No, disabling WAN administration does not block this attack. The vector for the attack is your own PC. However, enabling WAN administration on a router with the default password would certainly increase your vulnerability, and to much less sophisticated attacks than this one.
I can think of how many times I have changed my password for my broadband router.
New home router advert:
"Proven to be as secure in the default configuration as an ATM!"
The router box I have in my hand at the moment has the router MAC address printed on a label and affixed to the box.
Assume the MAC is unique; it should be.
To do this, every individual router must be programmed differently (to have a different MAC) and must be tracked from programming to boxing (to get the right sticker on the right box) and has a one-off printed sticker.
Given that these systems are in place, why couldn't they be co-opted to program each router with a different default password and put it on a sticker on the box?
IMHO, generating random passwords and packing them with routers before shipping would add cost and complexity to the production process, regardless of whatever other per-unit configuration was already being performed. It's not necessarily a no-brainer.
And, for that matter, routers would still *have* to revert to a default password after a hardware reset.
It gets better
Some ISPs (mine included) are now providing customers with 2Wire modem/router/WAPs. These gizmos have a number of security properties that should scare the bejesus out of anyone.
Most relevant to this - the vast majority of changes require no password at all. You can change the default password, but you'd be hard pressed to find a setting that requires you to enter it.
So, I can change such firewall and port forwarding options as it offers, as well as what DNS servers it uses, without entering my password. And so, of course, can my browser...
As if that wasn't bad enough, the things are actually under the ISP's administrative control - their tech support folks can log in from 'outside' my home network with, I'm sure, a global password that's never changed, and change any setting I can, as well as some I can't.
The routers don't have to revert to a _global_ default password on a hard reset. They could revert to using their own MAC address as a password, for example. As Michael pointed out, that's already on a label on the box. Since people usually lose the box, it should also be on a label on the bottom of the router.
"Since when is user stupidity a surprise? Software/hardware developers should expect it already."
The user aren't stupid, they are just regular people who assume that their purchases are reasonably well designed.
Being non-experts, this is a reasonable assumption to make, and it is developer error if it turns out to be incorrect.
Fortunately there are some units that are properly designed. As an example, the Apple units are in a setup-only mode out of the box, and require an administrative password to be set prior to the unit providing a functional network connection.
Unfortunately, as long as turnkey deployment remains a huge selling point, smart default passwords on routers will not happen.
How many average users do you think even know their router has a password? They don't have to, they just plug one end into their cable modem and the other into their computers. Or, if it's wireless, they just pug one end into their cable modem and they're done. That ease-of-use means more to that average user than not being PWNT. Unfortunately.
Notwithstanding the sheer stupidity of the routers having global default passwords, I wonder if this adds to the case for authenticated DNS?
I wonder ... if the attacker wanted to spoof, say, my bank account, then could SSL be able to flag certificates for secure sites changing and/or being improperly signed?
Have a nice default first time password. Then have the router prompt for a required password change when it is first turned on or reset?
Users are only "safe" from this attack in that the router DNS values can't be changed if the password isn't guessed. The user's browser can still become a "browser zombie" if they don't close the application... and therefore, still not "safe"!
Not a fix for a lot of home users, but i use a linux box for my dhcp server and caching DNS. I don't use the router's settings. Then again I have pretty hard random passwords on my routers too.
hmmm, Apple's wireless routers are updated using a custom app and SNMP. I wonder if they're vulnerable to a similar type attack.
Finally a security problem where the appropriate solution is a yellow sticky note with the password scrawled on it.
THe attack is called "CSRF" Cross-Site Request-Forgeries. It's been documented for several years, I remember stumbling on it myself 2-3 yars ago, and being very suprised that it doesn't wider publicity - that has luckily changes in the past year. It's not only routers, but all sorts of intranet-webapplications are open to this line of attack (especially when it's standard-software, or someone has insider-knowledge; and users stay logged in for most for most of the time).
Those kind of attacks can be made considerably more difficult with one-time tokens in all forms and/or tokens as subdomains^1 etc.
that is another reason to surf the web with mimimal trust and Java scripting disabled.
One reason this attack works is that many routers allow you to change their configuration with an HTTP GET request. And you can put a user name and password at the front of the URL. So any web page could have an "img" or "script" tag with a "src" URL that changes your router settings (instead of actually loading a script or image). This could be defeated (at least partially?) if they required HTTP POST - in which case the cross-site scripting restrictions would kick in. I hope this makes sense, maybe I'm wrong.
@Filias - Funniest comment in this thread. Bruce needs to update his article to include that as a solution.
It's rather unfair to blame the users in this case. Most non-techies will just unbox it, plug it in and turn it on. They're so easy to use that there is no configuration required, so why would a consumer even bother? People don't know about DNS, MAC Addresses or admin pages. Or care, for that matter. It's all well and good to tie the admin password to the mac, or have a silver scratchy inside the box, but if the consumer never attempts to hit the admin page, then all that is useless.
What the router should do is present them with the admin page the very first time they try to get online and not let them out to the public internet until they've changed the admin password and maybe do some basic configuration. It's easy enough to have a short start-up wizard webpage, and since users are used to wizards in MS Office and other software, this shouldn't be much different for them.
This is one of the situations that a captcha to log in would solve nicely.
Just enough security, it's likely not to stop other attacks though.
..This is especially devious if you've recently logged into your router's admin interface and your HTTP Auth attributes are saved.
<a href="http://192.168.0.1/action.cgi?do-something-devious"> Free stuff!</a>
Could do something devious without the user being any the wiser.
Why don't we see more attacks based on browsers caching authentication details?
What would stop that?
Problem: in my experience, home routers regularly require resetting, whether due to cheap QC of firmware, or other reasons. And every reset clears the password. Eventually, you get bored of redoing the password every time.
Definitely, there needs to be a device-specific default password physically attached to the router.
Another solution would be for the router to generate a unique token every time you load the configuration page. Then make it so changes can't be made without that token. If remote JS attacks can still get around this, there are some serious browser XSS vulnerabilities that should be dealt with.
The JS can get the captcha image and send it to the attacker by encoding it into a GET. The attacker decodes the data in the GET, posts an image to a web-server, and offshores a bunch of 3rd-world captcha-busters to do the work.
There are limits to the size of a GET URL, but there are no limits to what you can put in the GET request's headers. All you'd need is something that hex-encodes the raw image data. Should be pretty simple, really.
Another solution for the home user might be to stick a USB port on the side of the device, and and force the user to plug it into their computer to configure it. No more configuration over the air seems like it solves this problem completely. And IMNSHO if a home user has to fiddle with their router more then once, it's a pice of unmitigated crap.
This is way overblown.
Most users wisely have Java off.
If Java is on, then it's usually "game over" anyway.
What me worry? I've got a crappy Internet connection from NetZero. Just try and hijack it.
As for the proposed solutions, using the MAC address as password only works so long as attackers are not able to obtain a MAC address. As soon as they have that capability, then that approach fails too.
The proposed solution some others have made is pretty good though: disable the WAN port until the router configuration is completed *including* requiring the default password to be set. Then you'd 'never' have a router with a default password accessible to a net connected PC (well unless you have multiple routers involved or a PC already infected with a router-hacking trojan but those are less likely).
There have been a few comments asking what's the point of compromising a router when a PC needs to be compromised in the process. 1) PCs are not left on all day by most users. Routers typically are. 2) Most PCs have some kind of anti-virus or spyware protection, so an infection is more likely to be removed at some point. Routers do not have such protections, and most people will not reset/replace them unless something seriously is wrong. 3) Most routers today are actually small general-purpose computers running Linux or some embedded OS like VxWorks, either of which is capable of having arbitrary software being installed on it. It's quite possible to install things like proxy servers, email redirectors and even lightweight web servers on them (people do this legitimately with things like OpenWRT or Sveasoft every day). And once you have access to one you have a direct network connection, while a hacked PC behind a router is often only limited to outbound connections.
In summary, access to a router gets you a direct 24 hour connection to the net with less chance of detection of rogue software.
I think the real problem here is password fatigue.
I am not particulary geeky outside of work and dont go in for a lot of high tech at home but I must remember:
3 windows XP passwords.
3 Suse linux passwords.
2 email account passwords.
6 Web site login passwords.
2 bank account passwords.
5 bank account related pin numbers.
3 Mobile phone pin codes.
This is on top of 20 something regularly exoiring passwords at work (thankyou Bruce for password safe !).
So when I install a network router I have a choice. Do I change the password immedialtly and risk forgetting it? Or do I leave the device wide open?
This becomes more of a dilema when installing a device for a friend or relative, do you change the password and hope they remember it?
This is actually an occasion where writing the password on a piece of paper and scotch taping it to the box is sensible security practice. (If the bad guys are in your house poking around your PC setup you've lost everyhing anyway!)
Perhaps the manufacturers (at least for home devices) could do this for us, randomly allocate a default password and stick a label with the password on the box.
@CrisL: "One reason this attack works is that many routers allow you to change their configuration with an HTTP GET request. ... This could be defeated (at least partially?) if they required HTTP POST - in which case the cross-site scripting restrictions would kick in."
I am not sure whether you can dynamically change the form's destination-URL without a browser warning, but that is not necessary anyway (just let the form point to 192.168.2.1 from the beginning).
@James Lick: Good points, but the main attack vector is probably fishing. By compromising the router, you can invisibly poison the DNS, and sending all requests for legitimate site URLs such as eBay and PayPal to your own custom site. Or you could just perform a man-in-the-middle attack on traffic that goes through. If done wisely, this will be undetectable to the user.
Using Firefox with the NoScript extension, I can confirm the first part of your sentence but not the second one.
There are, however, some sites that seem to be unable to even put "Hello World" online without heavy scripting.
I don't think Java is needed for this attack... if you're going after the dumb users who plug-and-play their routers, then you can fairly reliably guess what the subnet is using the defaults provided by the router. You could probably hard code scans for 10.0.0.1, 192.168.0.1, and 192.168.1.1 and get enough hits for this hack to be worth doing.
Continuing from Pseudonymous
Free porn.... Offer free porn and require the users to submit a captcha.
Java is not needed. ``dumb users who plug-and-play their routers, then you can fairly reliably guess what the subnet is using the defaults provided by the router." Not just dumb users! I personally always use the default subnet, why shouldn't I? (Security by obscurity?)
It also makes telephone support (generally from friends and family) far easier - type 192.168.0.1 into the Internet. Note the deliberate use of `Internet' as opposed to `browser'. Its far easier Start -> Run -> cmd -> ipconfig /all now tell me what's there.
I think one of the problems with a unique password for each device is that it would require something that able to survive firmware flashings, which would presumably drive up the cost. An idea would be to just use the MAC address as the default password. Not ideal, but better than the default password of "password" on my router.
"Perhaps the manufacturers (at least for home devices) could do this for us, randomly allocate a default password and stick a label with the password on the box."
I don't know about the US, but our dear friends BT already do that with at least some of their wireless home router kit. My parents' one, for example, has its password on a sticker on the bottom, right next to its MAC address.
Surely if someone like BT can do it, the likes of DLink/LinkSys/Belkin/... can?
@Ben Smyth: "It also makes telephone support (generally from friends and family) far easier - type 192.168.0.1 into the Internet."
It is even simpler than that: Most routers (in germany) have specialized DNS names reserved for them that work even if you change their default IP-configuration. As they are commonly used as DNS-proxies, that is trivial to implement.
Mine, for example, runs at 192.168.99.99 and responds to the name "fritz.box" (and its IP).
It's an old trick. IE, Firefox and Opera fixed it for regular URL a while ago.
This is a browser bug. RFC 2396 is pretty clear about this :
Some URL schemes use the format "user:password" in the userinfo field. This practice is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URI) has proven to be a security risk in almost every case where it has been used.
Speaking of old news, that trick works with Flash too :
+A hijacked banking site will display an untrusted certificate warning. Unfortunatly, users who don't care/know how to change default password will have no idea what this pop-up is about.
If Symantec wanted to do more than product selling FUD , it should have showed that pop-up in their fancy animation...
Salmon: Routers these days are typically designed for separate storage of configuration settings (often incorrectly called 'nvram' settings even though they are usually in flash) and firmware. Updating firmware usually doesn't result in configuration changes being lost, only a 'reset to defaults' would. If you used a 'WAN disabled until password set' design then it really doesn't matter in either case.
The comments about using the NoScript plugin are all fine and good, but the average user just wants to have Gmail work without having to twiddle with things. Until such functionality is available by default in the majority of user's browsers, it is of limited value as a general security mechanism.
@supersnail: and dont forget to mention that at least half of those passwords are forced to be changed on differing timelines, have to conform to differing criteria and cannot be used again for n tries.
Safe combinations come from the factory set to 0-50-0. I wonder how many operational ATMs can still be opened this way.
Two minutes of basic due diligence would take care of this attack...
But since when can that be expected of the popcorn-faring masses?
/ Uses Firefox on all machines with NoScript.
// Has Linux on his personal machine.
/// Has his router locked down like Fort Knox.
//// Slashies! =:o)
We (the security/IT industry) have no excuse for pushing this problem onto the users. We are behaving like the auto industry before the publication of "unsafe at any speed."
It's time the router manufactures stepped up and installed some safety in their devices. I especially like the comment pointing out that some folks are going in the direction of not requiring any authentication. I wonder if an ISP is smart enough to install a client-side certificate for secure admin access to a CPE device...
I blogged on this, here http://grok-security.blogspot.com/2007/02/...
This is just a sexy name for XSRF (cross-site request forgery) a subtype of script injection attacks. Jeremiah Grossman and RSnake have also been talking about port-scanning and exploiting internal devices using script injection for a quite a while now.
It's easier than that if you're a UK Sky Broadband customer:
Nobody mentioned the router userid. Change it! Most are blank from the factory.
Am I right to assume that entering the IP address instead of the URL would defeat this attack?
The only problem seems to be that when I replace the domain name with IP with the domain name, the page doesn't load correctly. (This is clearly beyond my level of expertise.)
When I read "drive-by", I thought of performing a similar DNS redirection attack as a wardriver. While not particularly useful as a bulk attack, it could still be valuable for targetted attacks (like hitting a wealthy neighbourhood).
In such a case, using the MAC address of the router as a default password would not be adequate security, since it's pretty plainly visible to a wardriver. I'd go with the first passwording suggestion that the router doesn't work until you've set/changed the password to a non-default.
I've seen a similiar Unix attack vector over 15 years ago. The HP terminals at our Univerisity had escape codes that allowed you to request a section of the screen to be sent back. If you could write to another persons terminal for a 1/2 second, you could display a command and then have it sent as the user using the terminal. They were aware of the issue but were waiting on a new ROM chip to fix it. (Most people had their .cshrc lock the tty, but there was always a small timing window after logon).
Perhaps I just live in a hyperspatial data vortex, and the following _only_ happens to me, but nobody seems to have mentioned that some (well, two of mine, from two vendors) routers change their passwords with no input from me. That is, I go to do some maintenance and notice that the box responds to neither the password I set (and wrote on a sticky-note) nor the password I get back to by giving it the Vulcan Death Grip. Since I never enable WAN administration and only enable Wireless when I'm using it, (OK, just 40-bit WEP, but even the non-wireless Linksys does this) I am at a loss to explain it. Random bugs or a vendors "Secure by obscurity" alt-default?
"Another solution would be for the router to generate a unique token every time you load the configuration page. Then make it so changes can't be made without that token."
Exactly how does the legitimate user learn the token's value? If the user can't provide the token, the router refuses reconfig. But if the router can't tell the user what to enter, using a safe channel, then the router can never be reconfigured.
Safe? Yes. Useful? Not so much.
@Dan, paenito, Frank Wilhoit, James Lick:
And about 90% of the remainder is useless frippery. Disabling those generally stops things sliding about on the screen so much, which makes it easier to read the actual content, which is generally totally unaltered.
It's true that it is too much to expect home users to configure NoScript. However a perfectly acceptable default configuration to give to firends, colleagues and relatives would be Firefox with Noscript installed and a list of about a dozen sites pre-whitelisted for them.
"I don't understand why cross-site scripting restrictions don't prevent this attack."
What cross site scripting restrictions? XSS remains a serious attack vector with no general solution apart from asking web-designers to be more security conscious. There is a feature in some recent browsers which makes it harder for a malicious script to snarf a cookie, but that doesn't apply here.
Pay attention kiddies.
If you read the white paper, they even acknowledge it.
Leave JS on all day. As long as JAVA is off, you're safe.
If java is on, chances are your machine will be compromised by a more conventional attack first.
For example, visiting a website with the following code will change the dns1 entry of a TRENDnet TRW-432BRP router:
<script src =
It's that simple.
Write a few more of these for the most popular routers, and off you go, no JAVA needed.
It is really a miracle that no-one had thought of this before.
If the JS can simply guess at several plausible local IP addresses, it can accept failure. This takes longer, so the page the user is reading has to be more engaging, so the user tarries longer. This does not seem an insurmountable obstacle.
So I would say that even with Java disabled, JS alone can mount such an attack. In fact, it seems so easy, I may try to whip this up over the weekend, using JS alone.
>Most users wisely have Java off.
The paper says 90% of home users have Java enabled.
YOU may have Java off, but YOU may not be "most users."
Mixing up data with programs is the real problem.
Browsing webservers for information of any kind is the most important use of the internet, for many private computer owners it is the most important use of their computer. Forcing them to download prgrams together with the information, knowing they have no change to proof these programs, most time without them knowing of it, this is the real malicious attack.
As mentioned by others, most of Java Script is completely useless and it only exists because of the stupidity of the web designer. For the rest, it is mostly useless for the user, but of value for the provider of the webside. For the very few java scripts that do something usefull for the user, there are better solutions with far less security risks.
I wonder what all these people defending us against cross site scripting and all these complicated things would do, if they had not created the problem in the first place.
One of the problems is that browsers issue HTTP authentification without warning. Firefox sends the warining:
You are about to log into the site "192.168.1.1" with the username "admin"
but not if the page is accessed via a <script> tag. Safari never issues such a warning. (I don't know about IE). The browser programmers could do a better job to prevent this kind of intrusion.
The same (no warning) occurs with other tags that have a src= attribute.
On https://bugzilla.mozilla.org/show_bug.cgi?id=371598, bob wrote:
this sets, on a philips router, the dns servers to opendns.org without a password
(end of quote)
This is an unacceptable and irresponsible security risk that leaves the user absolutely defenseless: changing the router password does not help here.
Philips has fixed this problem in a recent firmware update. However, there might be other routers that behave that way.
What about a *physical* button on the device that has to be pressed within 2 minutes of making a configuration change, so as to confirm the change. The config web pages could tell the user to press the button after saving the change, so stopping most automated attacks.
@Ian: That is too cumbersome.
I think the easiest idea to implement here is to just require the user to change the default password by a prompt that says "Pick a password to allow administration of the router." That way we have circumvented the entire issue.
The main issue here is the fact that they have default passwords, which in most situations, are required to be changed. Fix the default password problem, and (most) other drive-by pharming related problems go away.
Just stop by to say that there is a lot of ways of killing rabits. The security field ain't out too
hai this is deepu my domain is system administrator in in company i want know without using third party tool how to reset the administrator password useing lan connection
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.