Home >
In the series of articles I will be posting on InsideRIA, you will gain knowledge about security in regards to Flash and Flex applications. In each article I will be covering specific security vulnerabilities, showing examples of how an attacker can abuse Flash/Flex applications, and pointing out ways to help prevent these attacks. The purpose of these articles is to increase awareness so you will take security into consideration when building your applications.
Compile the application, and then we can import the swf file and decompile the swf back into a Flex 3 project. See figure 1.
Figure 1: decompile Flex 3 project
After the project is restored, you can then import the project back into Flash builder and change the project.
My example is harmless since I only modified a label; however, as you can imagine, hackers can do much more than just modifying a label once they have access to the application complete code. For instance, they can steal the source code, re-publish the application on a fake URL, send emails out to users, and take credit card information or other important information. This type of attack is known as phishing attack.
Phishing attack is when a hacker tries to obtain user’s sensitive information by impersonating as a trustworthy entity.
As a second example I went to one of these Flash template site and used a Web Proxy to extract the swf URL and download the swf file to my desktop, see figure 2:
Figure 2: extract swf URL and download swf file to desktop
I then imported the file into a decompiler and exported it as an FLA, see figure 3:
Figure 3: decompiler and exported it as an FLA
Lastly, I was able to open the document in Flash Professional and modify and compile the document, see figure 4.
Figure 4: Flash Professional and modify and compile the document
The accessed application will hold a label field and an instance of a class that will enable the user to login. Create a Flex application in FlashBuilder 4 Beta and call it: AccessedApplication.
Here is the class that allows the user to signup to the application. This is just an experiment in which I did not implement a service call; however, you can get the idea.
Copy the swf from the accessed application (main.swf), and place it in the “bin-debug” folder of the accessing application. Run the accessing application, see Figure 5.
Figure 5: accessing application shown in the browser
At this point we are loading the accessed application from the same domain; however, if you place the accessed application and the accessing application on two separate domains and place a domain policy that allows accessing the domain from any domain, as in this example below, it will work.
Figure 6: Variables window showing loaded content object
Additionally, using decompiling software, the attacker can decompile the accessed application and browse through the classes (as we showed previously), see figure below:
Figure 7: decompiling the accessed application
In the example below the accessed application will hold a service class, see below:
The accessing application can load the SWF and access the service class to make an illegal call, and then it can retrieve the data. For instance, let’s assume that a site allows a certain authorized domain to make service calls but the API is not public. If the authorized domain holds a SWF that can be accessed, one can use that SWF to gain access to the API and make un-authorized service calls. See accessing application below:
You can decrease the chances of an attack by setting a restricted cross-domain policy that limits the domains that can access the application and load all the content from one remote source instead of loading content from many remote sources all using the same security domain policy. For more information see: http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
Additionally, you can use code obfuscation software such as secureSWF from Kindisoft (www.kindisoft.com/), which helps you to protect your ActionScript from Flash decompilers. By protecting your SWF and preventing attackers from decompiling your application, it will be much harder for attackers to do some of the cross-scripting I have shown you in this article.
Look for the next article in the series where I will be covering Cross-site scripting (XSS) vulnerability.
Follow Elad on Twitter: http://twitter.com/EladElrom
Part 1: Cross-domain Scripting threat
In this article I will be covering Cross-domain scripting vulnerability, one of the highest threats on Flash/Flex applications. An application may be hosted on a server where the Cross-domain policy allows loading a remote SWF and then have unintended access to the loader's domain and data. If the loading SWF loads the remote SWF into its security domain, then the loaded SWF could gain access to the parent SWF's data, modify properties, and even send that information back to an attacker. Additionally attackers can download a SWF, decompile and change it, and host it back somewhere else pretending it is the original application.Decompiling and modifying swf file
The concept of downloading Flash applications, decompiling, modifying them, and then re-compiling them is one of the oldest & most used cross-scripting techniques out there. Hackers’ use programs such as Sothink SWF decompiler software which allows them to modify the swf. I think that not many people are aware of the fact that these decompilers are now capable of decompiling Flex 3 projects in addition to Flash applications. Let’s take a look at this simple example. Create a simple Flex 3 application:
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
layout="absolute" minWidth="1024" minHeight="768">
<mx:Label x="23" y="31" text="Hello World"/>
</mx:Application>
Figure 1: decompile Flex 3 projectAfter the project is restored, you can then import the project back into Flash builder and change the project.
<?xml version="1.0" encoding="UTF-8"?>
<mx:Application layout="absolute" xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Script><![CDATA[
import mx.events.*;
import mx.controls.*;
import mx.core.*;
import mx.styles.*;
]]></mx:Script>
<mx:Label text="Hello World" x="23" y="31"/>
</mx:Application>
Phishing attack is when a hacker tries to obtain user’s sensitive information by impersonating as a trustworthy entity.
As a second example I went to one of these Flash template site and used a Web Proxy to extract the swf URL and download the swf file to my desktop, see figure 2:
Figure 2: extract swf URL and download swf file to desktopI then imported the file into a decompiler and exported it as an FLA, see figure 3:
Figure 3: decompiler and exported it as an FLA
Lastly, I was able to open the document in Flash Professional and modify and compile the document, see figure 4.
Figure 4: Flash Professional and modify and compile the documentLoading the Flash app SWF file into another project.
Another known attack is loading a swf file belonging to a Flex project and then having the accessing application make changes to the access application. In the example below the accessing application gains access to an application, and I was then able to change the text property on a label and even use a login service method. Create a new project. Call it CrossScriptingFlex, and paste the following code:
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768"
initialize="initializeHandler()">
<fx:Script>
<![CDATA[
import mx.controls.Alert;
import mx.core.IFlexModuleFactory;
import mx.events.FlexEvent;
// define variables
private var loader:Loader;
private var content:*;
// load swf
private function initializeHandler():void
{
loader = new Loader();
loader.contentLoaderInfo.addEventListener(SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loadContent_onComplete);
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
loader.load(new URLRequest("main.swf"));
component.addChild(loader);
}
// Event Handler
private function loadContent_onComplete(event:Event):void
{
content = event.target.content;
var onContentApplicationComplete:Function = function(event:Event):void
{
// content loaded successfully
}
content.addEventListener(FlexEvent.APPLICATION_COMPLETE, onContentApplicationComplete);
}
private function ioErrorHandler(event:IOErrorEvent):void
{
loader.contentLoaderInfo.removeEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
Alert.show(event.text);
}
private function securityErrorHandler(event:SecurityErrorEvent):void
{
loader.contentLoaderInfo.removeEventListener(SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);
Alert.show(event.text);
}
// methods to access loaded swf
private function changeTextOnSWF(str:String):void
{
this.content.document.label.text = str;
}
private function login():void
{
this.content.document.signupUtil.signup();
}
]]>
</fx:Script>
<mx:UIComponent id="component" width="400" height="400" x="0" y="100" />
<s:Button label="Change text on loaded SWF"
click="changeTextOnSWF('Hello again!')" x="84" y="0"/>
<s:Button label="Login"
click="login()" />
</s:Application>
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo"
minWidth="1024" minHeight="768">
<fx:Script>
<![CDATA[
import utils.CallSignupService;
public var signupUtil:CallSignupService = new CallSignupService();
]]>
</fx:Script>
<s:Label id="label" text="Hello!" x="8" y="9"/>
</s:Application>
package utils
{
import mx.controls.Alert;
public class CallSignupService
{
public function CallSignupService()
{
}
public function signup():void
{
// method to signup to using a service
Alert.show("User login!");
}
}
}
Figure 5: accessing application shown in the browser
At this point we are loading the accessed application from the same domain; however, if you place the accessed application and the accessing application on two separate domains and place a domain policy that allows accessing the domain from any domain, as in this example below, it will work.
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*"/>
</cross-domain-policy>
Attacker figure out application source code
In this example we have access to the source code; however, in case the attacker does not have access to the source code, they can find out the source code in two ways. Once the content is loaded we can actually place a break point and see all the methods we have access to, see figure below. See Figure 6.
Figure 6: Variables window showing loaded content objectAdditionally, using decompiling software, the attacker can decompile the accessed application and browse through the classes (as we showed previously), see figure below:
Figure 7: decompiling the accessed applicationAccessing other domain through the accessed application
Similarly to the application I showed you previously, an attacker could load a SWF from a domain that has access to other domain and than make un-authorized service calls. For instance, let’s say that DomainA allow access to DomainB, as you can see from the Cross Domain policy below:
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="domainB" secure="false" />
</cross-domain-policy>
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo"
minWidth="1024" minHeight="768">
<fx:Script>
<![CDATA[
import mx.controls.Alert;
import mx.rpc.events.FaultEvent;
import mx.rpc.events.ResultEvent;
protected function service_faultHandler(event:FaultEvent):void
{
Alert.show("fault error: "+event.fault.faultDetail);
}
protected function service_resultHandler(event:ResultEvent):void
{
Alert.show(event.result.toString());
}
]]>
</fx:Script>
<fx:Declarations>
<s:HTTPService id="service"
url="domainB"
resultFormat="text"
fault="service_faultHandler(event)"
result="service_resultHandler(event)" />
</fx:Declarations>
</s:Application>
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo"
minWidth="1024" minHeight="768"
initialize="initializeHandler()">
<fx:Script>
<![CDATA[
import mx.controls.Alert;
import mx.events.FlexEvent;
import mx.rpc.events.FaultEvent;
import mx.rpc.events.ResultEvent;
// define variables
private var loader:Loader;
private var content:*;
// load swf
private function initializeHandler():void
{
loader = new Loader();
loader.contentLoaderInfo.addEventListener(SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loadContent_onComplete);
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
loader.load(new URLRequest("main.swf"));
component.addChild(loader);
}
// Event Handler
private function loadContent_onComplete(event:Event):void
{
content = event.target.content;
var onContentApplicationComplete:Function = function(event:Event):void
{
// content loaded successfully
}
content.addEventListener(FlexEvent.APPLICATION_COMPLETE, onContentApplicationComplete);
}
private function ioErrorHandler(event:IOErrorEvent):void
{
loader.contentLoaderInfo.removeEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
Alert.show(event.text);
}
private function securityErrorHandler(event:SecurityErrorEvent):void
{
loader.contentLoaderInfo.removeEventListener(SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);
Alert.show(event.text);
}
// methods to access loaded swf
private function callServiceCall():void
{
this.content.document.service.send();
}
]]>
</fx:Script>
<mx:UIComponent id="component" width="400" height="400" x="0" y="100" />
<s:Button label="Call accessed application service"
click="callServiceCall()" x="84" y="0"/>
</s:Application>
How to avoid cross-scripting attacks
Cross-domain attacks are one of the highest threats that can expose a SWF to other threats such as spoofing, script injection into the browser, malicious data injection, DNS rebinding and insufficient authorization restrictions.You can decrease the chances of an attack by setting a restricted cross-domain policy that limits the domains that can access the application and load all the content from one remote source instead of loading content from many remote sources all using the same security domain policy. For more information see: http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
Additionally, you can use code obfuscation software such as secureSWF from Kindisoft (www.kindisoft.com/), which helps you to protect your ActionScript from Flash decompilers. By protecting your SWF and preventing attackers from decompiling your application, it will be much harder for attackers to do some of the cross-scripting I have shown you in this article.
Look for the next article in the series where I will be covering Cross-site scripting (XSS) vulnerability.
Follow Elad on Twitter: http://twitter.com/EladElrom
Tag Cloud
Podcasts & Screencasts
@InsideRIA on Twitter
Follow InsideRIA on Twitter
Facebook Application Development
I was planning on releasing this exact same security threats (plus more) on my blog but I tought that asking Mike Chambers (Principal Product Manager for developer relations for the Flash Platform at Adobe) first would be a good idea to prevent a "wave" of flash site hacking in the near future. So I did, and he sent that threat to the dev team. I was waiting for his feedback before making this public.
But there is many things you dont say and that make this threat much more bigger than you think! And there is no solution for it yet!
Follow the post on jpauclair.wordpress.com soon!
Hi,
what you describe in the decompiling section ("steal the source code, re-publish the application on a fake URL, send emails out to users, and take credit card information") is called a Phishing attack.
Maybe it should also be said that hacking a client swf can be used for cheating in games (modifying speed, going through walls etc.) and that it is vital to always validate important actions on the server.
As for the other cross-domain points: I think the article lacks a bit depth here. When talking about about cross-domain issues and countermeasures, you should also mention how certain ActionScript settings (particularly the flash.system.Security class in AS3) affect the behaviour of swfs in terms of security. Your examples ("Loading the Flash app SWF file into another project") don't demonstrate how different settings of System.sandbox and System.allowDomain modify the behaviour...
Sorry for criticising your article. I think it's really good that you're trying to increase the awareness about security but since this is a very important and complex topic, I would suggest to give the readers more details - particularly about Flash Player's security sandbox, ActionScript security settings and the Security class, the Loader class and application/security domains, more details about crossdomain policy files etc.. - basically information that enables users to understand how to protect their content against attacks and how to apply various Flash Player security settings...
Security is indeed very complex and hard to cover subject. I realize that it's not possible to cover everything in few pages. Maybe there is a need for a book that covers Flash security.. Anyway I suggest reading Adobe's article about security and how to protect your applications, which will give you some more information about protecting applications:
http://livedocs.adobe.com/flex/3/html/security2_01.html
perhaps Adobe should consider licensing Simplified Logic's NitroLM-Lite. Unfortunately the current licensing model is out of reach for most devs at $500 per application per year.
mrsecure:
There's a some great discussion on stackoverflow at the moment detailing some approaches that can be employed to make hacking a flash game harder, check it out
http://stackoverflow.com/questions/73947/what-is-the-best-way-to-stop-people-hacking-the-php-based-highscore-table-of-a-f
Great article... You did what you said you would do which is raise awareness. There is no way you can cover a topic as deep and complex as security in one article. Even discussing topics like flash.system.Security, System.sandbox, and System.allowDomain would still fall short of building a great understanding of security on flex/flash. I enjoyed it... So with my new awareness, I know one thing for sure. I will definitely make it more difficult for others to masquerade my SWFs in the future.
In this post:
http://jpauclair.wordpress.com/2009/12/11/flash-player-security-advanced-walkthrough/
I explained some very severe security threat that match well with what you explained. I also linked to your post for more info.
My suggestion is to clearly label on which domain the crossdomain.xml file resides. For people who don't have a background in this, it's quit confusing. In the last example, "Accessing other domain through the accessed application", it contains errors.
The attack scenario is as follows,
1. Accessing application (hosted on the DomainA)
2. Accessed application (hosted on the DomainB)
3. the crossdomain.xml hosted on the DomainB allows-access-FROM (NOT TO) domainA
4. Attacker finds a swf on DomainA, which loads the accessed swf on DomainB and then making an illegal call
Thanks for the information. I see that there are Flash/Flex app security threats. But, you should have told us more about how to avoid it. Using code obfuscation software or policy files are answers, but need to see them explained more rather than telling just what the solutions are. I think, the policy file articles on the internet are too boring to read, therefore I wish to see a video tutorial explaining it with all the possible scenerious.
I actually hate having to install the application. My friend tells me that doing Arc Flash Analysis before you start everything else can help. Is it true?
If only it is easy to manage the security issues, businesses would have better assurance to go online. I have also been trying to use only the most secure system such as Voice Over IP Phone Service to ensure there is no considerable drawbacks and leakages.
I am not even familiar with flash. Yes I need it when developing the free b2b community we have, but there are other team member who understands better. I hope I have more time to learn about it.
Hello, I am Harry from Personal Development Reviews. It just seems easy because you post the step by step instructions here. The case would be different if we explore ourselves, lol.. But good to read this. I can try it myself later.
I think good hosting and web development is really influential to prevent from such security issues. I use only among the best web hosting services for all my sites. There isno considerable problem so far.
google
Thank you. I am interested in anything that is related to SEO and software management. We will have to try more to be able to provide solid statement.
I don't think the security issues ae a big deal. I mainly in Internet Marketing Services and it doesn't feel like affecting significantly.
It is important that we can make sure there is good protection on our private data. I meet people a lot and I have been learning hard to keep things confidential..
I don't see how any of this is any less secure than your standard AJAX/HTML web page. In fact it requires extra steps, knowledge and tools to do, which makes it seem like the end of the world: "oh noes it's decompiled!", but we're forgetting that JavaScript comes over to the browser completely open to ANY user that knows how to view source and open .js files in notepad!
The moral of the story is: it's easy to fake the visual aspects of websites, whether they're simple HTML, AJAX/DHTML, Flash/Flex, Java Clients, or standalone applications. Doing so with Flash comes off as a more impressive feat because these apps tend to be so fancy, but the problem is fundamentally the same. So if you're implementing a "web application" of any kind make sure you implement security properly on the server side, and don't (for any technology, not just Flash) trust security built into your client side code. This rule has existed almost since the dawn of IT networking security and is nothing to be alarmist about for Flash or any other technology.
It is the best swf obfuscator and the most advanced but I built decryptor for AS3 secured files by Secure SWF. I will also add decryptor for AS2 Secure swf files.
Please visit http://www.swf-reader.com
SWF can’t be secured 100% it is open format and always it is possible to hack every protections.
Seen this area lately? It's been privacy protected in line with US laws and printplace indefinitely. Think it will work?
These are really highly rated applications. I think that not many people are aware of the fact that these decompilers are now capable of decompiling Flex 3 projects in addition to Flash applications.
Marshall,
TC G System
I didn't know there were so many secrity implications to flash. Fantastic article with step by step examples. J from Banner Stands
This is increasingly challenging for the digital age! I do believe, like any criminal activity that this will continue to be a struggle for users around the world.
If it is not Adobe Flesh and Flex,, HTML, AJAX, DHTML, Java , or standalone applications. there will be something else these terrible people have managed to build to infiltrate into other people systems. The at risk groups are personal users who do not have the exposure or the systems intelligence that large businesses and corporations install.
It is a sad indication of people who, if they focused on positive contributions, would benefit personally and professionally. Yet this is a historic situation that human behavior will choose the evil route to gain power and prominence. Science will continue to develop sophisticate software to increase safety and these hackers invade. The cycle will go on round and round. I guess my money could go under the bed!
UK Website Hosting, Research Scientists, large corporations, educators and to a lesser degree the home user and small business must combine to manage safe environments. The solutions are to continue to monitor and produce improved safety applications that are free or at least affordable for all users, to ward of these criminals. Further more, without sounding violent, these people should be made accountable when they are caught. There is no excuse, this is the current phenomenon of crimes across the globe. It you do the crime you should do the time!
Please correct me if Im wrong, but if you're running stolen code from within the Flash IDE, whatever is in crossdomain.xml doesn't even matter.
To add another layer of security, I use server-side sessions for scripts accessing server-side functions. Here's how it works: You get the session id from the server when your app loads, save it as a global var, and then pass that as an extra param every time you send sensitive information back to the server. So unless the session id was created on the server itself, the script fails. Always remember to clear sessions or generate a new session id for every login and logout (if thats something your app requires).
This has seemed to work for me so far, but if you think there's a security issue in doing this, please do let me know so I can fix some of my apps too.
Also, I learnt flash by decompiling swfs written by others. I think decompilers rock. People just need to use it for learning rather than manipulation. Too bad!
There seems to be some confusion about flash being associated with
Arc Flash and the need for it.
My experience with Sothink wasn't very successful, it had worked very unsteady on my Mac 10.6 and crashed a couple of times. Yet Mac version of Flash Decompiler Trillix impressed me with both handy interface and great result - FLA was restored, clear and shiny :)
I struggled a bit using it I have to say. The issues definitely can cause mobile problems, flash has always done this to my sites.
Hi Elad Elrom,
Thanks for sharing this useful information,
this is really very effective technique for Flash applications.......
I found that when I wanted more information the links provided me with what I was looking for.
Wondering if I could get more tutorial modules. Do you have clues about how Flash content can be modified to be more SEO friendly? This is always the problems for sites..
Richard
I think protection is a big issue. Just check out Arc Flash Analysis.
Interesting article.
This has opened my eyes to flash, I wasn't aware of the threats.
phone so this has proved very worthwhile.
Very impressive article. As a programmer i'll take these tips in use for my oyun projects.
What a crazy world we live in. Back when I was a kid the only think you worried about was that a criminal would jump out from an alley, pull a gun from his IWB holster and demand your money. Now we have "security threats" associated with Flash. How the world turns.
Good thing Adobe Flash now applicable into iphone and ipad apps.
iPad accessories
I've been using SWF Decompiler for a long time, which is really stable and powerful in my opinion.
Excellent article. I'm trying SWF Decompiler now. Thank you.
Do you think this will get resolved? Flash is a diamond of a software prog, shame to have so many issues, it could be a gem indeed, hope it get sorted soon.
Thanks a lot for this article. Really helpful.