CVE-2011-3402 and Cool Exploit Kit

I have been working with the Cool Exploit Kits payloads (attack vectors, rather, for the pass few days. The attack vectors consist of multiple vectors such as Flash, Java, PDF, Font and . It's interesting to see how the exploit kit is having probably the latest exploits released in public and also a 0day for Java vulnerability. The Cool Exploit kits is very stand out from many exploit kits due to Java 0day (please read the awesome article by @kafeine on the Java 0day analysis here). @kafeine also wrote a post on the Cool Exploit kits architecture here. So, i'll try to write multiple articles and only concentrating on analysis of these particular vulnerabilities used within the exploit kit: CVE-2011-3402 for TTF font, CVE2010-0188 for LibTIFF on Adobe's PDF, and CVE-2011-2110 for AVM bytecode confusion on Adobe's Flash. In this post, I'll focus on CVE2011-3402.

The analysis start with inspecting index's file retrieved from main page hosting the exploit kit. I'm using Thug ( a honeyclient honeypot, develop by Angello 'buffer' Dell'Aera) to speed up my analysis (so much thing to do when it comes to de-obfuscation of Javascript, ;P). Please refer for documentation on how to setup Thug and how to use it. Below is the Figure 1.0 screenshot of the result of page rendering.

Figure 1.0: Result from Thug showed the setup for @font-face pointing to font file at ../32size_font.eot with later being applied to "duqu" CSS style

The one interesting part of the Figure 1.0 is the word of "duqu". The IE font-face will fetch a remote font specified by the "src:url" parameter which pointing to ../32size_font.eot. A CSS style for the font-face using a font of ../32size_font.eot then sets to "duqu". The "duqu" style is important to understand because, in order to trigger the vulnerability in the font system, the font need to be called by the browser which later will call font engine (Win32k). Figure 1.0 [3], showed how the the style of duqu being rendered. Wasn't it cute when the smiley chars ":)" being showed in our browser?. I'll explain about this later.

The next step for the analysis is to download the 32size_font.eot for further analysis. The url for the 32size_font.eot is http://hosted_ip/r/32size_font.eot. In one of my analysis, i downloaded it via URL http://transport.hitandrun.cc/r/32size_font.eot.  

The Embedded OpenType File Format (EOT) was developed by Microsoft to enable TrueType and OpenType fonts to be linked to web pages for download to render the web page with the font. The understanding EOT format is crucial in order to reconstruct the original font. Please read a good specifacation from Microsoft on EOT specification here. The EOT is a mere container to enable the TTF font to be loaded into the application (in this case is a browser), thus triggering vulnerability inside a TTF font rendering system (Win32k).  Figure 2.0 showed a basic information about the downloaded file. 

Figure 2.0: Basic information for the 32size_font.eot

The FullName and FamilyName for the font sounds familiar. Symantec's report on Duqu pointed out about the font name used within the Duqu attack is called Dexter.  The FontDataSize value is 4004 bytes which represent the size of the embedded font.  Based on the Figure 2.0 result, I'm a bit curious about the "Flags" when "not-compressed" is presented. When checking the embedded font data, I failed to recognize any TTF metadata presented. So, I decided to write a new EOT file parser. Figure 3.0 showed the result of my EOT parser. 

Figure 3.0 showed the result of the new EOT parser

The new parser will parse the metadata of EOT file and will dump the embedded font into a new file. In this case, it will dump into Dexter. As for the flag, it showed a different result which has now been "tt_compressed" instead of "not_compressed". This result showed the embedded TTF font is compressed. According to Microsoft EOF specification, the compression algorithm used is the MicroType® Express algorithm. Based on this information, the Dexter file is required to be decompressed to retrieve the uncompress TTF font. Once the Dexter file is uncompressed, the TTF metadata can be showed as shown in Figure 4.0. 

Figure 4.0 showed TTF metadata

The next step is to analyze on the Dexter TTF font. A good documentation on CVE-2011-3402 and it exploitation possibility are described in a great detail from BlackHat Europe 2012 presentation (From Lee Ling Chuan aka lclee_vx) which can be downloaded from here and here.

In order to understand the TTF file format in easy way, 010 Editor's TTF Font template is used. Figure 5.0 showed the TTF Font format inside 010 Editor.

Figure 5.0 showed the TTF Font format inside 010 Editor.

Based on the lclee_vx's presentation, the criteria to trigger the exploit are pretty much the same with the extracted Dexter TTF font. Upon checking further, the shellcode can be discovered at FPGM Table. Two shellcodes is used, once is for ring0 and another one is ring3 shellcode. Ring 0 shellcode will copy and  execute ring 3 shellcode. Ring 3 shellcode is to download and execute (download and exec) a binary from this url: http://146.185.235.21/r/f.php?k=4. Figures 6.0 and 7.0 showed part of ring 0 and ring 3 shellcode, respectively.

Figures 6.0 Ring 0 (kernel) shellcode

Figures 7.0 Ring 3 (userland) shellcode

If we carefully check on the characters supported by the Dexter TTF font are only smiley chars which are ":)". So, in order to trigger the vulnerability, the smiley chars are used inside <div class=duqu>:)</div>. Please refer back to Figure 1.0.