Demo shows how web attack threatens fabric of the universe
All hail the power of DNS rebinding
RSA Showing how the web's underpinnings can be abused to attack assets presumed to be secure, a researcher unveiled a website that can log into a home router and change key settings, such as administrator passwords and servers used to access trusted web destinations.
Rather than creating a trojan or other piece of specialized malware to access servers or other devices behind a firewall, researcher Dan Kaminsky, a director of penetration testing firm IOActive, showed how a web browser can do much the same thing. His demo uses so-called DNS rebinding, an attack technique that uses fraudulent IP addresses to breach a network's security.
DNS rebinding can be used to subvert the same origin policy, which prevents pages or data loaded by one site from being modified by pages or data loaded by a different site. Because a single destination can have more than one IP address associated with it - and because nothing prevents one site from associating itself with anyone else's IP - DNS rebinding attacks fool a browser into letting one site tamper with a server or other resource that normally would be off limits.
"It kind of sort of breaks the entire security model of the web," Kaminsky said of the technique. "At one moment bar.com can point to server in Europe [and] the next moment it can point to a printer down the hall. We were depending on the web security model to prevent this very thing from happening."
To demonstrate the attack in action, he visited a website that opened the browser-based configuration page of a D-Link wireless router and change several key settings. 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. (It's worth pointing out, too, that weak or non-existent passwords are depressingly common.)
And of course, security weakness isn't the fault of a single vendor or even a handful of them. It's the collective fault of everyone who's played a hand in shaping the net over several decades. The protocols that allow a browser to find a website can also be used to sneak past a company's firewall to rifle precious resources.
DNS rebinding isn't the only way whitehat and blackhat hackers have been able to force their way into routers and other network-attached devices. Cross-site script (XSS) attacks, which allow attackers to inject malicious code into trusted web pages, have been known to do the same thing. So has Universal Plug and Play (UPnP), a feature that ethical hacking outfit GNU Citizen in January said made many home routers vulnerable to take-over simply by luring an attached computer to a booby-trapped website.
But those methods are made possible by design flaws, either in the router or in a software component, such as Adobe flash, according to Kaminsky. That means they can be fixed in a relatively short time. Indeed, Adobe today pushed out a major Flash update that Kaminsky said neutralizes the router attack using UPnP.
The update also minimizes much of the damage that could have been caused by Kaminsky's DNS rebinding attack. Previously, Kaminsky could commandeer devices using a host of protocols, including Remote Desktop, Windows file sharing, and proprietary Oracle database calls. Now, the attack is limited to devices with web interfaces.
It's a good thing Adobe has minimized the damage, because the problem itself is not easily fixed. Plenty of legitimate websites balkanize their various services across more than one IP address, making so-called DNS pinning unworkable. Eventually, he says, browser makers will be forced to build in controls, but he said that won't happen for a while.
So in the meantime, IT administrators need to consider the vulnerability carefully when deciding how to attach various devices to their network, and home users should make sure their routers have robust passwords. To that end. Open DNS, a company that provides a safer alternative to ISP-provided DNS lookup, today unveiled a new option that allows users to block suspicious responses, such as those from the outside that provide a URL with an IP address for a router or other internal device.
Beyond that, learn to live with DNS rebinding, Kaminsky said. "This bug is not going away anytime soon." ®
" 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!
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.
Re: Clearly you guys don't understand
So that would be like DNS cache poisoning, right? Like explained here: http://cr.yp.to/djbdns/notes.html