While analysing the Fiesta Exploit Kit, a number of “java applets” and a Silverlight application was downloaded by the exploit kit. This post will describe the Silverlight exploit. The purpose of this post is to give a better technical understanding of how exploits makes use of vulnerabilities and play with memory to acheive shellcode execution.
[ Sample used in the analysis ]
[ Part 1: Getting Started ]
For those who want to follow along, this is a link to the Fiesta-EK-silverlight-exploit. Do note, this is a MALICIOUS file, so please run it in a “safe” environment. The password to the attachment is “infected29A”
Silverlight applications come in a .xap file. As .XAP file is a .zip compressed file that contains the client DLL for the Silverlight application as extra DLLs of assemblies that the Silverlight application could be using. This can be the author’s own assemblies of user controls or assemblies that are not part of the Silverlight runtime by default that gets installed on the client.
External resources like images or other types of files can also be added to the .XAP file if you do embed them into your client DLL. By renaming the .xap file to .zip you can view its contents. Inside the .xap file and we will see a manifest file and a DLL file:
The manifest file describes the entry point of the application so let’s take a look at that first.
In this case, the manifest file is quite straightforward. The “EntryPointAssembly” tells us that the application starts in the tuyngled30.dll and the “EntryPointType” tells us that it starts in the App class of that package.
The next step would be to decompile the dll file. For this purpose, I used .Net Reflector. Throw the DLL into it and you will get back the C# source of the internal classes. Let’s take a look at the entry point, the App class.
The constructor calls the InitializeComponent which actually loads in components based on a xaml file. Normally, you would want to look at the xaml file to see if it loads in any additional suspicious components but for this case, the xaml file does not load in anything extra. The Application_Startup method is also called when the Silverlight application is started. In this case, it creates a new “jake” object and passes it the InitParams (We will get back to these params later)
[ Part 2: Overview ]
This exploit uses 2 vulnerabilities to achieve code execution.
CVE-2013-3896 (Memory Disclosure vulnerability) bypasses ASLR by disclosing adjacent memory such that ROP gadgets can be reliably located within mscorlib.ni.dll.
After which, CVE-2013-0074 (Double-Dereference vulnerability) achieves code execution. DEP is also bypassed by overwriting the shellcode into legitimate executable memory addresses.
Also, this exploit seems to target only x86 (32-bit) architecture.
[ Part 3: Bypassing ASLR with Memory Disclosure CVE-2013-3896 ]
Let’s look at the “jake” class.
The constructor of the “jake” class assigns the init parameter of “dies” into the byte array named “curd” and then calls the “wake” method (we will get back to this “dies” param later).
The first interesting point of the wake method is on line 103. The “brab” method basically exploits the memory disclosure vulnerability and returns the address of the ROP gadget. For this part, we will examine the “brab” method. Part 4 will describe the rest of the code.
First, take a look at line 23 and 24. A “polk” object is created. Reading the source of the “polk” class will reveal that it is a subclass of the MemoryStream object. It will be used together with the BitmapImage and WriteableBitmap class to trigger this vulnerability.
The vulnerability lies in the BitmapImage.SetSource(MemoryStream ms) method. This method creates a BitmapImage based on a memory stream. The amount of memory that is read in is based on the “length” attribute within the stream. This value is controlled by user and can be manipulated to a larger value to read in adjacent memory.
In this case, the memory stream is manipulated to look like a PNG file with a declared PLTE chunk of 0x300 bytes. Those unfamiliar with the PNG format can read about it at the following links. These 2 chapters show how a PNG is represented and the idea of chunks within a PNG file. (http://www.w3.org/TR/PNG/#5DataRep and http://www.w3.org/TR/PNG/#11Chunks)
The constructor first writes 0x29 bytes into the memory stream. These 0x29 bytes is the header of a PNG file up till the PLTE chunk header.
The “racy.tunc” method then calls the BitmapImage.SetSource method which will call polk.Read method which has been overridden such that it will declare additional arrays in a specific order (specifically the scum and raps array). When these arrays are declared, they are stored right after the already written PNG header.
The last few array elements will store the PNG Footer.
When viewed as a contiguous memory chunk, it looks like a legit PNG file. The resultant memory layout of the “polk” object is shown below.
The main objective of this arrangement is to have the additional arrays be stored in the PLTE chunk of the PNG. If we look at the PNG specifications at http://www.w3.org/TR/PNG/#11Chunks under the PLTE Palette section, it says that
“The first entry in PLTE is referenced by pixel value 0, the second by pixel value 1, etc.”
On line 29 of the “brab” method, “racy.papa” method creates a WriteableBitmap object with the affected BitmapImage object. The disclosed memory in the PLTE Chunk can then be accessed with the WriteableBitmap.Pixels array. The method transforms this pixels array (which stores 4 bytes/pixel in a ARGB format) into a contiguous byte array and returns it. So why is the disclosed memory important? Let’s take a look at what is disclosed.
If you are not familiar with how C# stores objects/primitives in memory or about Runtime Type Information (RTTI), read this first ( http://www.abhisheksur.com/2011/09/internals-of-net-objects-and-use-of-sos.html) . Don’t worry if your RTTI addresses are different from mine, this is because these addresses are ASLR-ed. Basically, all objects in C# has this RTTI pointer. The RTTI stores type information that can be used for dynamic type-casting.
The objective here is to get the RTTI address. The RTTI address points to somewhere in the mscorlib.ni.dll which is ASLR enabled. However, this RTTI is always loaded at the same offset from the base address of the mscorlib.ni.dll. Therefore, with the RTTI address, the base address of the DLL can be calculated. With that, the exact location of the ROP gadget can be reliably determined thus bypassing ASLR.
[ Part 4: Achieving code execution with CVE-2013-0074 (Double De-reference vulnerability) ]
Looking back at the “brab” method again, these are what the other functions do.
- vamp(p1, p2) – Reads 4 bytes from p1 array starting from offset p2 (Read Pointer)
- oils(p1,p2,p3) – Writes 4 bytes (p3) into p1 array starting from offset p2 (Write Pointer)
- racy.lisp() – Returns the offset to find the ROP Gadget on different Silverlight versions.
- Based on this method, it seems to target the following Silverlight versions
The rest of the “brab” method does the following
- Save the RTTI pointer (num)
- Save the raps pointer (num2)
- Save the scum pointer (mews)
- Save the offset to ROP gadget (num3)
- Calculate and save the memory location of ROP gadget (num6)
- Get the memory address of 41 bytes before the end of the PNG (c) (Take note of this!)
- Writes a total of 8 bytes starting from memory address c in the following format
- Returns the value of c “pointer to itself” (Take note of this!)
Let’s return back to the “wake” method.
The next important step is on line 109. The “diam” class exploits the CVE-2013-0074 vulnerability. The vulnerability lies in the ScriptObject.Initialize method. Fortunately, this is a protected method, meaning only child classes can call it. Unfortunately, ScriptObject has a public child class called HTMLObject. By sub-classing the HTMLObject class, it is now possible to call the protected Initialize method.
The “diam” class inherits from HTMLObject and wraps the Initialize method in the “gain” method. Calling the “gain” method with “(IntPtr) a” will lead to a “call [a+4]” instruction, meaning the next pointer after “a” will be called.
Recall that in the “brab” method, the above 8 bytes was written in the IDAT chunk, 41 bytes before the end of the PNG? Line 109 calls the “gain” method with “pointer to itself” as the parameter. This would lead to a “call [ptr to ROP gadget]”, thus executing the ROP gadget.
So, what ROP gadgets are being used? Interestingly, this ROP chain only consists of 1 gadget. The gadget consists of the following byte sequence “83-49-34-40-B8-01-00-00-00-C2-04-00”. Passing this sequence into Capstone yields the following result.
The gadget simply performs an OR operation with the value in [ecx+0x34] with 0x40.
Analysing the memory with WinDBG reveals that ecx at this moment contains the value of the “pointer to itself”. Therefore, [ecx+0x34] actually points to somewhere after the PNG “file”. In this case, it points to the most significant byte of the length of the next adjacent array, jake.chap.
By performing this OR operation, it changes the length of the jake.chap array from 0x00000003 to 0x40000003, effectively allowing jake.chap array to access the entire 32-bit process memory space.
[ Part 5: Executing the Shellcode ]
With access to the entire memory space, the next step would be to get the exploit to run the shellcode payload. From line 114 of the “wake” method, a “jake.loci” object is created. This object is responsible for putting the shellcode into memory and executing it.
Take note of the “bust” method. It is the first method declared after the constructor and it contains a lot of code that does nothing. It performs a whole lot of mathematical operations and the result is neither returned nor used.
On line 115, the “loci.pore” method is called next with the parameter “curd”. The “curd” here refers to “jake.curd”. Recall the initParams that was passed into this Silverlight application in the beginning? “jake.curd” contains the value passed in through the “dies” parameter. The “loci.pore” method basically transfers “jake.curd” into “loci.curd” variable.
This is actually the shellcode itself, it is Base64 encoded and passed in through the initParams of the Silverlight Application. In this way, the shellcode could be changed or modified without needing to recompile the whole Silverlight application.
On line 116, the “gnaw” method is called. The comments basically explain what this method is trying to do. Here is a summary. (Note: [“pointer”] means dereference the pointer)
- Create “bust” method to make sure a vTable entry is created.
- Create a new array “scum” which contains a marker value and the pointer to this “loci” object
- Iterate through the jake.chap (with 0x40000003 length) to find the marker value
- “loci” pointer = next pointer from the marker value
- vTable pointer = [“loci pointer”] + 0x2c
- “bust” function pointer = [“vTable pointer”] + 0x8 (I believe the value 0x8 is used because “bust” is the second function in the “loci” class)
- Exchange the bytes from “loci.curd” (Shellcode) and the bytes at [“bust pointer”]
- Call the “bust” method (Shellcode Execution Here!!!)
- Exchange the bytes back from “loci.curd” and the bytes at [“bust pointer”]
- Restore the length of jake.chap to its original value (Element 0x3fffffff causes an integer overflow, essentially becoming jake.chap[-1])
Shellcode execution is achieved by making use of the jake.chap array to override the “bust” function instruction bytes with the shellcode bytes and then calling the “bust” function. In this way, there is no need to bypass DEP as the shellcode is residing in a legitimate executable memory.
Although I am unable to confirm this, I believe that the length of the initial “bust” function instruction bytes must be the same as the length of the shellcode that will replace them. This would explain why there are a whole lot of useless instructions initially declared in the “bust” function.
[ Conclusion ]
I have discussed how this exploit made use of 2 vulnerabilities to achieve shellcode execution. I hoped that you gained a better understanding of how the exploit was able to work. Also, an additional point to note is that the exploit code is similar to the POC code initially released by Packet Storm for these 2 vulnerabilities.
This is also my first time writing such a technical article and there are some parts of the article that I found it difficult to explain the technical details in words. If you have any advice/suggestions on how to improve this, please let me know through the comments.
If not, I hoped you enjoyed the article!