Millions of routers vulnerable to new version of old attack

Tagged: hackers, router, Computer Hardware, Technology
Source: Ars Technica - Read the full article
Posted: 5 years 49 weeks ago

A presentation due to be shown at the Black Hat security conference at the end of the month will show that many of the routers used for residential internet connections are vulnerable to attack by hackers. The attacks would allow traffic to be redirected and intercepted, in addition to giving hackers access to victims' local networks.

The title of the presentation, "How to Hack Millions of Routers," gives a clear indication of the scale of the potential issues. Popular router models from Netgear, Linksys, and Belkin were found to be vulnerable, including models used for Verizon's FIOS and DSL services, as were widely-used third-party firmwares such as DD-WRT and OpenWrt. About half the routers tested did not appear to be vulnerable.

A list of tested routers can be found here; every router with a "YES" in the last column was successfully attacked.

The research was done by Maryland-based security consultancy Seismic. Craig Heffner, a researcher with the company, will both present the research at Black Hat and release a proof-of-concept tool to demonstrate the problem in practice. Heffner believes this is the best way to get router manufacturers to release firmware updates to fix the issue.

The attack uses a technique called DNS rebinding to subvert protections built into web browsers that are intended to restrict what scripts and HTML can do. DNS is the system that maps from human-friendly names—such as ""—to computer-friendly IP addresses. DNS allows one name to be mapped to multiple IP addresses, which is an important technique to provide load balancing and fault tolerance, as it allows the load to be spread among several different machines. In a DNS rebinding attack, the attacker controls both a website and the DNS server used to send traffic to the site. Each time a victim visits the website, the DNS server is updated to include the visitor's IP address as one of the IP addresses used for the site.

This is useful because it allows a browser protection called the "same origin policy" to be undermined. Normally, a web browser restricts JavaScript access such that a script can only manipulate pages that originate from the same domain. This means that, for example, a page from cannot manipulate a page from—the two have a different domain and, hence, a different origin. 

With DNS rebinding, however, the attacker can make the browser think that any computer he chooses has the same origin as his own malicious page—he just has to create a DNS entry pointing to that computer that matches the DNS name for his malicious site. So, by creating DNS entries for computers in the victim's LAN, the attacker can trick the victim's web browser into accessing machines on the victim's own network.

Most computers on a home LAN won't be running a web server, so on the face of it, this might not seem especially useful. However, one kind of machine typically does run a web server: the router. SOHO routers generally have administrative front-ends for configuration and monitoring. Though these front-ends are normally password-protected, most people don't bother changing the default passwords. And, even when they do change the password, security flaws within the front-end may allow the password to be bypassed anyway. With access to the router, the attacker could reconfigure it to (for example) route all DNS lookups through a malicious server, which would allow traffic to be monitored and intercepted.

DNS rebinding attacks are not new; in one form or another they have been around for nearly 15 years. Some environments such as Java and Flash have taken measures to reduce the possibility of exploitation—they cache DNS lookups to ensure that traffic destined for the same name always targets the same IP address. This prevents access to the local network.

Browsers, too, attempt to protect against such attacks. However, Heffner says that his variation of the attack bypasses the browser-based protection, allowing DNS rebinding to occur successfully. He also says that the bypasses have been known of for a long time; his attack is more the bringing together a set of known techniques rather than something novel per se. 

This is, in part, his motivation for releasing a tool to perform such attacks—he says that browser writers and router vendors have had "ample time" to fix the problem, but haven't done so. Demonstrating and distributing an effective exploit is, he believes, the best way to prod them into action.

In the meantime, the best defense is probably to ensure that your router does not use the default password. Though this can't guard against exploitation of actual flaws in the router's software, it will at least prevent trivial attacks from being made. Changing the router's IP address away from its typical default might also serve as some protection; though the attack could be used to target any IP address on a local network, a little obscurity tends to work well against widely targeted attacks.



GraysonPeddie's picture
Joined: 10/29/2006
Posts: 570

My Linux box is set with a very strong password (8 characters with capital/lower case letters with no vowels, numbers, and symbols) and it uses iptables. Can it be vulnerable?

This is the firewall configuration I have:

# Generated by iptables-save v1.4.8 on Sat Jul 10 10:14:52 2010<br /> *nat<br /> :PREROUTING ACCEPT [75044:8540159]<br /> :POSTROUTING ACCEPT [1360:169898]<br /> :OUTPUT ACCEPT [37035:3065074]<br /> -A POSTROUTING -o eth0 -j MASQUERADE<br /> COMMIT<br /> # Completed on Sat Jul 10 10:14:52 2010<br /> # Generated by iptables-save v1.4.8 on Sat Jul 10 10:14:52 2010<br /> *filter<br /> :INPUT DROP [45:5599]<br /> :FORWARD ACCEPT [0:0]<br /> :OUTPUT ACCEPT [13:2823]<br /> -A INPUT -p tcp -m tcp -m multiport --dports 22,25,53,80,3389,5060,5080,5900,5901,5902,10000 -j ACCEPT<br /> -A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT<br /> -A INPUT -p udp -m udp -m multiport --dports 5060,5080 -j ACCEPT<br /> -A INPUT -i lo -j ACCEPT<br /> -A INPUT -i eth1 -j ACCEPT<br /> -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT<br /> -A FORWARD -i eth1 -o eth0 -j ACCEPT<br /> -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT<br /> COMMIT<br /> # Completed on Sat Jul 10 10:14:52 2010<br /> # Generated by iptables-save v1.4.8 on Sat Jul 10 10:14:52 2010<br /> *mangle<br /> :PREROUTING ACCEPT [1585:191669]<br /> :INPUT ACCEPT [1338:146477]<br /> :FORWARD ACCEPT [246:44963]<br /> :OUTPUT ACCEPT [1102:222571]<br /> :POSTROUTING ACCEPT [1348:267534]<br /> :asterisk - [0:0]<br /> :common - [0:0]<br /> -A FORWARD -i eth1 -o eth0 -j MARK --set-xmark 0x3/0xffffffff<br /> -A FORWARD -i eth1 -o eth0 -j common<br /> -A FORWARD -i eth1 -o eth0 -j asterisk<br /> -A FORWARD -i eth1 -o eth0 -p icmp -j MARK --set-xmark 0x1/0xffffffff<br /> -A FORWARD -i eth0 -o eth1 -j MARK --set-xmark 0x3/0xffffffff<br /> -A FORWARD -i eth0 -o eth1 -j common<br /> -A FORWARD -i eth0 -o eth1 -j asterisk<br /> -A FORWARD -i eth0 -o eth1 -p icmp -j MARK --set-xmark 0x1/0xffffffff<br /> -A asterisk -p udp -m udp --sport 5060 -j MARK --set-xmark 0x1/0xffffffff<br /> -A asterisk -p udp -m udp --dport 5060 -j MARK --set-xmark 0x1/0xffffffff<br /> -A asterisk -p tcp -m tcp --dport 5036 -j MARK --set-xmark 0x1/0xffffffff<br /> -A asterisk -p udp -m udp --dport 5036 -j MARK --set-xmark 0x1/0xffffffff<br /> -A asterisk -p udp -m udp --dport 4569 -j MARK --set-xmark 0x1/0xffffffff<br /> -A asterisk -p udp -m udp --sport 10000:20000 -j MARK --set-xmark 0x1/0xffffffff<br /> -A common -p tcp -m tcp --dport 80 -j MARK --set-xmark 0x2/0xffffffff<br /> -A common -p tcp -m tcp --dport 8080 -j MARK --set-xmark 0x2/0xffffffff<br /> -A common -p tcp -m tcp --dport 443 -j MARK --set-xmark 0x2/0xffffffff<br /> -A common -p tcp -m tcp --dport 110 -j MARK --set-xmark 0x2/0xffffffff<br /> -A common -p tcp -m tcp --dport 119 -j MARK --set-xmark 0x2/0xffffffff<br /> -A common -p tcp -m tcp --dport 25 -j MARK --set-xmark 0x2/0xffffffff<br /> -A common -p udp -m udp --dport 53 -j MARK --set-xmark 0x2/0xffffffff<br /> -A common -p udp -m udp --dport 68 -j MARK --set-xmark 0x2/0xffffffff<br /> -A common -p udp -m udp --dport 22 -j MARK --set-xmark 0x2/0xffffffff<br /> -A common -p udp -m udp --dport 3389 -j MARK --set-xmark 0x2/0xffffffff<br /> COMMIT<br /> # Completed on Sat Jul 10 10:14:52 2010

Webmin is not installed. It allows you to access the core parts of your system, such as iptables and network interfaces, including server programs like Apache and OpenLDAP Server. It's not been used since I have my server setup without it and with config files backed up. It's the beauty of Linux. I run Ubuntu Server 10.10 Alpha 2. :)

PC: Tt Core V21; Kaveri APU, 16GB RAM, GTX 960, Arch Linux
Server: Rosewill Legacy V6-S, AMD Athlon 5350 APU, 8GB RAM, 90W DC-IN PSU, Ubuntu Server