Backdooring Flash Objects (the receipt)

Tue, 05 Sep 2006 22:03:52 GMT
by pdp

Death Flash

Just a day ago I released a quite narrative article called Backdooring Flash Objects (the walkthrough). Although, I received some quite good responds on the style of writing, I decided to write more narrowed and specific version on how Flash object infection works. The following post outlines one of the many ways and expands further on some of the core concepts.

The truth is that Flash files can be maliciously infected with bad code which in tern can cause havoc in your network. The concept is not new. In fact since the beginning of Macromedia Flash IDE, the developers have been given the flexibility to include or adjust external SWF files and such employ more robust and highly componentized framework. However, with the raise of popularity of Flash based applications, it was discovered that Flash objects can be infected and used as transport mechanism of various types of malware the same way application level executables are.

Infecting Flash objects is straight forward when performed from the Flash IDE. It is a matter of embedding the target file into a newly created Flash project and assigning actions to keyframes that proceed the point where the external file is called. Of course this is the most basic scenario. Other infection techniques are also possible but they are not going to be discussed here because the subject is quite broad. To narrow it down, I am going to talk about the basic toolkit required for infecting Flash objects.

For the purpose of this exercise I found several free command line tools that can be used for constructing Flash malware and also help analyzing already infected objects. The tools are as follows:

  • Mtasc - great tool for compiling ActionScript
  • Flare - excellent tiny tool for decompiling ActionScript from SWF files
  • Swfmill - SWF to XML and XML to SWF converter
  • Swftools - various useful utilities

Mtasc, Swtools and partially Swfmill are used for constructing Flash based backdoors while Flare and again Swfmill is pretty much used for analyzing them. Malware analysis will be covered in future articles, so lets get back to how Flash objection infection works.

There are several important things to understand first. Since SWF files are restricted and by default sandboxed by the Flash player, not that many interesting or dangerous functionalities can be used. Mainly, the infecter is restricted to JavaScript code or Flash ActionScript code. Most of the time it will be combination of both of them. However, JavaScript and ActionScript are highly suitable for performing web based attacks.

The first stage in my methodology is to construct body/framework for the backdoor. This can be something as simple as the following:

class Backdoor {
  function Backdoor() {
  }

  static function main(mc) {
    getURL("javascript:alert('hello from backdoor')");
  }
}

As you can see, the code above outlines a Backdoor class which contain one static main method and of course the class constructor. In this scenario the class is actually not need, however, since we are going to compile it into SWF with Mtasc, the style and syntax is kind of enforced.

To compile the backdoor into SWF the following command needs to be executed:

c:\Mtasc\mtasc.exe -swf backdoor.swf -main -header 500:365:24 backdoor.as

There are several important flags that needs to be discussed a bit here. The first one is the -main option. Basically this tells Mtasc that a static main method is expected. The second one is the -header option, which takes care of the produced SWF movie dimensions and characteristics. The example above produces 24 frames per second 500px by 365px movie. This dimensions can be extracted from the SWF file that will be backdoored with either Swfmill or Swftools utilities.

The Swftools packages comes quite handy in many ways. In fact the actual injection of malicious content is performed with swfcombine tool which is part of Swftools and here is the example:

c:\Swftools\swfcombine.exe -o The_Corruptibles_backdoored.swf -T backdoor.swf The_Corruptibles.swf

The command line above creates a new movie called The_Corruptibles_backdoored.swf by binding backdoor.swf with The_Corruptibles.swf. It is quite straight forward as you can see and this is all about it.

Obviously the infection mechanism provided above is very simple but it works quite well. Moreover it is highly robust. So, the question is to what extend attackers can use that to get into your corporate network. Given the fact that newly created JavaScript and ActionScript exploitation techniques are developed on daily basis and the fact that browsers are highly trusted, I must say that attackers have pretty good changes to cause serious damage. So, actions must be taken.

How can we protect ourselves from Flash based malware? It must be noted that Flash is probably the most popular media format on the web. This means that just turning off Flash is not that simple. Drastic action like this one could cause productivity loses. Unfortunately, there is no straightforward solution that can be easily implemented. I believe that prevention techniques will be discovered in the future and probably temporary signature based solutions will appear quite soon. This means massive attacks can be prevented but that might not be the case when dealing with dedicated attackers.

Archived Comments

nrgnrg
Hello mate, i enjoyed vey much reading your recent posts, but there is something in these last 2 that i didn't really understood. Whats so important about injecting javascript into a flash? can't you do the same that you would with a simple html with javascript inside? I get the idea about infecting SWFs wich is preaty cool but i don't see what's so special about it. Am I missing something? Anyway keep posting mate :) -nrg
pdppdp
hi there, First of all, wrapping your malicious code inside flash files will bypass all XSS filtering systems, simply becouse they don't understand how to read SWF files not to mention that even if they know how to do that, it would be highly inefficient approach. The second thing is that attackers are able to infect popular video, audio and interactive material and spread it on the web. This approach can be quite easily defined as viral infection. The next time you visit youtube.com or video.google.com beware that what you see might not be what you get. Sneeky JavaScript code can scan your internal LAN, hack into your WIFI router and enable the admin interface on the Internet side so attackers have direct access to you, your personal details and your bank account numbers. Well,... more or less!
nrgnrg
"First of all, wrapping your malicious code inside flash files will bypass all XSS filtering systems (...)" Hadn't thought about that. It's clear for me now, thanks for the fast explanation. Actually after thinking a bit about it was a really dumb question. So how can websites like myspace protect them selfs from being hijacked by an 'infected' swf? (i'm not a user from my space but i think they allow the use of SWFs in users accounts). Time to read how you managed to do it with quicktime. PS: Stupid suggestion, can you get a favicon? I would like to have it on my bookmark.
pdppdp
There are no stupid questions. I don't think that there is simple way of protecting against media file malware. Of course the most obvious approach will be to disable or filter out embed an object tags. However, this will make MySpace pages highly unattractive because people won't be able to show their YouTube movies for example. Yeh, I might think about favicon. Why not?
dev>nulldev>null
um ... what about allowScriptAccess="never"?
pdppdp
Well, then my POC won't work. It is that simple. However, keep in mind that JavaScript access is not required. Flash objects can be backdoored with ActionScript quite successfully and the attacker is given the same level accessibility; sometimes even more.
AcidusAcidus
pdp, I love what you are doing so please keep up the good work. For far too long people have thought that JavaScript is a toy language and that XSS can only annoy and steal the occasional cookie. I applaud the work you have been doing. Acidus, ps: I'm going to be dropping some JavaScript malware 0day in a week of back to back conferences (Toorcon-Ajax World-Security Opus) that I thhink you will find interesting...
pdppdp
Definitely, I would like to see your malware. I won't be able to attend these conferences but I will be vary happy to get some of your slides. I am also working on some advance techniques that will go into AttackAPI and my blog quite soon.
Vladislav 'dgtlscrm' MyslaVladislav 'dgtlscrm' Mysla
Using javascript protocol is well known technique
pdppdp
I know. This article is just a POC on how easy it is to backdoor any given flash object.
shizkanishizkani
can you make this exploit download and execute a RAT server to someine who views the corrupted .swf file ..?? if so can someone please explain to me how i would make it possible.. thanks..
chownchown
How can you call it backdooring? You're simply embedding javascript in flash. Please explain your definition of 'backdoor'
pdppdp
shizkani, the short answer is "NO", unless you use something like the IE VML vulnerability. chown,
A type of Remote Control Software that enables a third party to covertly control system resources.wetstonetech
What do you think a backdoor is?
chownchown
Primitive javascript access - within the confines of the browsers security restrictions, can hardly be classified as "system resources". If it were, then you could say you have access to the "system resources" of me, and anyone else who visits this site. By your logic, the following is a VBScript backdoor in a batch file
@echo off
echo msgbox "foo" > bar.vbs
start bar.vbs
Frank WalshFrank Walsh
above you say allowscriptaccess="never" kills your POC but javascript isn't nessecary , you can do with with purse ActionScript...isn't there also a tag allowNetworking="internal" would cover this... just wondering if I'm missing something in your response..not trying to be a dick.
karcooskarcoos
nice blog, I love the "swftools" you recommended.