Linksys Router

As old as this issue is, you’d think it would be solved by now; in fact, everyone thought it was. Many browsers and plug-ins protect against it. But it showed up in a different form that no one had considered until it was  revealed at Black Hat. The hacker discovered that not only can you browse to your router’s web browser using the private gateway IP (192.168.xxx.xxx or whatever), you can also get there using its public IP–the address on WAN IP–even if you have disabled remote administration from the WAN side. Steve Gibson, in his usual, thorough manner, analyzed the matter in Security Now! episode 260.

And so the next-generation attack that was revealed last week, which I’m sure all of the various firmwares are in the process of scrambling around to fix right now, solves, well, what it does is it gets around the blocks against internal LAN access IPs by using your public IP. And of course the remote DNS server gets your public IP because that’s the IP from which the request comes to it. It’s emitted by your computer, asking for the IP address of attacker.com. Well, that comes from your public IP. So it’s able to return the public IP to the [attacker] script running in a plug-in, which then knows how to get around the use of private IPs on the LAN to access your router.

Everyone should immediately check this list to see if your router is vulnerable. If it is, then you should go to the manufacturer’s website to check for firmware updates to your router.

I want to discuss this in detail in two weeks because it’s an interesting type of attack that we haven’t discussed in the past. It’s been around and has been known for a while. And it’s sneaky. And it will make for a great detailed coverage in two weeks. It’s called a DNS Rebinding Attack. And it’s in the news now because someone named Craig Heffner is going to be presenting at the Black Hat conference at the end of this month his presentation titled “How to Hack Millions of Routers.”

Pretty clear, don’t you think? Well, it is–now that I look back on it–but you know how emotion can get in the way sometimes. Here’s our email exchange:

Me: Hi Steve, I’ve been a loyal Security Now! listener since Episode 1 and I value your insight on current security issues. Haven’t missed a single episode (If I did, I’d have withdrawal symptoms!) However, I have to take issue with your reporting in Episode #258, that there is something new about what is really an old, stale issue: DNS Rebinding Attacks. It seems that when someone wants some attention (not referring to you, of course) they take a new twist on this one. In other words–different guy, same vulnerability.

Steve: Hi Ken! Thanks very much for your note.  I certainly agree with you that DNS Rebinding has been around for awhile, and I did also mention that last week.  Mostly the reason I’m bringing it up is that active attacks using it are around again … but more than that … because it’s something that we’ve never covered in detail on the Security Now podcast and I think it’s a clever and conceptionally interesting vulnerability/hole/glitch.  It also perfectly demonstrates, I think, the inherent trouble with the ever-growing complexity of our systems.

Me: Hi Steve, So good to hear from you. Thanks for the clarification. DNS Rebinding certainly is a clever trick and am definitely going to be looking forward to your analysis of it. You’re not kidding about complexity in our systems being the inherent trouble. As you say “complexity is the enemy of security.” That’s one of my mantras.

Steve: Hi again Ken… I’ve also just realized that I can add DNS Rebinding Attack protection detection to my (still) forthcoming DNS Benchmark.  I’m already detecting and alerting users to domain name error (NXDOMAIN) redirections.  So checking for rebinding protection would be very cool too! Thanks again for your note!

For the record, I goofed. I should have thought it out a bit before I hit the Send button, but it resulted in a very pleasant exchange with a guy I respect, so I guess it’s all good.