CVE 2013 3918 - Another zero day?

Another HTML exploit has surfaced and made a scene on the AV industry this November 2013. An exploit that takes advantage of the vulnerability of an ActiveX component of Internet Explorer which allows code execution when a user views a specially crafted webpage. Details on the vulnerability can be found on this Microsoft website.

ThreatTrack's Vipre 2013 detects this as Lookslike.HTML.CVE-2013-3918.a

The exploit uses a technique known as ROP (return-oriented-programming) that allows itself to run in non-executable memory areas. Once successfully exploited, it will intentionally exchange the address of the stack and heap and change the memory protection so that it can execute its shellcode. 

ROP in action

In order to for it to execute, it changes the memory protection of the said area using VirtualProtect.

Changes protection level of memory

Once everything is in order, it will pass execution to the part of its shellcode that decrypts and computes for the API's needed to inject itself to another process.

• LoadLibraryA
• Winexec
• CreateThread
• OpenProcess
• CreateProcessA
• VirtualAllocEx
• WriteProcessMemory
• CreateRemoteThread

 

It uses the said APIs to create a process named "rundll32" under Internet Explorer, writes another section of its shellcode and activates the process using CreateRemoteThread API. It's interesting to note that it covers itself with multiple layers of encryption and employs multiple jumps in memory to avoid easy detection.

An example of decrypting code

Decryption in rundll32

Another interesting feature of this payload is in the way it calls for the APIs it needs. It initially sets up a jump table that points to single function that performs the call (specifically a jmp) varying only  in the values it pushes. It is highly possible that it enforces this type of calling method in order to prevent researchers to easily identify the calls it uses and to quickly analyze the contents of its body.

Jump table for calling API

While its previous characteristics are trivial, the main purpose of this payload is to connect to a remote server that can be used or is being used for targeted attacks. It connects and listens to a remote IP address 111.68.9.93

Connects to a remote server

Read More

CIDOX Bootkit

There has been a growth of the use of bootkit in recent years and it has been an annoyance and a source of frustration of many computer users today. A bootkit, strictly speaking, refers to a set of programs that loads itself before the operating system does. It provides flexible means to hide its activities or modify key components that are not accessible normally. By modifying the initial boot loader of the hard drive it can bypass detection from most traditional AV vendors and perform kernel level operations not normally available on user level programs. Because of these, bootkits are generally hard to remove as they require extensive study as to how to restore the original MBR or partition.

Such is the case of Cidox.

This malware initially arrives as a single downloaded executable file, whether via drive-by-download, exploits or any other possible means. It carries within itself vital components to successfully infiltrate and compromise the system. Excluding the dropper, its tools are the boot loader (bootkit), the rootkit drivers (w32/w64), shutdown file and the attribute modifier.

 Cidox in the middle

The main purpose of this malware is to intercept, modify and gather information on the search requests made by the unsuspecting user. By modifying the volume boot record of an NTFS drive, it utilizes its rootkit, loads and sets up a library that monitors specific browsers and redirects their queries on a remote location. It has the capability to modify a webpage seen by users on their browsers. It has also been reported that it uses the said technique to hold the system ransom, and trick the user into believing that they need to pay a monetary amount to remove an infection on their system.

Browsers monitored by Cidox

The following section describes in technical detail what each Cidox component does.

DROPPER

Upon execution, it will perform the following actions to install the components in the said order

• Check for windows version
• Copy the w32 or w64 version of rootkit in memory
• Write it directly on hard drive
• Modify the boot loader of the hard drive to load the written rootkit
• Create and execute a small file to force restart the system
• Modify attributes and delete self

Overview of dropper

This executable employs anti-debugging tricks to avoid being emulated and analyzed. For one, it uses the classic large, almost infinite loop which does nothing. This is because most emulators avoid loop due to engine performance issues. In conjunction with the previous trick, it uses the GetTickCount API to know if it is being debugged and if so, will modify the first few bytes of its main function so that execution will not continue. This can be easily defeated by bypassing the code or modifying the registers.

Overwriting of function if it assumes it is being debugged

Instead of directly decrypting parts of itself, the dropper allocates memory multiple times, decrypts and uses those portion in memory to transfer execution. It is obvious that it uses this jumping technique to avoid third party programs to easily dump Cidox in memory.

Passing of execution

Cidox carries 2 versions of rootkit drivers within itself. It chooses either one of these depending on the version of windows of the infected system. It will perform some checks and verify whether it is 32bit or 64bit platform. It then saves the result in a memory location, and "drops" the file by writing it directly to the free sector of the hard disk.

Rootkit driver written to a free sector

At this point, it will prepare to write directly to the hard disk by mounting it. Saves the original volume boot partition to a random sector in the first disk, then write the malicious boot loader directly to it.

Uses ZwCreateFile to mount and read/write directly to hard disk

Finally, it will create and execute a small file with the specific purpose of forcing a restart on the system. Immediately proceeding after this is the creation of a batch file for changing attributes and deleting the small shutdown file.

BOOT LOADER

Cidox modifies the sector containing the active volume boot record of an NTFS partition in order to properly load its root kit. Once the malicious boot code is executed, it reads the malicious rootkit driver file in the disk, transfers execution to it and resumes normal boot operation.

Clean and infected copy of w32 infected partition

The original program loader is encrypted at the end of the malicious boot loader. After loading the malicious rootkit driver, the original loader will be decrypted and Cidox will pass execution to it to resume normal boot operations. Below is a copy of the malicious program loader and the highlighted hex bytes are the encrypted original loader.

Highlighted is the encrypted loader

ROOTKIT

Cidox rootkit driver employs its hooks by installing the following hook callbacks

 

• PsSetLoadImageNotifyRoutine
• PsSetCreateProcessNotifyRoutine

Driver loaded in memory

These functions are called whenever an image is loaded or a process is created, respectively. The handlers for the hooks checks to see if it is called in any of the process stated below.

• iexplore.exe
• firefox.exe
• chrome.exe
• safari.exe
• opera.exe
• maxthon.exe

The said process names are names of common internet browsers used by many computer users. Once all the conditions are verified, the rootkit will load a special DLL in memory which installs additional hooks and is the one responsible for intercepting messages. 

Hooks the following ws2_32 functions

• recv
• send
• wsasend
• wsarecv
• closesocket
• wsasocketw
• connect
• wsaconnect
• select
• wsagetoverlappedresult
• wsaasyncselect
• ioctlsocket
• wsaenumnetworkevents
• wsaeventselect

 

Hooked Send ws2_32 function

Cidox gathers information on the target infected system, uses them to form a GET http operation, send the request and awaits result. It can be seen that it checks for existing AV engines installed (in program files directory), checks for VMware process running, the OS and versioning.

  

 Sample message formed by Cidox DLL

 Checks hash for common AV filenames in Program Directory

While the target processes are being monitored, Cidox alters web queries sent by the user and replaces with data coming from the following remote addresses

 

• 213.133.103.21x
• V1s.cx
• 1nfo.cx 

SHUTDOWN FILE

The shutdown file, as its name implies, is a small executable created and activated by the dropper. Its specific purpose: to forcefully shutdown the system. This will execute the malicious modified partition and thus load the rootkit driver.

 

ATTRIBUTE MODIFIER

A small batch file with a randomly generated name is created and called at the end part of the dropper file. Its purpose is to delete the dropper and delete itself to remove possible detection.

Read More