Pharmed Out Passwords

I paid more attention to the recent "drive-by pharming" exploit than an actual drive-by would have allowed. (See New 'Drive-By' Attack Is Remote.) In fact, it led me to an interesting paper from a group of Symantec researchers, who developed a proof of concept exploit based on a few common security misconfigurations. They combined them in interesting and evil ways to create a threat that's extremely difficult to combat.

In case you've been living in a cave for the last month, I'll briefly describe the threat. First, the user needs to visit a Website, which will initiate the attack. Then, a Website sends a small applet to the user's browser, which proceeds to gather the local IP address. From there, the page proceeds to use script tags to attempt to access a set of common home routers, using default usernames and passwords, and the assumption that said router is on the same internal network as the host. Once access is granted, the script can use HTTP GET commands to reconfigure the router's DNS server settings, making it possible for the attacker to redirect traffic to legitimate URLs to the attacker's own phishing sites. Four easy steps.

Easy, assuming you can get somebody to visit a malicious Website (free porn, anyone?). And assuming your home router has either no password or the default password, which is probably the case, given the security consciousness of most users. (See Getting Users Fixed and Why User Education's a Bust.) And assuming your router can be configured using simple HTTP commands.

Here's the surprising part to me. The authors of the paper place only a small amount of blame on router manufacturers, basically saying that users need to be in charge of configuring these devices properly. I think the manufacturers deserve more of the blame.

I do understand the appeal of a Web-based configuration system for these routers. The extra inconvenience and expense of a console port and cable is not going to be supported by the market. I get that.

I also understand all too well the difficulty in designing a secure Website. I really do. However, the vulnerabilities described here can be addressed using a non-blank, non-default password. Think about that. These are devices that serve two purposes -- extending and securing a home network. The number of times they are configured for most users can be counted on one hand, if not one finger.

Why would it be so difficult to include in the initial setup (which can be accessed with no password or a default one) a mandatory non-blank, user selected password? This password doesn't even need to be good or strong. Just not nothing, and not "password" or "admin." A hard reset of the device can restore the password to blank, requiring initial setup to be run again. That's the point of the hard reset, after all.

This is yet another example of the problems we encounter when we assume that users either understand or care about configuring their devices securely. A small set of home users might make changes based on this advisory. This is a very small set, however.

In my experience users just don't understand networks. To borrow from Clarke (Arthur C. not Richard) networks are sufficiently advanced to be deemed magic. Does your mother even know what DNS is, let alone how a pharmer's DNS server could put her bank account in danger?

In short, the low-tech, simple solution to this problem, namely a password, is not only the most obvious one, it is really the only practical one. ISPs have repeatedly shown us that for the most part they don't care to invest the resources in securing their end users, so DNS filtering at the ISP level is not a great option.

Not only that, it only addresses the pharming threat, and wouldn't address the more sophisticated threat (detailed in the paper) of complete subversion of the router's firmware. Think of it as a router rootkit vector. Yikes.

No, I am sure that this first mention of this class of attack (browser code attacking the router config) is not the last. And until the manuphacturers start paying more attention to implementing configuration both simply and securely for home users, we are going to keep seeing easily prevented attacks like this.

— Nathan Spande has implemented security in medical systems during the dotcom boom and bust, and suffered through federal government security implementations. Special to Dark Reading.