After having attended the past couple of DEFCONs, I'm really excited to be speaking at DEFCON 18 this year. In anticipation of my presentation, "How to Hack Millions of Routers", I thought I'd take this opportunity to answer some questions, offer some background information, and give a quick teaser about the talk.
Most people assume that because they don't have remote administration enabled on their router, external attackers cannot access their router's administrative Web interface. However, for many routers this is simply not true; anyone with a registered domain can in fact gain full interactive access to the router's internal Web interface in order to exploit vulnerabilities or log in to the device (either via the router's default password or a brute-force attack), at which point they can view settings, change settings and generally do whatever else they want with the router*. However, this attack is not restricted to the primary Web interface; it can also be used to gain interactive access to SOAP-based services running on the router as well, such as Universal Plug-n-Play which requires no authentication at all. While this attack does not work against all routers, out of thirty different routers tested the attack was successful against more than half of them, including the venerable WRT54G from Linksys, ActionTec routers used by Verizon FiOS and DSL customers, and many others. Given the number and popularity of the affected routers, this translates into many millions of vulnerable routers deployed world wide, not to mention all the other routers that have not yet been tested.
The attack is actually a combination of many things, from browsers and JavaScript to firewalls and TCP/IP stacks, but it ultimately centers around DNS rebinding*. Although DNS rebinding has been publicly discussed for almost 15 years, many people still don't completely understand it. I've gotten several inquiries about the talk, and they generally boil down to two basic questions:
1) What is DNS rebinding?
2) What is so special about the DNS rebinding technique presented in this talk?
To understand DNS rebinding, let's examine why DNS rebinding is needed in the first place: the same domain policy. The same domain policy is a security policy that is enforced by your Web browser. That policy states that if you browse to https://www.evilhacker.com/, then that page from www.evilhacker.com can tell your Web browser to load content from other Web sites (images, JavaScript, CSS, iframes, etc), but it cannot see the responses from those Web sites nor access the content that is returned by those Web sites. In other words, JavaScript from www.evilhacker.com can only access content from www.evilhacker.com because that content comes from the same domain. This is a good thing, as you wouldn't want some JavaScript from www.evilhacker.com making unauthorized XmlHttpRequests to Web sites inside your local network or elsewhere.
The problem with this policy is that computers don't use domain names to communicate with each other; they use IP addresses. The idea behind DNS rebinding is:
1) Get the victim to load some JavaScript from www.evilhacker.com.
2) Convince the victim's browser that www.evilhacker.com has moved to a different IP address, say, 192.168.1.1.
3) Evil hacker's JavaScript is free to interact with www.evilhacker.com, which the browser now thinks is located at 192.168.1.1.
The difficult part in the above attack is convincing the victim's browser to switch IP addresses. Various methods of achieving this have been presented in the past, so why yet another talk on DNS rebinding attacks? Because quite simply, the common DNS rebinding attacks that have been discussed in the past are either not practical or simply no longer work:
o Setting low TTL values in DNS responses doesn't work anymore because of DNS pinning.
o Anti-DNS pinning attacks only work in older browsers (IE6/7, FF2.x), and even then the rebinding attack takes between 15 and 120 seconds to take effect depending on the victim's browser.
o The "multiple A record" technique can no longer be used to rebind to internal (RFC1918) IP addresses.
o In addition to browsers, third party plug-ins such as Flash and Java have implemented anti-rebinding measures.
Thanks to several features present in many popular routers and their underlying operating systems*, none of this will deter the attack discussed in this talk, which has been tested against live networks under real-world scenarios (with the appropriate permissions from the network owners, naturally). Common anti-DNS rebinding protections offered by services such as dnsmasq, OpenDNS and NoScript will not prevent this attack, nor will changing the router's internal IP address. The good news is that there are fixes that can be made by both vendors and end users to protect against this attack*. The bad news is that these are fixes that should have been implemented years ago, but instead have been ignored by both vendors and users alike.
Of course, what is a talk without a tool release? I will be demoing and releasing a tool that automates the entire attack and extends the target router's internal Web interface out to an external Web site where the attacker can access and browse the router's Web pages in real time, just as if he were sitting on the LAN himself. All the attacker needs is a user inside the target network to browse to the attacker's Web site. It's point-and-click hacking goodness that's fun for the whole family!
* To be discussed in more detail at the talk!
Source : Def Con
