Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

2/22/2007
11:10 AM
50%
50%

Pharmed Out Passwords

A simple change to wireless password defaults could make a world of difference, and possibly render this issue moot

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.

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
Edge-DRsplash-10-edge-articles
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
News
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Commentary
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-32615
PUBLISHED: 2021-05-13
Piwigo 11.4.0 allows admin/user_list_backend.php order[0][dir] SQL Injection.
CVE-2021-33026
PUBLISHED: 2021-05-13
The Flask-Caching extension through 1.10.1 for Flask relies on Pickle for serialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the ca...
CVE-2021-31876
PUBLISHED: 2021-05-13
Bitcoin Core 0.12.0 through 0.21.1 does not properly implement the replacement policy specified in BIP125, which makes it easier for attackers to trigger a loss of funds, or a denial of service attack against downstream projects such as Lightning network nodes. An unconfirmed child transaction with ...
CVE-2019-10062
PUBLISHED: 2021-05-13
The HTMLSanitizer class in html-sanitizer.ts in all released versions of the Aurelia framework 1.x repository is vulnerable to XSS. The sanitizer only attempts to filter SCRIPT elements, which makes it feasible for remote attackers to conduct XSS attacks via (for example) JavaScript code in an attri...
CVE-2020-23995
PUBLISHED: 2021-05-13
An information disclosure vulnerability in ILIAS before 5.3.19, 5.4.12 and 6.0 allows remote authenticated attackers to get the upload data path via a workspace upload.