Drive-By Pharming

Sid Stamm, Zulfikar Ramzan, and Markus Jakobsson have developed a clever, and potentially devastating, attack against home routers.

First, the attacker creates a web page containing a simple piece of malicious JavaScript code. When the page is viewed, the code makes a login attempt into the user’s home broadband router, and then attempts to change its DNS server settings to point to an attacker-controlled DNS server. Once the user’s machine receives the updated DNS settings from the router (after the machine is rebooted) future DNS requests are made to and resolved by the attacker’s DNS server.

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.

Note that the attack does not require the user to download any malicious software; simply viewing a web page with the malicious JavaScript code is enough.

Tags: , , , , , , , ,

Posted on February 22, 2007 at 12:40 PM • 78 Comments

Comments

Surprised • February 22, 2007 1:14 PM

“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.

Michael Ash • February 22, 2007 1:19 PM

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.

JP • February 22, 2007 1:19 PM

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.

janantha • February 22, 2007 1:25 PM

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.

Andre LePlume • February 22, 2007 1:28 PM

I take it this is clever because the attack code is execute within the (meager) perimeter?

ac • February 22, 2007 1:35 PM

@JP

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.

Michael T • February 22, 2007 1:45 PM

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?

Michael

Dan • February 22, 2007 1:51 PM

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.

Also, the attack isn’t a matter of Javascript being improperly ‘sandboxed’ – after all, you have to allow active web pages to inititate network communication in many instances.

Sticky problem.

dragonfrog • February 22, 2007 1:56 PM

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.

dragonfrog • February 22, 2007 2:05 PM

@Dan

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.

This would raise the bar to remote attackers somewhat. The first three bytes of the MAC are vendor specific, but the last three should be essentially unpredictable, so there’s about 24 bits of randomness there. I don’t know of any javascript interfaces to the ARP cache – anyone?

Kevin Way • February 22, 2007 2:15 PM

“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.

Joshua • February 22, 2007 2:26 PM

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.

Paul Crowley • February 22, 2007 2:26 PM

I don’t understand why cross-site scripting restrictions don’t prevent this attack. JavaScript code on site x is supposed to be sandboxed such that it can only connect to site x.

BLOB[11] • February 22, 2007 2:37 PM

The threat to be protected against here is fairly narrow. Javascript doesn’t have the power to do extensive attacks against router login pages or do stuff like grab MAC addresses. Trojans can do better, but there’s no need for a trojan to hijack a router when it can hijack the host system directly. Designing routers to use their LAN-side MAC address as the default password is sufficient to defeat this threat.

Another way to defang Javascript router attacks would be to require router logins to correctly respond to a captcha as long as the default password is in place.

Paul Cantrell • February 22, 2007 2:45 PM

Using Javascript to create a LAN-based attack vector is nothing short of brilliant. Nicely done, you diabolical kids.

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?

meeters • February 22, 2007 3:05 PM

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?

Keith Schuler • February 22, 2007 3:10 PM

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

Yakko • February 22, 2007 3:16 PM

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.

Yakko • February 22, 2007 3:19 PM

hmmm, Apple’s wireless routers are updated using a custom app and SNMP. I wonder if they’re vulnerable to a similar type attack.

Filias Cupio • February 22, 2007 3:42 PM

Finally a security problem where the appropriate solution is a yellow sticky note with the password scrawled on it.

Sencer • February 22, 2007 3:51 PM

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.

[1] http://blog.php-security.org/archives/48-CSRF-protections-are-not-doomed-by-XSS.html

Chris L • February 22, 2007 4:03 PM

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.

Sammy The Surfer • February 22, 2007 4:19 PM

@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.

Blair Nilsson • February 22, 2007 5:49 PM

This is one of the situations that a captcha to log in would solve nicely.

The user doesn’t need to know the password. But the javascript attacker wouldn’t be able to solve it.

Just enough security, it’s likely not to stop other attacks though.

Matthew Skala • February 22, 2007 6:35 PM

“Note that the attack does not require the user to download any malicious software; simply viewing a web page with the malicious JavaScript code is enough.”

Viewing a Web page with the malicious JavaScript code is downloading malicious software. That’s the point. Why do we still permit Web pages to contain executable code? Why did we ever?

Laen • February 22, 2007 6:36 PM

..This is especially devious if you’ve recently logged into your router’s admin interface and your HTTP Auth attributes are saved.

This:
<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?

For example, a website could fire off a itty-bitty popup window that hits every single bank’s online-banking page for transferring money.. Or it could make some javascript XMLRPC calls to google to spam..

What would stop that?

Barry Kelly • February 22, 2007 6:54 PM

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.

Stephen • February 22, 2007 7:43 PM

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.

Pseudonymous • February 22, 2007 7:53 PM

@Blair Nilsson
“This is one of the situations that a captcha to log in would solve nicely. The user doesn’t need to know the password. But the javascript attacker wouldn’t be able to solve it.”

If only.

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.

Vincent • February 22, 2007 8:34 PM

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.

Mike • February 22, 2007 9:16 PM

This is way overblown.
Javascript can’t execute this attack unless JAVA is enabled.
Most users wisely have Java off.

If Java is on, then it’s usually “game over” anyway.

James Lick • February 23, 2007 12:00 AM

@Mike: JAVA and JavaScript, despite the names, are completely different things. And it is really not my experience that ‘most users’ have turned off either one. JavaScript is used by so many major sites these days that it makes it really hard to use the net without 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.

supersnail • February 23, 2007 2:20 AM

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.

Paeniteo • February 23, 2007 2:25 AM

@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.”

You can use Javascript’s form.submit() method to submit POST-based forms.

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).

Tarkeel • February 23, 2007 2:30 AM

@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.

Paeniteo • February 23, 2007 2:31 AM

@James Lick: “JavaScript is used by so many major sites these days that it makes it really hard to use the net without it.”

Using Firefox with the NoScript extension, I can confirm the first part of your sentence but not the second one.

Many sites use Javascript, but with the big majority of these you will just experience a minor loss of convenience, if at all.

There are, however, some sites that seem to be unable to even put “Hello World” online without heavy scripting.

Ben Combee • February 23, 2007 3:51 AM

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.

Ben Smyth • February 23, 2007 5:42 AM

Continuing from Pseudonymous
Free porn…. Offer free porn and require the users to submit a captcha.

@Ben Combee
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 tobrowser’. Its far easier Start -> Run -> cmd -> ipconfig /all now tell me what’s there.

Salmon • February 23, 2007 5:44 AM

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.

LeoNerd • February 23, 2007 5:54 AM

“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?

Paeniteo • February 23, 2007 6:57 AM

@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).

Frank Wilhoit • February 23, 2007 6:57 AM

paeniteo has it right. NoScript blocks JavaScript by default but allows domains to be easily whitelisted for JavaScript execution on either a permanent or one-session basis. This has been farandaway the single most beneficial device I have ever adopted for blocking attacks of all kinds. Any web site that requires JavaScript has to meet an extremely high burden of proof with me.

Guillaume • February 23, 2007 8:06 AM

It’s an old trick. IE, Firefox and Opera fixed it for regular URL a while ago.
http://support.microsoft.com/kb/834489

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 :
http://www.webappsec.org/lists/websecurity/archive/2006-08/msg00001.html

+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…

James Lick • February 23, 2007 8:16 AM

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.

The type of person who doesn’t know or care about putting a password on his router is rather unlikely to know or care about controlling how JavaScript is configured on his computer.

bob • February 23, 2007 10:20 AM

@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.

Fenris Fox • February 23, 2007 10:27 AM

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)

tanj • February 23, 2007 10:47 AM

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/i-hate-passwords-12.html

GSM • February 23, 2007 1:09 PM

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.)

kiwano • February 23, 2007 1:14 PM

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.

aarrgghh • February 23, 2007 1:57 PM

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).

MikeA • February 23, 2007 2:04 PM

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?

bob • February 23, 2007 3:39 PM

@Stephen
“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.

Roger • February 23, 2007 10:42 PM

@Dan, paenito, Frank Wilhoit, James Lick:

I have to endorse the comments that Javascript is not at all essential, in fact is easily disabled. I have been using Noscript for more than a year now, and there are only about 5 or 6 sites where I find I want to whitelist Javascript. Not only that, but I’ve become a bit more aware of what sites are actually doing with their JS. At least 90% of Javascript scripts are just doing hitbox style user tracking. Disabling them has NO EFFECT whatsoever on the user exerience, except that the site oftens runs a little faster and is more reliable during times of congestion. Plus, of course, it protects my privacy.

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.

Roger • February 24, 2007 5:36 AM

@Paul Crowley:
“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.

“JavaScript code on site x is supposed to be sandboxed such that it can only connect to site x.”

Erm, aren’t you thinking of Java? There is nothing to stop your Javascript saying document.write(“<img src=’http://whatever.you.want’>”)

Andreas • February 24, 2007 12:12 PM

Changing the password is not enough! The browser should be restarted every time the configuration page has been opened, because from then on the router can be accessed without a password. And never tick the “memorize password” box. The attacker does need a password any more because the browser will willingly deliver it. This is also true with your bank – an attacker could access your bank account with javascript (no router needed).

Mik • February 24, 2007 3:22 PM

Pay attention kiddies.
THERE IS ABSOLUTELY NO WAY FOR JAVASCRIPT TO DO THIS.

If you read the white paper, they even acknowledge it.

The only, half-arse, demo uses javascript to call JAVA (not the same thing). Java is the only way to get the needed network info (besides active-X).

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.

Andreas • February 24, 2007 5:39 PM

Javascript alone is enough for a serious attack. There are not so many possibilities for a router address, many use 192.168.1.1 or 192.168.0.1, so that is already a good bet, no need of Java for this.

Andreas • February 24, 2007 9:19 PM

For example, visiting a website with the following code will change the dns1 entry of a TRENDnet TRW-432BRP router:

<script src =
“http://admin:admin@192.168.1.1/wan_poe.cgi?dns1=204.101.251.1”>
</script>

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.

Anonymous • February 24, 2007 11:38 PM

@Mik

The Java applet doesn’t appear to play a critical role. All it does is ascertain the LAN-local IP address, in order to determine where to start scanning for routers. The JavaScript performs the scan that finds the router.

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.

Anonymous • February 24, 2007 11:42 PM

@Mike

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.”

Werner • February 25, 2007 4:27 AM

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.

Andreas • February 25, 2007 9:15 AM

One of the problems is that browsers issue HTTP authentification without warning. Firefox sends the warining:

Confirm
You are about to log into the site “192.168.1.1” with the username “admin”
Cancel/OK

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.

Andreas • February 25, 2007 10:55 AM

On https://bugzilla.mozilla.org/show_bug.cgi?id=371598, bob wrote:

<img
src=http://192.168.1.1/cgi-bin/setup_dns.exe?page=setup_dns&logout=&dns1_1=208&dns1_2=67&dns1_3=222&dns1_4=222&dns2_1=208&dns2_2=67&dns2_3=220&dns2_4=220>

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.

Andreas • February 25, 2007 5:12 PM

Philips has fixed this problem in a recent firmware update. However, there might be other routers that behave that way.

Anonymous • February 25, 2007 10:42 PM

“I don’t know of any javascript interfaces to the ARP cache – anyone?”

I don’t know javascript so instead I have to wait for the next arbitrary-code bug in an image file parser.

Ian Ringrose • February 26, 2007 7:54 AM

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.

Doodle • February 26, 2007 1:31 PM

@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.

deepunp • August 23, 2007 3:45 AM

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

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.