Wednesday, April 09, 2008

[ 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 and let's say your browser tries to go to the website. If can't be reached your system will start to look through your search domain by performing a DNS lookup for (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 (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 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 and differently.

You go to, DNS lookup is performed for, the browser pins the resulting IP to and life is good. Then you go to, IE sees as a totally DIFFERENT domain, performs a DNS lookup, pins that IP to 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.

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

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

Flash allows requests to be made for since it sees that as being the originating domain, it passes them off to IE which sees as a DIFFERENT domain and performs a DNS lookup. By this time the attacker has changed the IP address for, either manually or automatically. IE performs the HTTP request for, 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 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, 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.

Labels: , , , , , , ,


Post a Comment

Links to this post:

Create a Link

<< Home