Microsoft Office RTF Exploit : CVE 2015-1641 Dissecting the Shellcode

Few days back , I came across interesting RTF exploit floating around, eventually concluded as CVE -2015-1641 vulnerability. I was particularly interested in knowing about the DEP / ASLR bypass mechanisms and shellcode used in this exploit . I decided to dig little deeper into this exploit to figure out how it overcomes the windows mitigation mechanisms.

First step for me to start with analysing any MS Office exploit is to run it through my own developed static analysis framework for Office exploits , which can precisely extract the embedded streams, locate the shellcode and can do bunch of other analysis stuff. Notice that 4 embedded binary objects has been extracted out of the RTF exploit.





Looking at the log file , we'll observe few stuff which is worth further investigation.
















It has also extracted 2 Open Office XML document embedded within the RTF exploit. Static analysis framework further has the ability to re-analyse extracted OOXML files. If we take a look at the anlaysis.log file for the extracted_ooxml_1, it has detected a shellcode in the embedded object activeX1.bin












and similar for the extracted_ooxml_2










Below graphical representation of the shellcode apparently indicates the API address resolving code , parisng the export table as you'd normally see in most of the exploits.
















Lets take a look at the interesting embedded binary objects.

ASLR Bypass - object_00000020.bin






otkloadr.WRAssembly.1 is the ProgID that loads otkloadr.dll. This DLL is linked to another MS Office component MSVCR71.dll , that will get loaded once the exploit is executed and the one which is used to bypass ASLR. MSVCR71.dll is shipped along with the MS Office and it is not compiled with /DYNAMICBASE which makes possible to hardcode the addresses for ROP chain.











object_000000E6.bin

This object contains the embedded OpenOffice XML document which includes activex1.bin that is used to perform the heap spray before the vulnerability is triggered. This technique is similar to the one used in CVE-2013-3906.








Following structure of the activex1.bin used for Heap Spray clearly reveals the shellcode. This structure of RET sledge + ROP chain + NOP + Shellcode is repeated every 0x20000 bytes

















object_000187A1.bin is responsible for triggering the vulnerability. I wont't be digging much into the vunerability details since it has already been covered in greater depth in the blog over here

object_0002802c.bin also has OOXML document embedded and activex1.bin inside it leads to believe that EIP will be overwritten with 0x08080808 after the vulnerability is exploited. It is yet unidentified at what point this happens but the structure of the binary object is apparent. This can be confirmed by launching the exploit in the debugger as exposed in the next section.


















One of the fact to note about this exploit is that it crashes several times when the execution is transferred to the heap at address 0x08080808, where the shellcode doesn't exist. Once we launch the exploit in the debugger , we can check out the non-aslr module MSVCR71.dll loaded by otkloadr.dll







After the exploit is launched , it performs the heap spray and subsequently,vulnerability is triggered to redirect the execution control to the heap , overwriting EIP with 0x08080808.

Shellcode Analysis - 1st Stage

1. Beginning of the 1st stage shellcode, as we would usually see in most of the exploits, parses the Process Environment Block ( PEB ) and deternines the base address of kernel32.dll. It then parses the export table of kernel32.dll to resolve the address of VirtualAlloc( ) API.












2 . Calls VirtualAlloc ( ) to allocate the buffer and copies the hashes of the APIs to be resolved further, and then again returns to the export table parsing routine to resolve address of GetFileSize ( ) , CreateFileMapping ( ) and MapViewofFile ( )











3 . Next, the shellcode tries to locate itself in the memory by incrementally passing the file handles to the GetFileSize in the looped code. If the file size is greater than 40KB and less than 2MB, it calls CreateFileMapping and MapViewofFile ( ) to map the file into the address space of the calling process and matches the first 4 bytes of the file to check the RTF header.










4 . Subsequently, it adds the offset 0x10000h to the beginning of the file and searches for the 2nd stage shellcode marker 0xFEFEFEFE and 0xFFFFFFFF and eventually jumps to execute it.










Shellcode Analysis - 2nd Stage

1 . At an offset 0x2E from the start of the 2nd stage shellcode , it XORes 0x3CC bytes of the shellcode with the single byte XOR key 0xFC.











2 . Calls NtQueryVirtualMemory( ) API to retrieve the original name of the exploit document , converts the filename to ASCII using WideChartoMultibyte ( ) and then calls GetLogicalDriveStringsA ( ) to append the current logical drive to the document name



3 . Searches for the marker 0xBABABABA, subsequently decodes the XORed encoded executable with 4 byte XOR key 0xCAFEBABE , calls GetTempPathA ( ) and writes the decoded executable to the %temp% directory with the name svchost.exe















4. Next part of the shellcode searches for the marker 0xBCBCBCBC , XOR decodes the decoy document with the 4 byte XOR key 0xBAADF00D and then calls previously resolved API UnmapViewOfFile ( ) to unmap the original exploit file from the process's address space,writes the decoy file to the original exploit document and eventually executes it using WinExec ( )
















5. Invokes cmd.exe to delete the registry key "HKCU\Software\Microsoft\Office\12.0\Word\Resiliency" with /F switch to force delete and suppress the error messages from Winword.exe














Decoy document :









At the time of writing this analysis, dropped executable connected to the C&C server login.loginto.me resolving to 58.158.177.102. Based on the passive DNS records this domain also resolved to 23.249.225.140

Evading Sandboxes : Into The Loopholes Of Sandboxing Technology - Part 2

Malware authors tend to come out with the innovative methods to detect the virtualized / sandboxing territory and cease to execute the moment they discover it. A while back , I blogged about some of the sandbox evasion techniques used by malwares. In this part , I'll walk through some of the most recent and efficient evasions used by malicious code to identify sandboxes.

Today, Advance persistent threats and targeted attacks tend to wait for the human interaction with the system to activate the malicious code. Since automated malware analysis frameworks process millions of samples per day, human interaction is bare minimal and malwares does not replicate and as a result, does not show complete behavior. Underlying hardware used to replicate the malwares also expose several artifacts about the environment which isn't too hard to notice.

Another flavour of DeviceIoControl ( )

In my previous post on this topic , I talked about the technique of using DeviceIoControl ( ) API to fingerprint the hard disk properties. This technique was yet again observerd in Win32/Phorpiex family of malware with the different IO control code. Win32/Phorpiex uses the IoControl Code 0x2D1400 (IOCTL_STORAGE_QUERY_PROPERTY) to check the returned device properties for virtual hard drives.













With this method , notice the output on Vmware and Qemu . It exposes the underlying hard drive properties on both the virtualized environment.

Windows Management Instrumentation

Windows Management Instrumentation is the Microsoft’s implementation of Web-Based Enterprise Management (WBEM) which is the industry initiative to develop standard technology for accessing management information .WMI is the default windows service that can execute the WMI scripts which is typically used to automate the administrative tasks. Above that, it provides common interface and object model to extract the management information about the OS, processor, hardware devices, applications and services.

Malwares can abuse this windows interface in multiple ways. One of the method is using WMI Query Language (WQL) to issue the SQL type queries to extract the hardware information. For instance, following queries can be issued by the malware to retrieve the Hard Drive / Processor information and match the keyword QEMU / VMware / Xen in the values returned.

SELECT *FROM Win32_Processor
SELECT *FROM Win32_BIOS
SELECT *FROM Win32_DiskDrive
SELECT *FROM Win32_SCSIController
SELECT *FROM Win32_ComputerSystem




















Checking the time acceleration using GetTickCount ( )

Traditional ways to detect the userland hooks had been to check if the function code does not start with the JMP or CALL instruction. One of the variant of Win32 / Kovter malware family was found to be using slightly different way of checking for the user mode hooks using time acceleration. It calls the API GetTickCount, then sleeps for 500 milliseconds and then calls the GetTickCount again to take the difference of the elapsed time. Sandbox systems historically have been patching sleep ( ) calls to force the stalling code execute faster. This technique performs the difference the time and checks if the code has stalled enough before executing the malicious code. It will terminate the execution if it determines that enough time has not elapsed between these instructions.












No of CPU cores on the virtual machine

Checking the number of CPU cores on the machine executing the malware is yet another elementary way of detecting the sandboxes environment. Analysis machines used by sandboxing environment are customarily configured with the single core while physical machines are predominantly multi core machines. Malwares can get the number of CPU cores by just calling the GetSystemInfo ( ) API taking the pointer to the SYSTEM_INFO structure, which returns the system data.SYSTEM_INFO structure contains the attribute dwNumberOfProcessors field which can be checked to see if the system is a single core machine.











Similar check can also be done by accessing the Process Environment Block of the running process. Offset 0x64 in the PEB defines the NumberOfProcessors on the system.













Foreground Windows check using GetForegroundWindow API ( )

One of the very predictable behavior of sandboxes is that they do not change or switch between the windows when the malware is being executed. Typically, this window would be the one from where the malware is executed and could be most likely desktop window. Recent variant of Win32 / Gataka banking malware was found to be taking the advantage of this behavior by calling GetForegroundWindow () API to get the handle of the current foreground window. Malware ceaselessly calls this API in the loop until the current window handle is changed after which it starts executing the malicious payload, thereby checking if the human is interacting with the execution environment.














Waiting for mouse clicks using SetWindowsHookEx ( ) API

Variants of Win32 / Banechant malwares employs more stealthier mechanism to evade the sandboxes. It installs the hook procedure using SetWindowsHookEx with the hookId 0x0E into the hook chain to monitor low level mouse events. This API defines the HOOKPROC specifying the callback function to execute when the windows receives mouse events. Earlier variants of Win32 / Banechant checked for a single left mouse click in the callback function before the malicious code is executed while the later variants came with the improved technique of checking for the more than three left mouse clicks before the activation of the payload.













As and when sandboxing technology becomes more popular and its adoption grows , malware authors will employ increasing level of sophistication in detecting sandboxes. It is extremely crucial for automated malware analysis systems to keep abreast of all such methods and patch it to keep the environment hidden.

Espionage Attacks On Indian Organizations Continues In 2015 With More Politically Themed Exploits..!!

In November last year, I blogged about Operation Mangal , an ongoing targeted attack campaign against several Indian domestic and overseas organizations. I was actively tracking the campaign since last year. In my previous analysis of this attack I uncovered several exploits that were politically themed and closely connected to India’s developmental agenda. The exploits lured victims into opening malicious documents that compromised their machines and stole confidential data. We found that this campaign has been going on since 2010 with periodic variations in the malware families.

Since January this year, we have seen a steady flow of similar exploits as part of this campaign. These exploits continue to be politically themed and closely follow national events. The following are some recent exploit filenames or themes:

• Indian Diplomacy At Work — UNSC Reforms.doc (MD5: faa97d7c792e3d8e7fffa9ea755c8efb; first seen: Oct 31, 2014).
• Vibrant Gujarat Summit 2015.doc (MD5: b44a0ebddabee48c1d18f1e24780084b; first seen: Jan  6).
• U.S.,_India_to_formulate_smart_city_action_plans_in_three_months.doc (MD5: b0ae36bcf725d53ed73126ed56e55951; first seen: Jan 28).

During late 2014 and early 2015, the attackers modified the shellcode and the dropped malware family, continuously changing their tools and techniques. Some of the recent exploits involved in this campaign has been found to be dropping PlugX malware . The following images show how the shellcode has been modified between exploits observed on January 6 (at left) and January 28 (at right).

While researching this campaign , I was able to gain access to one interim control server, which appears to be the short-term registration server that the compromised host communicates with after decoding the first-stage URL. The directory structure of the control server is:

/cms: 

This directory holds all the client data in JavaScript Object Notation from compromised machines connected to this server. The following image shows the directory structure and the information stored in the file:

Filename: h_HOST-NAME_TIMEVAR_t. All the machine information (IP, MAC, OS type, hostname, OS version, infection time stamp, etc.) was recorded on the remote server with this filename.

Next we see how the machine information looks on the control server, highlighting the infection time stamp from late last year:

Filename: r_off_PCNAME_TIME_TIME_t. This holds base-64 encoded data for command-line outputs that ran on the compromised host.

Decoding this data reveals the command that was executed on the compromised host and also exposes the list of documents and files on the machine that could have been stolen.

Filename: c_HOSTNAME_TIME_t. This file holds an encoded WMI script or script variables in the following form:

which turns out to be a readable WMI script when decoded:

Filename: d_rdown_HOSTNAME_TIME_t. This file is uploaded from the compromised host to the control server.

Filename: rdown_HOSTNAME_TIME_t. This file is downloaded from the control server to the compromised machine. It could contain post-exploitation tools to run on the host.

/tools:

The tools directory hosts several post-exploitation tools and malware to be downloaded from the control server to run on compromised machines. We found malicious DLLs, rootkits, encoded JavaScript malware, and cab files. One of the WMI scripts is an installer for other malware:

I have been able to track down the location of many of this campaign’s control servers, primarily in the United States and China. More than 60% of the servers were hosted in the United States and more than 20% were hosted in China.

Attackers are continuously on the lookout for social engineering opportunities. Influencing targeted users to open malicious documents following national events is one the most effective and effortless ways of performing these espionage attacks. Users need to exercise extreme caution when opening documents from unknown sources and use patched software.

I would like to thank my fellow researcher Brad Arndt for assistance in researching and tracking this campaign.

Analyzing 2014-0282 Internet Explorer CInput Use-after-Free Vulnerability..!!

Sometime during the mid of the last year, Proof-of-Concept code for the Use-after-Free vulnerability was published on the exploit-db effecting Internet Explore 8, 9 and 10. I was kind of interested in picking up this exploit code and debug to see the inner workings of the exploit and checkout how it looks like in the debugger. Another motive of debugging this exploit was to spend some cycles to do the precision heap spray technique to control the placement of the shellcode on the heap address of our choosing. 

Let's start by taking a quick look at the published exploit code on exploit-db and walk through it to gain some basic understanding of what should we expect, when we execute this code inside the debugger.

In the above PoC code,  a form with the id "testfm" is created following which 2  "TextArea" and 2 "Input" elements and are created. If we notice the changer( ) function in the PoC code, it frees up the contents of the form where the "TextArea" objects are also freed up.  In the last portion of the script, element "child2" is being set to true and changer ( ) function is set to be called on the property change event of child2 element.

If you look at the code closely, in the last part, reset( ) function is called  and iterated over the form element, which actually calls the CFormElement::DoReset ( ) function. This function will basically iterate over the each of the 4 elements of the form and resets its properties, In the iteration where the "child2" element properties is reset, changer( ) function is called and the form properties is reset which will also free the "child3" element properties. Eventually, in the last iteration, it will try to reset the properties of "child3" element and since the object is already freed, Reset( ) function call on that element will crash.

Let's try to execute this code in the debugger and see if we encounter the crash in IE 8.

As expected, IE crashes in the debugger, if we checkout the state of the IE in the debugger we can apparently see that Instruction pointer ( EIP )  is pointing to the invalid memory and consequently it is crashing at that point since it is not able to disassemble the code.

Next step is to check the call stack and see if we can dig out some more details on the crash.

Highlighted portion in the above call stack apparently shows that IE crashed while executing CFormElement::DoReset( ) function. If we disassemble at the Return Address 0x665a1742, it would look following.

Seemingly, we can see that crash happened while calling the virtual method. ESI was pointing to the object memory in the heap. In the first "mov" instruction the Virtual Function table pointer was moved to EAX after which IE was attempting to call the virtual method at the offset 1CC into the virtual function table during which it crashed since code cannot be disassembled at that memory address. This is the classic case of Use-After-Free vulnerability where the object was freed previously and ESI register was pointing to the freed memory which was 0x60 ( 96 ) bytes in size . We can confirm it from the below debugger screenshot.

To further validate our observation,  we can enable the page heap and user stack trace and see if it crashes again at the "call" instruction. Page heap will enable us to track all the heap allocations, chunk sizes and also track the freed up memory. Let's enable the page heap using gflags.exe and re-run the exploit to check if it crashes again at the same point.

Below is what I hit after enabling the page heap.

This is exactly what we expected. Apparently, IE8 crashed again at the "call" instruction while attempting to execute the virtual function method. Ggflags.exe keeps track of all the freed heap chunks and fills it up by 0xf0f0f0f0 which is used in the following call instruction to access the offset 1CC into the VFtable and then crashes. Disassembly at the crash location is following:

Following shows where the ESI and VFTable pointer was pointing to when the call was executed.

Page heap will also allow us to visualize when the heap memory was freed and what was the size of the freed heap chunk. Take a look at this below screenshot especially the highlighted portion. This validates our conclusion.

Another way to figure out the size of the freed object is to disassemble the mshtml.dll. There would be a constructor allocating the memory using HeapAlloc( ) and we can check the size of the allocated chunk as shown below.

Next, If we can craft the exploit code in such a way that we make IE to reallocate the same freed memory with our controlled data, then essentially it would mean that we will be able to control the "Call" destination which consequently will lead to remote code execution. With our previous analysis, we already have the information on what should be the size of the heap memory that needs to be allocated. We can force Internet Explorer to re-allocate the same memory if we create the fake object of the same size ( 0x60 bytes ).

Before diving further, let's first briefly understand the concept of Low Fragmentation Heap ( LFH ) used for servicing the memory allocation requests in windows and Virtual Function method calls.

Low Fragmentation Heap

In Windows, when an application would request for certain size of the memory chunk, heap allocator will dynamically allocate the memory from the process heap and hand it over to the application for use. Later if the application no longer requires that chunk, it can free the allocated memory, after which the freed memory is tracked by the front-end cache manager. Since the application can request and free the memory as and when required, consequently the heap can be fragmented which is not the ideal condition. In order to minimize the heap fragmentation, cache manager will track the list of freed chunks and will allocate from the that list if possible.

Low Fragmentation Heap in Windows is basically a heap allocation policy where, given the certain amount of memory allocation request of size X, it will try to allocate the memory of that same size contiguously. Now, there are multiple things coming out here in favour of the attacker.

• If the allocator is requested memory of size X, which it already finds in its free list of chunks, it would try to re-allocate the same memory chunk to the requesting application. This implies that if application frees certain chunk of memory and requests the same size of memory again, there is a high possibility that application will get the same memory chunk freed previously. 
• Additionally, this sort of allocation behavior will also make the heap allocations predictable. This essentially means that, if certain threshold number of allocations of size X is given to the heap allocator, all of these blocks will be allocated together and we are almost certain that attacker can place his controlled data to the heap address that he likes. For eg. 0x0c0c0c0c.

Virtual Function method calls

In Object Oriented world, parent or a base class can supply the methods which can be overridden by the child or derived class in its definition. Until run time, compiler would not know if the method of the base class or the derived class is required to be called. To make this much simpler, objects would typically have first 4 bytes as the pointer to the Virtual Function table which is a pointer to the array of function pointers. Visualize the object's memory and virtual functions as below. 

In our analysis so far, We've seen that we are getting the crash while calling the virtual function at address EAX+1CC, where EAX holds the pointer to the VFtable. Our idea is, if we can control the call to this destination by:

• Creating the enough fake object allocations of the same size, thereby forcing the IE to re-allocate the same previously freed memory. 
• Create the fake virtual function table by allocating the large amount of heap memory with another object, thereby placing our controlled data [which will usually be the ROP gadgets], at the predictable address [ for Eg. 0x0c0c0c0c. I am just using this address as an example. We can use any other heap address like 0x0a0a0a0a, 0x0b0b0b0b etc. ].

If we can achieve both of these above mentioned conditions, we can do the arbitrary code execution. Now let's slightly modify the exploit code to see if we can achieve the first condition. We'll modify the changer( ) function in the exploit to perform good amount of fake object allocations and see that IE re-allocates the previously freed memory thereby corrupting the object's VPTR. In the below modified exploit code, we would attempt to overwrite the object's VPTR by 0x41414141, subsequently, the crash will happen while calling virtual method at address 0x41414141 + 0x1cc, which equals 0x4141430D.

Apparently, we created 0x1000 "img" elements and set the image's title to the 0x60 bytes ( including  4 bytes of length and 2 bytes of null character. We need to use the unescape( ) here, else the string will be Unicode in the memory. If we re-launch IE with this exploit, we get the crash while calling the code at below address as expected.

This validates our claim and we've made IE to reallocate the previously freed memory and EAX holds the pointer to our fake virtual function table, which so far doesn't exist. Also, we are now certain that, we can corrupt the object VPTR and set it to something useful which we can control.

Precision Heap Spraying

Precision Heap Spray relates to our second condition that we want to achieve. Essentially,  we need to fill up good amount of heap memory with attacker controlled data, which includes the ROP gadgets + Shellcode that needs to be executed. ROP gadgets will mark the area of the memory where the shellcode resides, as executable, bypassing DEP, and finally will execute it. One of the primary thing that needs to be done here is to allocate the heap with precision, such that our ROP chain will start exactly from the address 0x0C0C0C0C [given that we wish to control the data placed at that address].

Given above conditions, we will have to overwrite the object's VPTR with the 0x0C0C0A40. Our exploit plan will finally look like the below diagram.

Next, with the below basic heap spray script, we'll examine the allocations in Windbg and subsequently optimze the script to place our controlled data at the target address.

Looking this under Windbg, our allocations will come out to be like below. Apparently, the heap spray that we executed accounted for 98.8% of the memory which is a good indicator. Also check the size ( 0xfffe0 ) which confirms that it is the result of what we executed.

It is important to check in which heap chunk the target address is located, and turns out that it is in the chunk 0x0C090018 [ address might differ on other systems ]

Also, note below that data we want to place at the target address [ deaddead ] is not there at the moment.

Now, here is our mathematics to achieve the precise heap spray such that, our controlled data "deaddead" will be certainly placed at our target address 0x0C0C0C0C.

• Subtracting the heap entry address from the target address gives us the total distance from the heap entry to our controlled data. 0x0C0C0C0C - 0C090018 = 30BF4 . We need to determine the offset into this heap chunk, such that when we add 0x1000 to the heap entry and subtract the resulting address from 0x0C0C0C0C, then value is less than 0x1000 [ i.e 4096 ]. With the little bit of experimentation, that heap address comes out to be 0x0C0C0018.
• Subtracting 0x0C0C0018 from our target address 0x0C0C0C0C = BF4.  If we divide this by 2 and then again subtract 6 from the resulting value, i.e ( BF4 / 2 ) - 6 , for BSTR header of 4 bytes and null characters of 2 bytes we have value 5F4 
• Now if we insert the padding of this size , we can align our shellcode exactly to the target address.

We'll have to modify the above basic heap spray script such that the data we'd like to place "deaddead" is at the target address. I will leave this as a exercise to the reader. If you do this correctly, it should look like below:

This validates our claim that with the careful crafting of the exploit, attacker can place the shellcode at the address of his choosing and eventually control the program execution. Finally, go ahead and embed the heap spray function into our main exploit POC code and we should see the Instruction Pointer register ( EIP ) overwritten with the dword "0x64616564".

Attacker can craft the exploit to place the Stack Pivot ROP gadget here which will pivot the ESP to the heap and start executing the ROP chain, subsequently bypassing Data Exexution Prevention and executing arbitrary code.

GAME OVER. !!.