Adobe patches 7 issues, including Pwn2Own contest flaw and DNS rebinding issues

Adobe published an advisory covering issues, including a fix for the Pwn2Own flaw that we previously discussed here.  Adobe's details are published here.

Nathan McFeters and Rob Carter
Adobe published an advisory covering issues, including a fix for the Pwn2Own flaw that we previously discussed hereAdobe's details are published here.  One of the issues that was patched was discovered by myself and fellow researcher (and co-worker at Ernst & Young's Advanced Security Center) Rob Carter, see the picture to the right of Rob and I rollin' with large stacks of Euros (not really, it was actually like 10 Euros, aka $10,000.00 with the way the dollar is these days) in Amsterdam during Black Hat Europe.  The flaw we discovered is a DNS Rebinding flaw that's a bit unique.  It takes advantage of some DNS canonicalization issues, and I really feel like it may be useful in other attack vectors as well.  My good friend Rob has already posted the details on his "Farfromr00tin" blog, and the analysis is quite good, so I will paraphrase this here.  As Rob says:
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.

IE: 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.

Flash: 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.
Ok, cool.  So as Rob mentions, this is an attack against the URLLoader class of Flash.  Flash, quite reasonably, says that and are one in the same with regards to domain name.  This is correct, actually, when you think about it, that's how DNS records are setup with that trailing (.).  The kicker is that when URLLoader passes through the browser (which is it's nature), it passes control of grabbing the request and the response to the browser.  Now, because IE and other browsers see and as requiring two separate domain name lookups, we can rebind to the new IP address that we control.  Onto the attack:

Attack: 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 probably 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.
So as Rob mentioned, we used this attack combined with some of the URI Use and Abuse research we've been a part of to steal images from a user of Picasa through a simple Cross-Site Scripting exposure on any site.  Sounds strange?  Believe it.  I'll discuss this piece in more detail in a separate post, but the good news is, Adobe has resolved the issue.  In fact, I'm pretty impressed by how quickly Adobe turned this issue around.  Rob and I worked very closely with Peleus Uhley of Adobe to explain the issue and he and the Adobe security team have been a pleasure to work with.  It's really impressive that they were able to put out the Pwn2Own fix so quickly as well.


You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.
See All
See All