Public IP DNS rebinding: Another reason not to use default passwords

Craig Heffner, senior security engineer for Seismic LLC gave a talk at this year's Black Hat conference called "How to Hack Millions of Routers". A rather dramatic title, but his research uncovered an exploitable weakness.

Some background
The new attack leverages several concepts that aren't well known. With that in mind, I would like to step through the process in a bit more detail.

DNS was created because it's easier to remember words (domain names), than numbers (IP addresses). You type in a name and the Web browser asks the appropriate DNS server for the IP address. In IT-speak, that means there is a binding between the domain name and associated IP address.

What might not be known is that quite often more than one IP address is bound to the same domain name. This is to facilitate load balancing or redundancy for Web sites with critical uptime requirements. Using NS Lookup, one can see that Google has six IP addresses bound to Google.com:

Now let's look at how the attack works.

The original attack
The DNS-rebinding attack requires the bad guys to set up a malicious Web site. Or more insidiously, malicious Web ads that are published on trusted sites. For example, the New York Times was caught up in such an attack.

To help explain, let's say that example.com is such a Web site. The victim visits example.com, causing a client-side script or applet to be downloaded onto the victim's Web browser. Once entrenched, the attacker's Web application asks to create a connection with example.com, separate from the Web browser and hidden from the victim. The DNS server for example.com will then return the correct IP address for example.com, along with the private IP address of the victim’s computer.

Once that information is cached, the Web app asks for more information from example.com. Knowing what’s going on, the attacker's server responds with what is called a TCP reset. This is meant to deceive the supposedly legitimate Web application (set up by the script) into believing the first IP address used for example.com is not working. So the Web application checks its DNS cache and tries the second IP address for the domain name example.com.

Here's where it gets interesting. By using the second trusted IP address the malicious browser applet gains network-level access to the victim's computer. That means the attacker can establish a session with any Web server on the internal network if the Web server's private IP address is known.

Guess what uses Web servers--most network devices and Web-based email servers. All sorts of havoc can now be wreaked by the attacker.

Fixed the problem?
I mentioned earlier that this problem was fixed. Developers realized what was happening and changed how Web browsers handle DNS responses. If the response contains a non-routable (RFC 1918) IP address, the packet is to be dropped. This change negated the attack vector and it disappeared for years.

The new attack
It's common knowledge that configuration pages for residential network devices are accessed by entering the device's internal IP address in the Web browser. We now also know that spoofed DNS responses using private IP addresses are dropped.

So routers and such are safe now, right? Well maybe not. For some reason, you can enter the public or routable IP address of gateway devices/routers in the Web browser and gain access to the configuration Web page. Remember now, that http request is coming from a computer on the internal network.

What's more, this approach works regardless if public-side access has been disabled in the gateway. I have an ActionTec gateway on my perimeter, and I was able to access the configuration pages using the public IP as shown below:

Heffner and the people at Seismic diligently tested most residential gateway routers and have come up with the following list of secure and vulnerable devices or third party firmware:

What this means

Prevention is simple
This attack requires knowing the username and password to access the gateway device's configuration Web pages. The bad guys are hoping the default settings are still in use. So, make it hard for them. Change the user name if possible and replace the default password with a nasty and hard to figure out one. That should stop the attackers.

Another option is to require each and every Web site to ask permission to load any kind of scripting. This is easy to do if you use the Firefox Web browser. Get the NoScript add-on. In fact, Giorgio Maone, NoScript's developer added a new feature in the latest version of NoScript. The feature is called Application Boundaries Enforcer and one of default rules prevents the DNS rebinding attack.

One final suggestion is to use well-respected DNS servers and hard code their IP addresses into the network adaptor's configuration. I use OpenDNS. Doing so eliminates this and many other DNS-related exploits.

Final thoughts
Heffner's public IP rebinding attack is dangerous when successfully applied. Fortunately, it's complex to pull off and easily thwarted. All we have to do is get people to stop using default login credentials. Please spread the word.

Michael Kassner has been involved with with IT for over 30 years. Currently a systems administrator for an international corporation and security consultant with MKassner Net.