Aurora exploit still floating ...

It's been around two years since Microsoft released a patch for the IE 0day famously known as the Aurora exploit (CVE-2010-0249). We had blogged about this in the past when it was first seen in the wild on the 'GOV.CN' domain. This vulnerability targets IE version 6. Despite the passage of time, we continue to find live exploits for this vulnerability. Recently, we found a new URL which is serving the Aurora exploit code.

Exploit URL: hxxp://www.artbridal.com/bizcodi/gm/news.html

Let's take a look at the exploit code being delivered.

 

The exploit is delivered via obfuscated JavaScript code, although the level of obfuscation is not very high. Some of the strings and JavaScript function names are been obfuscated. The following is a snapshot of the de-obfuscated code.

If you observe the first image, the SPAN tag holds an IMG tag on which the 'onload' event calls an event handler  function 'eve'. This in turn creates an event object called 'e1', using the 'document.createEventObject' method. Then, by using an '.innerHTML' property, it assigns a null string to SPAN object 'sp1', but instead, the 'sp1' object is removed. In the function 'eve', the freed object is referenced, causing memory corruption in the form of an access violation in IE. To exploit this condition, the exploit code uses a typical heap spray technique to load the shellcode into memory for the execution. When the shellcode is executed, it tries to download a malicious file from the URL 'hxxp://fly-tld.ru/w.php?f=47&e=3'.  For a more detailed analysis, you can refer to this blog.

To obtain the aforementioned URL, the PE executable file was formed and extracted from the shell code in the exploit. The EXE was then examined using a debugger to extract the URL as can be seen below.

This URL is down at the moment, so further post exploitation analysis was not possible.

Reports:

VT URL Scan on found URL : 4/51 detections.

VT File Scan on EXE formed from Shellcode: 27/41 detections.

Various other URLs that have been seen in the past with similar patterns - '/w.php?f=(\d){2}&e=(\d){1,2}' include:

hxxp://synergyledlighting.net/w.php?f=56&e=4
hxxp://nicesextubes.co/w.php?f=18&e=6 
hxxp://iplaecrcocee.com/w.php?f=26&e=2
hxxp://iplaecrcocee.com/w.php?f=26&e=2
hxxp://examine.arsb.co.uk/w.php?f=20&e=2
hxxp://exciting.simssocialcheat.com/w.php?f=22&e=2
hxxp://oyacromifh.com/w.php?f=26&e=2
hxxp://eteaescopr.com/w.php?f=26&e=2

The obvious reason behind attacking old CVE's is the belief of attackers, that there are still un-patched and outdated browser's out there on end user machines. Sadly, they're correct. To avoid such attacks we suggest updating browsers with latest patches and migrating to the most recent version of the browser. 

Stay updated, Stay Safe!

Pradeep

Expack continues exploiting Java vulnerability

Exploit kits available in the wild tend to follow a trend by exploiting vulnerabilities reported in various browser components which are commonly deployed. Recently, we have seen an increase in exploitation of a year old vulnerability reported in the JRE component of JAVA (CVE-2012-1723). Exploitation of this vulnerability in JRE allows a attacker to download malware onto a victim's machine and execute it. Let's looks at an analysis of such an exploit kit recently found in the wild.

Exploit Kit URL:

hxxp://174.142.240.91/577ac477f62d4873cf41dc834d107b7c/influences-portal.php

When accessed, the above exploit URL executes obfuscated JavaScript and loads an applet into the browser as shown below:

Obfuscated source code:

Let's analyze the above obfuscated JavaScript code by de-obfuscating it. While de-obfuscating the JavaScript code, we noticed that the code has multiple layers of obfuscation. For the scope of this article, lets skip ahead to the end of the de-obfuscation process. 

As usual, the exploit kit request loads content based on the version of the browser and versions of different plugins installed in a browser by running browser/plugin detection logic embedded in obfuscated JavaScript. The exploit kit targets vulnerabilities in JRE (Java) and Adobe components of the browsers.

Let's take a look at following de-obfuscated code which loads malicious applet into browser:

The following code calls the relevant functions above, depending upon the JRE version found on the victim's machine:

The applet is executed by the browser, which then downloads a malicious .jar file from following URL,

hxxp://174.142.240.91/577ac477f62d4873cf41dc834d107b7c/influences-portal.php?gKoRO=UfhqAFb&gCTEVgSTdQbZjI=wUkSXV 

The de-complied code of the downloaded .jar file is also heavily obfuscated. 

VT Result: 13 / 45

MD5:  361b0e1eab5e647315e6873ea16ca720

This .jar files exploits the vulnerability in the JRE, which allows the attacker to download additional malware and execute it the browser context.

 

 VT Result: 13 / 46 

MD5: a151fdce265ba4fcab1b36bd624d330f

A Trojan then connects to the CnC server by sending POST data and in response, the CnC server replies with 'STATUS-IMPORT-OK'.

After receiving command 'STATUS-IMPORT-OK' from the CnC server, The Trojan then downloads another malware file (6.exe) from the same domain which looks to be a variant of ZerooAccess rootkit. The detection rate for the '6.exe' is also fairly low on VT.

VT-Result: 6 / 46  

MD5: b152b3d170dc089b057fbbe3d6393764

Exploitation of browser components such as Java and Adobe plugins by exploit kits are now a very common reason for enterprise PCs to become compromised. My colleague Krishanan Subramanian recently blogged about a rise in Red Kit Exploit Kit Activity, which also addressed the same vulnerability in Java. It is vital that enterprises ensure that browser plugins are always patched and up to date, something enterprises regularly fail to do. In the case Java, given the now regular stream of 0days that it has inspired, you may want to seriously consider disabling Java altogether, at least at the browser level, something that you can read about in a previous blog post entitled: Are you vulnerable to yet another Java 0Day exploit?

Pradeep