Liberal Crossdomain.xml Exploit Example – Part 1

Liberal Crossdomain.xml Exploit Example – Part 1

Posted on July 26, 2014 by chs

So, I decided to whip up this PoC of a liberal crossdomain.xml policy and what you can do with it. It’s been on my mind recently and thought a tangible example would help solidify in mind some of the possibilities. First, the basics-

What is a crossdomain.xml file?

A crossdomain.xml file essentially lets a domain specify the domains from which flash applets are loaded that are allowed to access it. The domain(s) that the crossdomain.xml file specifies are the domain from which the applet is loaded, not the domain that references the flash file.

Why does this matter?

Keep in mind that when a flash applet makes a call to retrieve data from a domain, the browser includes any cookies for that domain with the call. So, if it’s a domain that you’re authenticated with, then the flash applet will have the same access to that domain as the user does when accessing the site.

A working example

There are 2 domains for this example- rubysecurity.info and injectionvector.com. These are both domains that I own and have used for this demo.

Try going to http://rubysecurity.info/login/info.php. You will get a message that looks like this-

You are not logged in. Please login

because you are not logged in. That page requires you to be authenticated to view it. (In this cause “authenticated” means a cookie is set with your username:password in it)

Then go to http://rubysecurity.info/login and input anything as the user name and anything as the password. In my example, I used “chs” for both. You will be redirected tohttp://rubysecurity.info/login/info.php with a message that looks like-

Thanks for logging in! Your credentials are: chs:chs. Do not share them with others. You must be authenticated to view this page.

Since you are authenticated, it lets you get to that page and shows you your username:password in this example. In a real world site it could be a page that shows you bank balances, sensitive data, etc.

Now, in another browser tab open http://injectionvector.com/flasher. It appears that nothing happens. But, in the background it connected tohttp://rubysecurity.info/login/info.php, got the response, and logged it.

You can see the results at http://injectionvector.com/flasher/readlog.php

Currently it looks like-

Thanks for logging in! Your credentials are: chs:chs. Do not share them with others. You must be authenticated to view this page.

So, the flash applet that I wrote on http://injectionvector.com/flasher connected tohttp://rubysecurity.info/login/info.php and pulled the content utilizing your existing session with rubysecurity.info.

Why did that happen?

The reason this happened was because rubysecurity.info had a liberal crossdomain.xml policy. In this example, it lets any flash applet connect. It looks like-

<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="*"/> </cross-domain-policy>

When a flash applet tries to connect to a domain, the flash container attempts to retrieve crossdomain.xml and applies the policy it contains. Since the above one allows access from any domain, the flash applet from injectionvector.com was allowed to connect, access the page, and log the results.

More to come…