Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2007-06-07 InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

A Java exploit

Published: 2007-06-07
Last Updated: 2007-06-07 22:50:48 UTC
by Bojan Zdrnja (Version: 2)
0 comment(s)
Peter G. reported a malicious Java class that he downloaded yesterday. Now, this certainly looks interesting since this is an exploit for Java VM (not to be confused with JavaScript). This means that, in order to run the exploit, a vulnerable Java VM has to be installed on the machine.

The exploit comes in a small class file:

$ file java.class
java.class: compiled Java class data, version 46.0
$ md5sum java.class
0b67d360d5b1839820c0a39810b40498 java.class

As you probably know, Java class files contain bytecode, which is a machine language for the Java virtual machine. Luckily, bytecode has *a lot* of extra information which makes decompilation much easier (and viable, when comparing to x86 machine code, for example).

After analyzing the exploit, I found out that it’s using an old vulnerability (CVE-2007-0243) that has been patched since January. Mark also wrote about this vulnerability here. According to the CVE article, Sun JRE 5.0 Update 9 or earlier, SDK and JRE 1.4.2_12 or earlier and SDK and JRE 1.3.1_18 or earlier are all vulnerable. The vulnerability allows an applet to gain privileges through a GIF image.

This is exactly what our exploit does – it creates a malicious image that is then displayed on the victims machine. This causes a memory corruption which leads to code execution.

The sample is completely based on the publicly available PoC code that was posted to various security related mailing lists. The shellcode was, of course, changed – the current shellcode included a downloader which, of course, dropped the second stage (a password stealer).

AV detection

Now we come to an interesting point – the AV detection. I first submitted the Java class through to VirusTotal – the results were shocking – only 1 (!!!) AV program detected the Java class as malicious:
VT results (Java class)

The second stage binary was no picnic either – only a handful of AV programs detected it correctly:
VT results (2nd stage binary)
As this is a more or less standard password stealer I expect AV vendors to add detection shortly.


At this point in time I would say that I’m more worried about inability to detect the Java class properly. If you remember, back in March I wrote a diary about RTF documents carrying embedded executables (this attack scheme is still used in BBB/IRS phishing e-mails we wrote about several times). It is clear that AV programs are struggling with all these new formats – another sign that you should always rely on multiple layers of security.
Java upgrades could also be made easier: multiple available versions often confuse users (which version should I download) and the fact that old versions are left on the machine after the upgrade certainly do not help in resolving the problem.



How many people are vulnerable to this Java exploit? Johannes did some statistics on ISC visitors that run Java. Of course, in order to collect these statistics you need JavaScript enabled in your browsers as well (so those of you who do not have JavaScript enabled are not counted, even if you have Java). It turned out that 86% of our visitors have Java installed.

Regarding patching, it’s generally OK but I would expect better results from security experts – about 12% are running vulnerable versions of Java VM. As we’ve confirmed that exploits such as the one described in this diary are in the wild, take a minute or two and confirm that you’re running the latest version.

Regarding the AV vendors - it looks like they're starting to pick this up (so they do read our diaries, do they? :). The test I did couple of minutes ago showed that the exploit is now detected correctly by 5 vendors on VirustTotal. Far away from perfect but improving.
0 comment(s)

Analyzing (malicious) SWF file actions

Published: 2007-06-07
Last Updated: 2007-06-07 22:10:34 UTC
by Bojan Zdrnja (Version: 2)
0 comment(s)
Couple of days ago, Steve P. reported a web page that, when viewed, somehow redirected his browser to another, phishing web site. I initially thought that the original web page just used simple redirection (with or without help from JavaScript), but after analyzing the original site I found out that phishers used something different.
(I’ll use this opportunity to ask developers of legitimate web sites to try to make their code a bit more readable – stripping all spaces and tabs from your code and using cryptic names for variables doesn’t help analysts at all)
So, the web site that had the redirection had the following HTML code embedded:

<P><embed src=""
height="4" width="3"></P>

As you can see above, the web site (which is still live, but the target phishing site has been removed) is actually pulling an SWF (Macromedia Adobe Flash) file. In other words, the redirection was caused by the malicious SWF file, which also means that this will work only if you have Flash installed. While this was obvious, I got interested into how to analyze actions embedded in SWF files so I found two nice (and free!) utilities that you might want to bookmark, in case you need to do the same thing in the future.


The first utility is actually a collection called SWFTools ( This utility is for all you guys that prefer to analyze malware under Linux. The collection consists of various command line utilities for various manipulations of SWF files. The most useful one for our analysis is called swfdump. This small utility can disassemble action tags in SWF files and that’s exactly what we need in this case:

$ swfdump -a cocino.swf
[HEADER] File version: 6
[HEADER] File is zlib compressed. Ratio: 86%
[HEADER] File size: 296 (Depacked)
[HEADER] Frame rate: 12.000000
[HEADER] Frame count: 1
[HEADER] Movie width: 10.00
[HEADER] Movie height: 10.00
[009] 3 SETBACKGROUNDCOLOR (ff/ff/ff)
[00c] 263 DOACTION
( 259 bytes) action: GetUrl URL:"" Label:""
( 0 bytes) action: End
[001] 0 SHOWFRAME 1 (00:00:00,000)
[000] 0 END

And the action taken is clearly visible at0x00c – the SWF file uses the GetUrl() action and redirects the browser to the target site.


The second utility that you can use to analyze this file is JSwiff ( JSwiff is a Java framework for SWF file creation and manipulation. As it’s completely written in Java, you can start JSwiff on any platform.
JSwiff is a very simple GUI based utility that will immediately show all SWF headers and tags, as you can see below:




Couple of updates with useful stuff we've received from our readers (thanks everyone!):

- There is a nice command line utility that can be used for quick analysis of actions in SWF files. The utility is called Flare and is available at It has an accompanying utility called Flasm ( which you can use to even edit actions in SWF files.

- There is a cool addon for Mozilla Firefox called Flashblock. It basically prevents all Flash content on a web page from loading and lets you easily enable just the Flash content you want to see. The addon is available at
0 comment(s)

DDoS on anti-spam groups

Published: 2007-06-07
Last Updated: 2007-06-07 21:34:57 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)
It looks like a pretty big DDoS attack is being carried out against several well known anti-spam groups, including Spamhaus, SURBL and URIBL. The Rules Emporium site that hosts additional (and very useful) rules for SpamAssassin is also not available at this moment – I don’t know if they are under a DDoS attack as well.

The attacks seem to be similar to those carried out against BlueSecurity last year, with the Storm malware. Storm is a botnet that can do basically anything and, starting from DDoS attacks to sending spam.

It looks like some anti-spam groups managed to get the attack(s) under control, let’s hope the things will stay that way.

On the other side – this looks like the anti-spam tools are doing their job because spammers seem to be desperate when they launch DDoS attacks (otherwise they would just keep sending spam, instead of using their resources this way).
0 comment(s)
Diary Archives