Shockwave exploits
The initial infection was common iframe injection on a web page. The iframe page loaded tiny shockwave file, which was only 158 bytes long!
This file uses internal ActionScript global variable ("$version") to get the version of user's OS and plugin for handling Shockwave files.
The $version variable evaluates to something like "WIN 9,0,12,0", which is short platform name, version and revision numbers of Adobe Flash Player plugin. After that 4561.SWF tries to download and run another .SWF basing on this string. In the case above it tried to download "WIN 9,0,12,0i.swf" file. The server replied with famous ERROR 404: “File Not Found”. But that was done for purpose. If the 4561.swf file was tested on an automated sandbox a researcher may have not notice the fact that unavailability of the second .SWF file was not due to the absence of malicious code on the server, but due to the different Adobe Flash Player plugin that was used in the sandbox.
I have checked all the possible versions and found 6 different .SWF exploits.
Here is the list of files that I found:
WIN 9,0,115,0i.swf
WIN 9,0,16,0i.swf
WIN 9,0,28,0i.swf
WIN 9,0,45,0i.swf
WIN 9,0,47,0i.swf
WIN 9,0,64,0i.swf
The files were already detected by our engine as Exploit.SWF.Downloader.c but they were new variations and were not in malware collection. The first sample of Exploit.SWF.Downloader was detected on 2008-05-27.
This exploit uses a vulnerability of Adobe Flash Player, built on incorrect handling of DefineSceneAndFrameLabelData tag with negative value of SceneCount parameter. The shellcode can be discovered in SWF file as an embedded image file with wrong image size.
So, to draw the line, I would like to repeat that this technique allows to carefully download specific exploits for specific version of the vulnerable Adobe Flash Player plugin and at the same time allows to hide the actual malicious code from curious researchers.
Post a Comment