Exploit Kits: Anatomy of a Silverlight exploit

With the significant adoption of Silverlight technology in today’s market, it has become one of the popular targets for the hacker community. We have observed many popular exploit kits (EKs) like Nuclear and Fiesta, serving specially crafted exploits targeting Silverlight vulnerabilities. Recently, we blogged about the Nuclear Exploit kit live infection cycle, which was leveraging Silverlight vulnerabilities to infect the victim’s computer. In this blog, we will take a look at the Silverlight exploit payloads and how they are embedded in the Exploit kit.

A Silverlight file is a zip archive with an ".xap" extension and it is written in the .NET language. This XAP file contains a list of one or more .NET managed assemblies (.DLL files) along with the AppManifest.XAML file.

We have observed that Exploit kits are generally targeting following Silverlight vulnerabilities:

• CVE-2013-0074: Memory Dereference Arbitrary Code Execution Vulnerability.
  This vulnerability is due to an improper boundary checking of the user supplied input which leads to arbitrary code execution.

• CVE-2013-3896: Information (memory) disclosure Vulnerability
  By exploiting this vulnerability an unauthorized attacker can gain access to the sensitive information. This bug is used to bypass the exploit mitigation technologies.
  
  
  The following is a typical infection cycle involving Silverlight exploits in EKs:

Dissection of the Infection Cycle and Silverlight Exploit:

As we discussed in our previous blog, the landing page of the Nuclear Exploit kit is heavily obfuscated to evade Anti-virus detection. The function highlighted below is invoking the Silverlight exploit:

As we stepped through the deobfuscated code, we found that the exploit author has implemented multiple unused variables to possibly confuse analysts. We saw a parameter named “tuti” which contains the base64 encoded data that decodes the shellcode.

Upon successful execution of the silver_run() function, the Exploit kit will download a malicious XAP file with the following GET request.

The downloaded XAP exploit consists of three files as shown below.

The AppManifest.xaml file contains the deployment details needed to run the Silverlight application. The first element of it starts with a deployment node which defines the Assembly information, Runtime version, Application Entry point and the assembly extension parts. In this file, There is an attribute called 'RuntimeVersion' through which we can target a specific version of Silverlight. There are two other important attributes, namely EntryPointAssembly & EntryPointType which are mainly used for loading the XAP file.

Reverse engineering the .NET DLL file is straightforward, because it is MSIL (Microsoft Intermediate Language) and there are multiple tools at our disposal. We used the Telerik JustDecompile tool to decompile the DLL. The following screenshot shows us the list of the classes used by the asdgsd.dll.

The screenshot below shows the entry point routine asdgsd.App. The constructor of asdgsd.App is used to call the shlyapa class.

The following activity is performed by the shlyapa class which attempts to exploit multiple silverlight vulnerabilities:

• Get the .NET run time environment version and store it in the “mild” variable.
• Get the base64 encoded stream from aforementioned “tuti” parameter and store it in “brae” variable and invoke the "dips" function.
• In parallel, the function “lout” generates the “numArray” leveraging  class “chaiki”.
  

  

•     Function "lout" generates the "BitmapImage" instance by calling function "game" from "alupka" 

• The function "huts" is leveraging CVE 2013-3896 (A memory disclosure vulnerability in the public WritableBitMap class) to calculate the base-address of "mscorlib.ni.dll" as seen below:

        

• Finally, the "dips" function executes the "spca" function that takes the base-address of "mscorlib.ni.dll" as an argument. The "spca" function is triggering CVE-2013-0074 (Dereference Vulnerability during HTML object rendering) as shown below:

The following is a sample of live Nuclear Exploit Kit domains that we have seen in past 24 hours:

Nuclear EK Domains 

indyresident[.]gq

macropromise[.]ml

hybridvertex[.]gq

macropromise[.]ga

uthunilaej[.]co[.]vu

daviddaniel[.]cf

brightrolling[.]ml

culturemerge[.]ga

Conclusion:

We continue to see the Silverlight vulnerabilities mentioned in this blog being exploited by many other popular exploit kits. Zscaler is actively monitoring and protecting end users against this threat.

Credit for Analysis & Guidance : Dhruval Gandhi

De-obfuscating the DOM based JavaScript obfuscation found in EK’s such as Fiesta and Rig

There is little doubt that exploit kit (EK) developers are continuing to improve their techniques and are making exploit kits harder to detect. They have heavily leveraged obfuscation techniques for JavaScript and are utilizing browser functionality to their advantage. Recent exploit kits such as ‘Fiesta’ and ‘Rig’ for example, have been found to be using DOM based JavaScript obfuscation. In this blog I will demonstrate a simple approach to de-obfuscate DOM based JavaScript obfuscation.

Before we dive in, it’s important to understand the difference between older EK’s such as Blackhole and Incognito versus newer ones such as Fiesta and Rig. A key difference between them is the way they de-obfuscate code in the victim’s browser. The newer approach de-obfuscates JavaScript snippets and stores them into DOM by building an element tree. Older EK’s by contrast were heavily using JavaScript functions such as ‘eval’ and ‘document.write’ to de-obfuscate the JavaScript. 

Let’s start by taking a look at a Rig EK sample. 

Rig EK page:

Heavy obfuscation of Rig EK JavaScript code

Unlike most EK’s, instead of running plugin detection code first, it instead starts by checking for the presence of Kaspersky and TrendMicro antivirus (AV) programs. If any of the AV driver files are found on the victim’s machine, the exploit execution stops. In order to check for the presence of these driver files, the EK uses the ActiveX object ‘Microsoft.XMLDOM’. The routine labeled ‘df3z’ does the inspection.

AV driver checking code

 Driver file information:

 Take note of the following statement,

The above value of variable ‘sdf43w’ is used later on in the JavaScript. 

If no AV driver for Kaspersky or TrendMicro is found on the victim’s machine, the code then initializes the de-obfuscation routine. First the Javascript creates a ‘div’ element and appends it to the DOM. The remaining JavaScript, which is heavily obfuscated contains exploit code targeting vulnerabilities for Java, Flash and SilverLight browser plug-ins.

 

First JavaScript:

Let’s take a look at the JavaScript code to understand how it’s building the DOM element tree.

First JavaScript

To summarize,

• Function ‘alz’ concatenates a string passed to it and assigns the concatenated string to the ‘ty6’ variable. This is later used by the de-obfuscation routine. 
• Element ‘dn3d’ with a type of “script” is created.
• De-obfuscated (final) JavaScript is assigned to the element ‘dn3d.text'.
• Element ‘dn3d’ is appended to the ‘document.body’ i.e into the DOM tree for later execution.

To get the de-obfuscated code for this JavaScript we need to get the value of ‘dn3d.text’. For that I added a line called ‘console.log(‘dn3d- 1: ‘ + dn3d.text)’. I am using the Google Chrome browser to complete de-obfuscation and all of the analysis is carried out in an isolated environment. To get the console logs, you need to open developer tools in Google Chrome browser.  Apart from console.log you can also leverage other JavaScript functions like ‘alert’ or ‘document.write’ to get the de-obfuscated code

.

De-obfuscated code for first JavaScript segment:

JavaScript Console Output

The beautified version is shown below:

Here you can see the value of ‘dn3d.text’ is a JavaScript, which is then, is added into DOM tree. This JavaScript contains function ‘dsg45’, which creates element ‘bd6’ of type ‘div’ and appends it to DOM tree and also assigns a passed value of variable ‘hgd1’ using property ‘innerHTML’ of the created element.

All the remaining obfuscated JavaScript is structured like the aforementioned code. The following shows the second snippet of JavaScript, which actually contains the malicious applet code.

Second JavaScript snippet: Exploits Java vulnerability

Again, I’ve added a ‘console.log’ function to get the de-obfuscated JavaScript, which later will be appended to DOM tree and will be executed.

De-obfuscated code for the Second JavaScript snippet:

Malicious Applet Code

You can see above, the malicious applet code is assigned to variable ‘jg67fgf’. This value is then passed to JavaScript function ‘dsg45’, which was appended into the DOM tree by the first JavaScript snippet (see above).

Similarly the remaining two JavaScript snippets are de-obfuscated using the aforementioned method.

De-obfuscated code for the third JavaScript snippet: Exploits Silverlight vulnerability

Malicious SilverLight Code

De-obfuscated code for the fourth JavaScript snippet: Exploits Flash vulnerability

Malicious Flash Code

To get all of the de-obfuscated code above I would normally need to conduct code analysis to find the ‘dn3d.text’ variable, which contains the de-obfuscated JavaScript code. This would require fair bit of code analysis and understanding of JavaScript and DOM. As such, I wanted to find a simple solution which would provide all of the de-obfuscated JavaScript at once. Fortunately, I was able to identify a shortcut. Since all of the de-obfuscated JavaScript is stored in DOM tree, we can crawl the DOM tree and get the element value once for all of the EK script has executed. For this, I wrote a simple JavaScript routine which I call ‘domWalkerAndDeobfuscator’. By putting this code at the end of the EK sample, we can get all the JavaScript being stored into DOM, which in turn contains the de-obfuscated code.

domWalkerAndDeobfuscator at the end of EK:

domWalkerAndDeobfuscator

‘console.log’ output after appending domWalkerAndDeobfuscator:

JavaScript Console Log

Malicious Applet code:

JavaScript Console Log

 Malicious Silverlight code:

JavaScript Console Log

Malicious Flash code:

JavaScript Console Log

My trick worked and gave me the full de-obfuscated code of the Rig EK sample. This increased my curiosity and tried the same ‘domWalkerAndDeobfuscator’ on the Feista exploit kit sample.

  

Fiesta EK:

Fiesta EK

De-obfuscated code obtained from ‘domWalkerAndDeobfuscator’ through console.log for Feista EK:

JavaScript Console Log

The Feista EK also contains exploit code for Java, Flash and SilverLight plugins.

Adding a simple DOM walker (crawler) script made the job easy of de-obfuscating DOM based obfuscated EK far easier. I’ve tested the approach with samples of Rig and Fiesta so far and every time was able to get the de-obfuscated code in seconds instead of doing the heavy lifting required for manual analysis.

Conclusion: Previously with older EK’s it was easy to de-obfuscate the code using many online tools and with manual analysis, but due to the introduction of DOM based obfuscation techniques the difficulty has increased. Many tools are failing to de-obfuscate the code for newer EK samples. Fortunately, the approach of walking the DOM solved the issue in seconds. 

Pradeep