[ Flash DNS Rebinding Attack Explained ]

Instead of waiting a couple days to post about this, I guess I'll do it now. It's a pretty interesting flaw and since no one has posted the technical details of it yet, I'll be the one to do it.

First of all, this attack relies on DNS canonicalization differences between the browser and Flash. I'm going to pick on IE for this example.

So let's say your DNS search domain is mycompany.com and let's say your browser tries to go to the evil.com website. If evil.com can't be reached your system will start to look through your search domain by performing a DNS lookup for evil.com.mycompany.com (this is difficult because I need to be careful of my use of periods).

On the other hand, if your browser tries to go to evil.com. (notice the dot(.) on the end of that domain name) and it can't connect to it then it won't do any further lookups. It treats evil.com. as an absolute domain (I'm probably not using that terminology correctly, oh well).

The important thing to know here is that IE and Flash treat the differences between evil.com and evil.com. differently.


IE:
You go to evil.com, DNS lookup is performed for evil.com, the browser pins the resulting IP to evil.com and life is good. Then you go to evil.com., IE sees evil.com. as a totally DIFFERENT domain, performs a DNS lookup, pins that IP to evil.com. and life is still good.

All of the cross domain restrictions are in place that you would normally have. XMLHTTP requests are blocked, iframes are protected, etc.


Flash:
The SWF originates from the evil.com domain so URLLoader requests can only be made back to the same domain. But, Flash sees evil.com and evil.com. as THE SAME DOMAIN.


Attack:
Armed with the information above, we can come up with an attack scenario. Since IE treats evil.com and evil.com. as different domains and Flash treats them as the SAME domain, this means pwnage.

Flash allows requests to be made for evil.com. since it sees that as being the originating domain, it passes them off to IE which sees evil.com. as a DIFFERENT domain and performs a DNS lookup. By this time the attacker has changed the IP address for evil.com, either manually or automatically. IE performs the HTTP request for evil.com., passes that result back to Flash and it has now been pwned.


There is one obvious issue with what I've described above: How do you get the information you've obtained through your nefarious means back to your server if you're the attacker? Now that the domain evil.com is rebound in Flash it doesn't seem like an easy proposition.

That's where crossdomain.xml and the Socket class come in. If you have a crossdomain.xml file on your server and another domain name associated with that server, like 0mgurs0pwn3d.com, you can connect back and send the information you've stolen through binary (or probabably even XML) sockets.

Like I mentioned before, Nate and I used this exact flaw in our Picasa exploitation. I couldn't get traditional Anti-DNS Pinning working reliably so came up with this solution.