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.


11:10 AM

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
Newest First  |  Oldest First  |  Threaded View
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Zero Trust doesn't have to break your budget!
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
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
PUBLISHED: 2021-06-17
Nextcloud Android app is the Android client for Nextcloud. In versions prior to 3.16.1, a malicious app on the same device could have gotten access to the shared preferences of the Nextcloud Android application. This required user-interaction as a victim had to initiate the sharing flow and choose t...
PUBLISHED: 2021-06-17
In CiviCRM before 5.21.3 and 5.22.x through 5.24.x before 5.24.3, users may be able to upload and execute a crafted PHAR archive.
PUBLISHED: 2021-06-17
In CiviCRM before 5.28.1 and CiviCRM ESR before 5.27.5 ESR, the CKEditor configuration form allows CSRF.
PUBLISHED: 2021-06-17
HashiCorp Nomad and Nomad Enterprise up to version 1.0.4 bridge networking mode allows ARP spoofing from other bridged tasks on the same node. Fixed in 0.12.12, 1.0.5, and 1.1.0 RC1.
PUBLISHED: 2021-06-17
An XSS issue was discovered in manage_custom_field_edit_page.php in MantisBT before 2.25.2. Unescaped output of the return parameter allows an attacker to inject code into a hidden input field.