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: Who knew face masks could also prevent the PII from spreading
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-15
Apache HTTP Server protocol handler for the HTTP/2 protocol checks received request headers against the size limitations as configured for the server and used for the HTTP/1 protocol as well. On violation of these restrictions and HTTP response is sent to the client with a status code indicating why...
PUBLISHED: 2021-06-14
A buffer overflow vulnerability in SonicOS allows a remote attacker to cause a Denial of Service (DoS) by sending a specially crafted request. This vulnerability affects SonicOS Gen5, Gen6, Gen7 platforms, and SonicOSv virtual firewalls.
PUBLISHED: 2021-06-14
magento-scripts contains scripts and configuration used by Create Magento App, a zero-configuration tool-chain which allows one to deploy Magento 2. In versions 1.5.1 and 1.5.2, after changing the function from synchronous to asynchronous there wasn't implemented handler in the start, stop, exec, an...
PUBLISHED: 2021-06-14
net/can/bcm.c in the Linux kernel through 5.12.10 allows local users to obtain sensitive information from kernel stack memory because parts of a data structure are uninitialized.
PUBLISHED: 2021-06-14
Cross-site Scripting (XSS) vulnerability in the main dashboard of Ellipse APM versions allows an authenticated user or integrated application to inject malicious data into the application that can then be executed in a victim’s browser. This issue affects: Hitachi ABB Power Grids ...