Slashdot Mirror
DNS Rebinding Attacks, Multi-Pin Variant
Morty writes "DNS rebinding attacks can be used by hostile websites to get browsers to attack behind firewalls, or to attack third parties. Browsers use "pinning" to prevent this, but a paper describes so-called multi-pin vulnerabilities that bypass the existing protections. Note that, from a DNS perspective, this is a "feature" rather than an implementation bug, although it's possible that DNS servers could be modified to prevent external sources from being able to point at internal resources."
http://www.getfirebug.com/
Not without Javascript you aren't!
The article mentions Java and Flash are problems as well.
Heh, my boy, you just summed up the Web's great affliction in a nutshell.
This particular exploit vector is especially troublesome because turning off the ability to point a name at multiple IPs would break a large part of the Internet. But it wouldn't be an issue for web browsers if we didn't see the need for the Web to be dynamic and interactive. Dynamism and interactivity are really not built into HTTP. It would be more accurate to say that HTTP was designed to be just the opposite.
Website designers and software makers have been trying to turn the Web into a collection of desktop applications since about the time the Web was invented. This runs counter to what Tim Berners Lee intended. HTTP is stateless for a reason. I honestly don't think he made HTTP stateless because he envisioned the havoc that malicious websites could cause, but the principle of agnosticism (i.e. providing content without knowing anything about the requester's capabilities) that's implicit in the protocol is inherently more secure than the desire of many to make websites into remotely-accessed desktop apps.
Unfortunately, this particular horse bolted from the barn in the earliest days of the web, and there's no easy way to get it back in. A wise web developer will nonetheless read and understand the HTTP protocol. Its statelessness and agnosticism can be strengths when considered in the proper light....
...Yeesh, that last sentence makes me feel like Yoda counselling young Luke.... 8^/
Crumb's Corollary: Never bring a knife to a bun fight.
I did RTFA, and it seems to me they made an oversight in the fact that most ISP/corp sites use a caching DNS server. A repeated lookup to the same domain will return the cached result. Their POC depends on the client doing another lookup and getting a different result. This would attack would depend on the client being able to the attacker's DNS.
Now they do say that the attacker DNS returns more then one A record for each request. But they are ignoring the fact that the serial number of the zone would have to change for a refresh to not get cached. And even if they did create a new zone record for each visit, with the target's IP (seems unlikely), all the servers back to the client would need to respect it. Again, my ISP Qwest, has a bad habit of ignoring the TTL in my zone files.
example 1:
target lookup (T0) -> www.attacker.com
www.attacker.com -> 192.168.0.1
target lookup (T1) -> www.attacker.com
ISP/site cached reply -> 192.168.0.1 (attack failed)
Example 2:
target lookup (T0) -> www.attacker.com
www.attacker.com -> 192.168.0.1
target lookup (T1) -> www2.attacker.com
attacker's ISP cached reply -> 192.168.0.1 (attack failed again)
The only case I can see this working if the zone records contain an IP for some third party source that they want to try and abuse. So say www2.attacker.com points to 10.0.0.1 and that number is static in their zone record. Which appears to be much less efficient zombie scan with IP spoofing.
And finally, this is all dependent on the attacker tricking the client into loading Flash/Java/Javascript from their box. Another win for noscript.
For now, bind9 does not support this. See the relevant thread.
If you read the original article, you will note that they generated exploit stats by utilizing an ad network. You don't need to visit a "bad" website, you just need a "bad" ad while visiting a normal website. Cool! What server do you use, and how did you configure it to do this?
OpenDNS ( http://www.opendns.com/ ) works pretty well. I typically go internal cache, external ISP, openDNS on my systems. Keeps Windows boxes in line, especially.
-theGreater.
One point placed in the paper:
if the web browser and applet are connecting to the server via a proxy, then neither the web browser nor the applet have control over "connecting to the same IP address from which they were loaded"
Therefore, if a proxy is involved then current versions of the JVM are still vulnerable.
Fortunately, the paper goes into detail about this later on:
The irony is that many organizations use proxies to implement both content and virus filtering. The use of these proxies themselves makes their web browsers MORE susceptible to these pinning attacks.
--jeffk++ipv6 is my vpn
Change dom.max_script_run_time to a smaller (or larger) number of seconds.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON