Web Development

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

DNS rebinding first appeared 15 years ago. It was a clever penetration technique until web browsers were fixed. It now appears there is a work around for the fix and residential gateway devices are the targets.

DNS rebinding first appeared 15 years ago. It was a clever penetration technique until web browsers were fixed. It now appears there is a workaround for the fix and residential gateway devices are the targets.

---------------------------------------------------------------------------------------

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:

Mr. 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

This attack vector is unsettling because it's subtle. In most households, the gateway device provides DHCP information to all computers on the internal network. Besides providing the proper IP address for the computer, DHCP also publishes what DNS servers to use. If attackers gain access to the gateway device, they could change the DNS server entries to point to their malicious DNS servers and that's not good at all.

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

Mr. 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.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

43 comments
Craig_B
Craig_B

This may work, though I have not tested with a home router. In Windows you can do the following to block a host: route -p add External_IP mask 255.255.255.255 Bogus_GW_IP External_IP = your routers external ip address Bogus-GW_IP = Made up internal address, never really used. Example: route -p add 206.46.232.45 mask 255.255.255.255 192.168.45.254 Now you can't get to the external ip address from that machine.

Ocie3
Ocie3

Long ago I learned the hard way to change the default password on a router upon installing it (whether to also change it often ...). However, either Comcast or Bellsouth told me to not specify a user-name, only a password. Nonetheless, since the Linksys WRT54G is on the list, I decided to access it with the default gateway [i]internal[/i] IP address, to check the firmware date. So, after I tabbed from the user-name field and entered the [i]strong[/i] password, the following string was appended to the message that is ordinarily displayed on the panel above the user-name and password lines: [i]The site says: "level_15_access"[/i] (but not in italics) The router is currently connected to Comcast broadband. Then I visited [i]GRC Shields Up![/i] to get the public IP, in the course of checking the status of the ports (all remain stealthed), and entered it into the Firefox 3.6.8 location field. After three timeouts, it did not seem accessible by that method either. Evidently, now I cannot access the configuration page of the router, which is my personal property. I'm not sure what, if anything, I will do about that, but Comcast takes forever to fetch pages from certain web sites and it seems that it will never fetch some of them at all. The Speakeasy speed test reports the same numbers as for 1.5 mbps DSL. [b]Note:[/b] Security Now! #260 released 08/05/10 is about "DNS Rebinding".

pgit
pgit

Here we go again... why don't manufacturers of low end routers force the user to set a unique user name and password, and a strong one at that? Out of the box the WAN interface should be OFF and only enabled after a pass is set. The internal web access doesn't need a 'default' user/pass. Make it such that as soon as you open a browser you are connected to the router, on a dialog to set the user/pass. Why oh why is this so hard for the manufacturers to comprehend?? I use OpenDNS on my systems, but not all of my clients want to do so. I have succeeded in getting all but a handful of them to use noscript. Those that had problems needed little convincing. One office experienced a horrific and costly attack that gummed up all the boxes on an affected segment of a LAN. Accounting was down, completely. Almost a dozen computers. They graciously allow me to use the example in the course of pushing best practices generally. It was particularly bad because folks were hopping mad in all directions; customers who couldn't get information and employees who had paychecks delayed. BTW I hadn't dealt with them prior to this mess. They had done everything in house, sort of a "my cousin Fred over in the paint shop knows a bit about computers" approach. Things are very different there now, no facebook on company hardware any more, and yes, we will do updates. (they turned them all off and never bothered to check "to save time")

JackOfAllTech
JackOfAllTech

My Firewall is set to deny access to all requests except those previously approved by me so these scripts would not work on my network. I also wrote a program that runs everytime I log on that verifies my router is still using OpenDNS - if not it would tell the router to shut down all internet traffic and alert me.

CyberN
CyberN

I just discovered that the problem I have been experiencing with my home network since mid July included a hack to my routers DNS settings and it was affecting all my systems. In the registry on each system: HKLM\System\CCS\Services\Tcpip\Parameters: DhcpNameServer = 213.109.65.44 213.109.75.130 1.1.1.1 I recommend everyone reset their routers and at a minimum set strong passwords immediately. The DNS server addresses above are in Russia and and Australia. For several weeks all my internet activity was funneled through these and I could not find any infections to blame for the redirects and other issues I was experiencing. It's not just a theory anymore! BEWARE!

Neon Samurai
Neon Samurai

And why did you black out the info? We already know your using Administrator/password1. :P Seriously though.. very nice summary of the old and new issues with DNS rebinding. With access on an external server and my own .lan and router, I'll be playing with this as soon as time permits. If one doesn't know how to break a thing, how can they know how to fix a thing?

tbmay
tbmay

...when this started making ripples, my concern was no more over routers than it was a few years ago when rebinding was making the news. Obviously much of the public still isn't versed enough, or doesn't care enough, to change their default passwords but the fact that someone hacks someone linksys on their home network isn't that much of a concern for me. I was more concerned about OTHER network servers running web services behind a firewall. Firewall circumvention is a serious issue that has could have disasterous consequences. My client firewalls are all OpenBSD and I have no web management on them. You have to know your cli. I zip them up tight but I spent a lot time looking at this recent one to determine if I needed to make any changes. Not because I thought they'd get into the firewall, because they won't. But because I was afraid they might get into a private web server.

dawgit
dawgit

In many areas you might just find yourself with a fine for leaving your wireless open. Germany is so anyway, as is other areas. Loss of (more than a few) Euros tends to keep people more aware, and secure.

santeewelding
santeewelding

The lights on my BEFSR41 arrange themselves occasionally into an evil grin. Kidding. No defaults here.

Michael Kassner
Michael Kassner

Residential gateways maybe at risk to outside take over.

Michael Kassner
Michael Kassner

I do not see why that would not work. Thanks for sharing.

bryantc
bryantc

While I like that the routers are easy to setup so people do not need to hire someone to get them connected to the Internet, I hate that they do not require a user name/password change at start up. I have had several customers both residential and business that could not remember the password to the router. Each time I have tried the default password and gained access. I had one customer that did not want the password changed so I packed my gear to leave. I refused to work on a system that was vulnerable and not being allowed to secure it. I wish them the best of luck!

Michael Kassner
Michael Kassner

Would be to hard code the DNS servers into each computer. That is unless you have a whole bunch of computers. I mention this as there are other attacks that gain admin rights to certain routers. I would also suggest seeing if there were any updates for your router.

Michael Kassner
Michael Kassner

To figure out why some vendors allow using public IP addrs to access the gateway from inside.

Michael Kassner
Michael Kassner

Not that many IT types are aware of the original DNS rebinding attack against Java. You are correct, the ability to circumvent the firewall or any perimeter defense is an issue. Yet, there are many other attacks that are easier to carry out. My concern is that this attack is below the radar. Being able to inject malicious DNS servers into the mix has all sorts of implications.

Michael Kassner
Michael Kassner

Oriented on using default login credentials. Is the EU concerned about that as well?

Michael Kassner
Michael Kassner

Yet, still on the list. It's downstream of your DSL gateway though. Right? Edit: Spelling

dawgit
dawgit

It looks like Christmas around here at night. I sure hope they don't get evil on me. ]:)

seanferd
seanferd

Craig caused a bit of consternation by announcing this and and saying that such -and-such is no protection against the attack, then going incommunicado. Although he did say that all the individual bits of the attack are already known. I'm not big on "responsible disclosure" as defined by some organizations, but I'm not sure why he announced it the way he did prior to the presentation. I think some parties took this the wrong way as well, but that is what happens when poor communication is involved. (And no, I don't mean router vendors - they should know far better by now.) What I thought was one of the more interesting aspects of this attack was exposing what is wrong with the weak end system model. That just doesn't seem right, and probably should have been changed long ago.

Neon Samurai
Neon Samurai

Another aproach would be to adjust your router firewall rules though not as simple as doing a local host route or local host file entry. I think what is happening is the Forward rules are allowing your internal traffic to hit the external IP. Adding the missing Forward rule to stop that behavior may protect all internal nodes centrally. I'd have to boot up a VM and muck with iptables to confirm it. INPUT/OUTPUT are pretty obvious but I've not worked with the FORWARD rule tables enough to give experience.

Michael Kassner
Michael Kassner

Cisco's Valet. It changes the password during setup.

Neon Samurai
Neon Samurai

That would be my guess at a technical level but there will, of course, be some human factors to cause it. One would think if I disable "admin from WAN" that my external IP device would not recognize the request even from an internal IP.

Neon Samurai
Neon Samurai

Attacks only ever get easier though and this one has potential to easily mature into a button push. I'll be watching my Metasploit updates to see if this turns up weaponized for valid uses.

tbmay
tbmay

....is fashionably lighter than it used to be.

dawgit
dawgit

The Laws have been changing rather rapidly here in the last few. It does get a bit confusing. The point is, that by locking down all the networks, DNS relays are reduced. Sort of.

Neon Samurai
Neon Samurai

Default uname/passwd is no different than default OPN encryption in my view but I'm also curious on how the EU or at least Germany views it.

Michael Kassner
Michael Kassner

So, my thoughts were that he was helping the manufacturers before he started disclosing. You know Sean, they have to do the PR stuff when Defcon and Black Hat are here. It's their payback for their hard work the rest of the year. Kind of like the fact that professors need to publish to retain tenure. Edit: Spelling

Neon Samurai
Neon Samurai

As we call it in the family of early colour changers. :D

Neon Samurai
Neon Samurai

Good on Cisco.. here's hoping that can be passed all the way through the product line from enterprise too consumer basics.

seanferd
seanferd

thirty-odd-six: I think this is awesome for some reason. safe hex: Perhaps not the first time I've seen this, but you use it so well. Vendor default passwords really should have disappeared by now. Sequential default "serial passwords" are nearly as bad.

Neon Samurai
Neon Samurai

.. I probably still got lots of time to fetch the thirty-odd-six. On the other hand, arpwatch, kismet and practicing safe hex do wonders for when you can't see the enemy. Now if only vendors would help out by delivering unit specific defaults or, ideally, uname/password setup at first use. The fact that we can still use default password lists is madness.

Michael Kassner
Michael Kassner

That he might have been working with router vendors up until the presentation.

seanferd
seanferd

If the paper had been released, I don't think there would have been any questions. I was more or less purposefully vague, but what I meant was that he poked a couple people with some specific comments (not router vendors), but did not follow up with further information, and did not reply to inquiries. A simple, "Wait for DefCon/Blackhat," probably would have sufficed. Again, I think the people who were prodded a bit reacted in about as useful a manner as Craig did in delivering his comments. That is to say, not at all useful.

Editor's Picks