I don't see anything here that Kaminsky didn't show at Defcon last summer, except maybe specifically attacking the home gateway. And that was by far the least interesting thing that he managed to come up with for his presentation. Too bad I have to miss DC this year - Dan's talk makes the whole thing worth it. That and watching hacker jeopardy whilst getting plastered.

I forgot to mention in my recent comment that DNS rebinding is, in fact, incredably scary / awesome. And for the most part all you have to do is write yourself a DNS server (Probably about 1/2 a line of Perl now) and get someone to query your domain. And then the things you can do are limited only by your imagination. There is some seriously scary potential there.

... when I said that no ressource on "my" network would be available if not behind a tightly-controlled server, with its own static IP and unique authentication (good old ettercap allowed me to bust a few local wannabe-hackers. "Noone is watching", riiiiiiiiight. Noone but the bofh!). And when I disabled remote administration on everything. I might have taken some heat at the time, but I feel good now.

IF he's on my network AND he knows my password THEN he can mess with my DNS

Or have I miised the point somehow?

How long before we see a dedicated botnet hosted on a generic router such as the bt home hub or the orange livebox??? once there are enough of them out there to make them a worthwhile target im sure it will happen.. and knowing these companies they will all have a standard generic remote assistance type password just to make sure they all fall at once.. and they'll be on a nice easy guess IP range too... can you imagine if they are all hijacked and locked out.. the isp will be subtley asking customers to reset or worse swap out there routers with an upgraded version!...

If you can mess with DNS then you can probably bypass or replace the SPF DNS record in order that your spammy IP address looks like a proper SMPT sender listed in the SPF record.

Someone said once that todays spam is of a higher technical standard of correctness than most peoples email setups. So in order to get through spam is starting to look too clean.

UPnP is an amazing thing. Who would have thought it was a good idea to have a service to automatically punch holes through a firewall from an active x control? Evil gates, that's who.

[It's a good thing Adobe has minimized the damage, because the problem itself is not easily fixed.]

Really? So Bind gets asked what's the IP addr for www.bar.com, sees that it's entry has expired, so goes off up the chain to find the new addr. It gets a response back saying www.bar.com -> 192.168.10.1. Wait a minute! A DNS resolve coming in from the WAN and it points to private address space?! Best drop that. Was that so hard?

Yes browser makers could flag resources - such as scripts - as having come from either the WAN or LAN and not allow them to change betwixt the two, but that's only one class of application you've fixed. Far better to squash the problem at its root, which is your DNS server.

I also struggle to believe this kind of attack will work outside of either the lab, or targetted attacks against one individual. You need your DNS to point to your www server when people visit your website to download the script, but point to private address space when the script is operating. That means whilst the script is iterating nobody else could access your www server.

It's an interesting attack, but all we "learnt" from it is DNS is insecure, which I'm pretty sure we knew nearly 20 years ago.

.....so what's wrong with numeric IP addresses? Is everyone so useless these days they NEED a readable host name?? I dont get it. Let's go back to the days of IPs, dial up, BBS ;) Sheesh....the sooner a large portion of the corporate internet vanishes into the ether the better.

"Yes, we know the attack requires the device to use a weak or non-existent administrator password, but that's not the point. The same technique can also be used to tamper with firewalls, databases and other resources that are attached to an IP address."

Um ... surely that IS the point? If the user has specified a decent password the attack won't work. Or have I missed something?

Also, care to specify which "firewall" would be susceptible to this kind of attack? I can't think of any off the top of my head which would be ...

Your point would be valid, except for a few things.

1: On most networks, to lower the time it takes to get a responce, you would want the same DNS to tell you where www.theregister.co.uk is as the one that tells you pinky is the network printer down the hall.

2: The whole point is you can get the PC, sitting inside your network, that www.blabla.net is both your favorite website and your home router. This home router as UPnP enabled, for example. Many do by default, linksys and netgear come to mind. Now, I can open your firewall to connect to your home PC from the net as if the firewall was not there. Or I could make your printer down the hall, with no one sitting next to it because it makes a lot of noise, spit out black paper to empty both the ink and the paper. 1000 pages of black paper, that will be fun to clean and pay for.

Now the fun part is, this also might work on alternative OS like OSX, Linux, BSD or anything else that as a browser ... Now everybody sucks.

[1: On most networks, to lower the time it takes to get a responce, you would want the same DNS to tell you where www.theregister.co.uk is as the one that tells you pinky is the network printer down the hall]

There is no issue with that.

Your DNS server will be authoratative for your local namespace (i.e. some poor bugger will have typed out all of the IP addrs and associated names in named.conf so names will be resolved immediately by your own DNS server).

That same DNS server can still resolve names out on the WAN as it usually does. theregister.co.uk, google.co.uk etc will all be cached locally presuming they pass the test (see below) and so will resolve quickly.

All you need to do is check the contents of the response before you pass it on to the client and cache it. You have four possibilities -

1. The response landed on your public interface, and the IP addr is routable. Good. Carry on as normal.

2. The response landed on your public interface, and the IP addr is not routable. Bad - bin it.

3. The response landed on your internal interface, and the IP addr is routable. Bad - bin it.

4. The response landed on your internal interface, and the IP addr is not routable. Good. Carry on as normal.

Those 4 simple rules (oh but were there 8...) allow you to segregate your LAN from the WAN and defeat DNS rebinding attacks for *ALL* applications. No need to wait on half a dozen different vendors patching their wares.

[2....]

Yes, you can print stuff on ONE guys PC. That's my point - unless you're into industrial espionage (where it *is* a valid attack) then it has a very low return on investment. Would you rather log into one guys router, change his DNS and wait a week or two for him to log into www.mybank.com or send a few million emails from www.netwest.com telling you to log in for special offers?

The fishing spam job is so much less effort for a decent return. As I pointed out above, whilst you are committing a DNS rebind attack no bugger else can look at your website as it resolves to non-routable addresses. You could partially get around this by hacking your DNS server to give the proper IP addr on first request, then iterating through non-routable addresses on subsequent requests, but given how few DNS servers service how many peoples requests that is a very unreliable method. In short, this attack works on one person at a time.

You're totally right about alternative OSes tho - it's a very useful attack if you want to spy on a competitor in a tender process, and either you don't know what OS/AV they use, or you know they are locked down and don't allow non-whitelisted .exes to be run. Rather than email a trojan, you can attack through their browser.

Before y'all get smug, I'd like to mention that I binned one home router after the _third_ time I found it had reverted to the default password, without anybody pressing the reset button or any apparent power failure (other equipment on the same breaker was set to not reboot on power recovery, and was running the whole time). So unless you are in the habit of checking that your router still "believes" in the settings you last made, you may be one of the "muppets" you disdain. (Airlink, BTW, but since they are one of many that just crank out clones of chip-maker reference designs, I wouldn't suggest feeling smug yet)

It looks like nobody here actually understands the concept of a rebind. The idea is that a dns reply may have more than one address on it, so if I tricked you (or your browser) into resolving ftp.bar.com (suppose I control the dns server there) I can respond with an IP for ftp.bar.com /and/ an IP for google.com. Obviously I do not control google's dns, but many OSs and DNS proxies will cache these gratuitous replies, so that the next time you try to visit google, you get sent to an IP of my choice. And you can get them to virtually never expire.

And that is only the beginning. Clearly this is above the heads of everyone that said "I control my DNS server, nobody can own me." Fact is that as of Kaminsky's DC15 presentation, there were just about no servers out there that protected against this sort of attack. I hope that has changed by now, but I wouldn't count on it.

So that would be like DNS cache poisoning, right? Like explained here: http://cr.yp.to/djbdns/notes.html

People are on the whole getting it - but you are describing cache poisoning not rebinding.

Your DNS is not authorative for google.com, so it would be rejected, of course what you say is true some systems do accept non authoritative systems to supply their DNS information.

DNS rebinding works because DNS pinning happens in the browser, but is not pinned for Flash, ActiveX or Java whch maintain their own pinning.

So the TTL is set to a very low time, and then switched after the initial page request so the included object with a different resolve pin thinks it actually on an internal IP (ie you ran it from your system), they then explore your network.

The second location may be necessary to get the information back though, so that maybe where you got confused.

If you run your own name caching server, you go to the TLD name servers to get your recursive call to find the authoritative servers - now you can still be caught out if you don't check the TTL or if an outside domain is trying to bind to an internal IP number. But if you say TTL below 1hr reject and if the bind shows an internal number definitely reject, you cannot be 'owned' by this procedure.

The procedure to cache poison relies on a system trusting another system that is not authoritative, that means your setup has to accept DNS information for a domain from a system that is not authoritative or the top level domain name systems are poisoned, that is not rebinding though.

" It gets a response back saying www.bar.com -> 192.168.10.1. Wait a minute! A DNS resolve coming in from the WAN and it points to private address space?!"

You just described the "smart" solution that a classmate devised to solve the "non routeable IP" problem. His ISP gives 10.0.0.0/8 range private IPs, so when he distributed his IP for everyone to listen his "internet radio station", nobody except those using the same ISP could tune in. So he set up one of those sytes.net domains ... to point to his 10.x.x.x IP.

I got to laugh very, VERY hard at the double whammy: not only this guy was too stupid not to understand why this was *still* not going to work, but having a public DNS to allow private IPs in their registries.

I can't remember which hosting service did this, but there is someone out there that has public DNS pointers to non-routeable IP address spaces. Oops!