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

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

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

SHARE:
Nathan McFeters and Rob CarterAdobe 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 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.
Ok, cool.  So as Rob mentions, this is an attack against the URLLoader class of Flash.  Flash, quite reasonably, says that evil.com and evil.com. 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 evil.com and evil.com. as requiring two separate domain name lookups, we can rebind evil.com 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 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 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.

Topics: Networking, Browser, Enterprise Software, Microsoft, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

1 comment
Log in or register to join the discussion
  • adobe was aware of pwn2own flaw since months

    adobe was aware of pwn2own flaw since months
    qmlscycrajg