The recent advent of flashback malware that includes exploit code for CVE-2012-0507 has been creating waves and quickly adopted by various other attackers as Websense® Security Labs™ has shown. This blog post detail some of the aspects of CVE-2012-0507 and how this exploit has been used in the wild.

The Java code first starts with the excerpt below:

The string "sobj" contains a stream of characters that trigger the vulnerability and force Java to render something which it usually wouldn't be allowed to. The string "8BCA ..." is obfuscated with an XOR key of 0x27 shown below:

After this string is de-obfuscated, it looks something like the image below:

We compared the exploit code used in the flashback campaign (above) with another instance in the wild that surfaced recently. Apparently, the attacker is using the exploit code provided by the metasploit framework.

The only difference between the flashback exploit code and the one used by metasploit is the bytecode array, where one is a signed byte array while the other is unsigned, as revealed below:

In our flashback sample, the string that triggers the vulnerability is "XOR-ed" with 0x27, while the string seen in the metasploit sample uses a signed byte array.

Lastly, the payload used by the flashback malware is a dropped Mach-O binary executable, while the metasploit exploit opens a listening TCP port shell pipe depending on what operating system the victim is on (This highlights the beauty of a design flaw as opposed to a vulnerability that corrupts memory). The code excerpt is shown below:

 Websense security solutions protect users from these kinds of exploits.

When Duqu, which most believed to be written by the same group that wrote Stuxnet, was originally uncovered, the infection vector was still unknown; how did the machines get compromised in the first place? That changed when the Hungarian research lab, CrySys, announced that it had found the dropper which was a Word file that used a new 0-day vulnerability in how Windows parses TrueType fonts. 

Microsoft has confirmed that there is indeed a vulnerability in TrueType Font parsing. An attacker could use this vulnerability to run arbitrary code in kernel mode. Vulnerabilities that allow the attacker to run code directly in kernel mode are very rare, and the attacker could, for example, create new user accounts with full access rights. More information is available from Microsoft in Security Advisory 2639658.

Microsoft has also released a Fix-It tool that will temporarily mitigate any attack using this vulnerability.

Websense, as an active member of the Microsoft MAPP program, has worked with Microsoft to develop protection for our customers. Our security solution will block as "Malicious Web Sites" any attempts to download a file containing an exploit that uses this vulnerability:

Block message when trying to download a file exploiting CVE-2011-3402

Websense will continue to work closely with Microsoft and the security community to monitor this prevalent  threat.

A few days ago, an exploit used for highly targeted attacks was published here: CVE-2010-2568 Lnk shortcut. As the blog post, and other posts, state, this is caused by Windows Control Panel's shortcut image display routine. The original blog post shows a stack trace of the exploit results, which also serves to explain the vulnerability.

The nature of the vulnerability is pretty clear. But out of curiosity we did some reverse engineering and here is what we have found. The bug itself is a design flaw as stated by many people and it's very straightforward to locate the point where it happens. The vulnerable file is shell32.dll and the vulnerable routines are Control Panel-related. We loaded the binary on a disassembler and found that the Control Panel file-related routines start with a “CPL_” prefix.

Drawing 1 shows the relations between CPL initialization routines and data flow. The red “LoadLibraryW” API is the vulnerable one.

Drawing 1: The flow of the related routines and data

The icon extraction routine calls “CPL_FindCPLInfo” to find the icon information of the target file. The “CPL_FindCPLInfo” routine is basically a wrapper around all CPL-related routines. The loading and initialization of the CPL module is performed before getting any information out of it. One of the initialization routines, “_LoadCPLModule”, calls the “LoadLibraryW” API to load the target CPL dll for future use. The module handle acquired from this call is used later in the “_InitializeControl” routine with the “LoadImage” API. There are ways to acquire an icon handle from a dll without loading it, but in this case the programmer chose to load the target dll for some reason, which opens the vulnerability.

It looks like the security side-effects of one module are not evaluated fully before it's combined with other modules.

We recommend following this Microsoft security advisory to disable icon display or the WebClient service until a patch for this flaw is released.