Internet Explorer Zero Day: CVE-2014-0322

Recently, several security vendors reported about a new IE 0day which affects version 9 and 10. The attackers targeted the U.S. Veterans of Foreign Wars website (vfw.org) with an injected iframe which contained a previously unknown exploit for IE.

Below we'll detail some of the techniques used by the hackers behind the attack and draw your attention to some similarities in the payloads of this vulnerability and CVE-2012-4792 (which we took a look at last year).

The hackers behind the attack used several techniques to help them stay "under the radar" as long as possible:

1. The malicious IFRAME, although containing the exploit in function "puIHa3()", doesn't execute the exploit by itself - instead, it embeds a Flash file, which in turn executes the malicious function of the parent HTML:

   a. The malicious IFRAME embeds the flash file:
   
   
   
   b. Here is a snippet from "Tope.swf" which executes the puIHa3() function that is defined at the parent HTML:
   
   

Besides triggering the exploit, the current Flash file is also used for spraying the heap and for bypassing ASLR protection. Using Flash in malicious campaigns is becoming very popular these days for various reasons: its efficiency in heap spraying and its ability to interact with the parent HTML and actually execute JavaScript code as if it is part of the HTML DOM. We have actually seen recent attacks where all the IE exploit code resides entirely inside the Flash file which is embedded in the HTML page. These capabilities add more layers of evasion to the attack.

• When the malicious function from the HTML is finally executed, the exploit will be executed unless the user has EMET installed (Microsoft's Enhanced Mitigation Experience Toolkit). The attackers check for the existence of EMET.DLL file, using Microsoft.XMLDOM ActiveX:
  
  
  
  And the path of the DLL is provided to the function:
  
  
  
  We may assume that they have tested their exploit against EMET prior to deploying the exploit in "production".
  
  
• Although this vulnerability exists in IE9 as well, we see no code to support exploitation for IE9. This could be due to various reasons:
  
  a. They had intelligence regarding their target's browser version.
  
  b. They were short in time or money and decided to proceed as is.
  
  We don't know the actual reason for this, however it is clear that the attackers aren't rookies as they don't proceed with exploitation unless IE10 User Agent is detected. This ensures no false attempts are made, which could only lead to early detection.
  
  

When the exploit succeeds, the Flash file drops to the victim's machine a malicious file named "Erido.jpg".

_{Analyzing the Payload}

Some of our readers with excellent memories may remember a blog post from January 2013 where we took a look at a payload for CVE-2012-4792. You may be wondering why we'd mention this post. As it happens, the payload for CVE-2014-0322 has a remarkable number of similarities. In fact, there are so many similarities that a good argument could be made that the author of the previous payload is also the author of this one. As we've already spoken in great detail about the previous payload, we'll take this opportunity to outline the similarities and differences between the two.

Similarities / Differences

First and foremost, let's discuss how these payloads are similar. One of the first similarities that immediately jumps out at the analyst is string decryption routine, which once again makes use of a simple XOR scheme. The malware then immediately enters an installation routine, where we see a number of other similarities. Specifically, they use the same routine for determining whether the victim is running a 64-bit operating system (OS). Additionally, the same technique for UAC bypass is seen, with a dropped DLL used (DLL determined based on OS architecture).

Finally, one of the largest similarities witnessed is the command and control (C&C) structure, which has remained near identical, as seen below:

You may notice two additional commands in this list. These will be discussed shortly. The encryption scheme of XORing the data against 0x59 remains the same, as well as the structure of the sent and received C&C data.

The sample we saw previously was more than a year older than this one, it's not surprising that some changes have been made. During the installation of the malware, it is no longer installed as a service. Instead, the malware uses the common 'Run' registry modification, as we see below:

[HKLM|HKCU] SOFTWARE\Microsoft\Windows\CurrentVersion\Run\MicroMedia - %Temp%\MicroMedia\MediaCenter.exe

The path seen above is the location the malware will copy itself to during installation. The other major modification during the installation process is the removal of the installation as a service, and the addition of the installation of a COM server. In addition to these changes, we see the network communication change slightly, as three distinct URIs are used. We also see those two additional commands that I previously mentioned. The first added function (case 7) simply uploads basic information about the malware, including the process ID and the path of the malware. The second added function (case 8) executes a command within the context of cmd.exe and uploads the response.

In summation, these two binaries, while over a year apart, are very similar both in the coding style and their functionality. It's extremely likely that the same individual or group of individuals authored both binaries.

At the time of this writing, Microsoft still hadn't provided a patch for the security flaw.
Until that happens, we would recommend that all users of Internet Explorer upgrade to IE version 11, install EMET or use another browser.

Trustwave SWG blocked this threat out of the box without requiring any additional updates. We will also address this vulnerability in the coming updates in order to protect against any future variations of it.

What would be the first Exploit Kit to integrate this 0day exploit? Time will tell…

Thanks to the Seculert team for their help with this project. See their post on the topic here.

This blog was co-authored by Josh Grunzweig and Rami Kogan.