A Taste Of Reality

Recently, there was a vulnerability (CVE-2014-6332) disclosed in OLE component of Windows Operating System which could be used to exploit Browser Applications like MSIE. The vulnerability in OLE SafeArray Resizing allows one to do arbitrary read/write in the memory address space of the process. While this vulnerability alone cannot be used to exploit an application and gain code execution. It gets even more interesting when combined with the IE SafeMode bypass.

Often referred to as "God Mode", this technique was first documented by yuange (https://twitter.com/yuange75). He explained how one could execute any system code using only VBScript embedded in an HTML page. To be more specific, the SafeMode setting in Internet Explorer prevents system code to be run using VBScript. So if an attacker can disable the SafeMode setting in Internet Explorer, they will directly get remote code execution on the machine.

To see this in more detail, let us attach windbg with Internet Explorer. We would also need to load a web page in Internet Explorer which would trigger it to load vbscript.dll. So, we use the below code snippet as an example:



This HTML page will attempt to execute calc.exe on the machine using only VBScript. However, MSIE SafeMode would prevent this.

I will use Win XP SP3 and MSIE 6 to check the SafeMode settings in VBScript. After attaching MSIE with windbg, we see that vbscript.dll is not loaded by default. So, let us set a breakpoint on module load for vbscript.dll.

0:000> sxe ld vbscript.dll

Now, run MSIE with windbg attached.

Load the above HTML page. We now break into the debugger. Let us view the assembly code specific to the function: COleScript::InSafeMode

The disassembly is as shown below:

0:000> u vbscript!COleScript::InSafeMode
vbscript!COleScript::InSafeMode:
7330624b 8b8174010000    mov     eax,dword ptr [ecx+174h]
73306251 83e00b          and     eax,0Bh
73306254 f6d8            neg     al
73306256 1bc0            sbb     eax,eax
73306258 f7d8            neg     eax
7330625a c3              ret
7330625b 90              nop
vbscript!DexCaller::`vftable':
7330625c a84c            test    al,4Ch

Let us set a breakpoint at InSafeMode() function and run the application:

0:000> bp 7330624b

0:000> g
Breakpoint 0 hit
eax=7755620d ebx=00000000 ecx=0003be90 edx=7c97b178 esi=0003ab80 edi=00000000
eip=7330624b esp=0013e1cc ebp=0013e254 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
vbscript!COleScript::InSafeMode:
7330624b 8b8174010000    mov     eax,dword ptr [ecx+174h] ds:0023:0003c004=0000000e

We now hit the breakpoint.

The value at address referenced by ecx+0x174 is 0xe

It has been documented already on Internet that the default value of SafeMode flag is 0xe. To disable the safe mode, we need to set this value to 0x0

Let us modify the value at address: 0x0003c004 in memory. We can run the following windbg command for that:

0:000> ed 0003c004 0;g
Breakpoint 0 hit
eax=00000001 ebx=00000000 ecx=0003be90 edx=0013e180 esi=00000000 edi=00000000
eip=7330624b esp=0013e1cc ebp=0013e254 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
vbscript!COleScript::InSafeMode:
7330624b 8b8174010000    mov     eax,dword ptr [ecx+174h] ds:0023:0003c004=00000000

Now, let us run the application and we can see that calculator was started successfully.

However, in this case, we have manually modified the value of SafeMode flag by editing the memory address, 0x0003c004 (@ecx+0x174). In real world, the attacker would need to use another vulnerability which would allow arbitrary memory read/write that can modify the SafeMode flag.

Also, this SafeMode bypass technique can be reused in other exploits as well. Since now an arbitrary memory read/write would directly result in code execution on the machine, these type of MSIE vulnerabilities will become more common in near future.

c0d3inj3cT

I wanted to write about debugging Windows 64-bit executables. Olly Debugger is the most commonly used user mode debugger for 32-bit Windows Binaries. However, the 64-bit version of Olly Debugger is not yet developed and available. You could either use IDA Pro to perform static analysis of 64-bit Windows Binaries or use the Debugging Tools provided by Windows (windbg). However, the interface provided by Olly Debugger is much more convenient to use.

Fortunately, now we have a debugger which supports 64-bit Windows Binaries as well. It is called x64_dbg and is available for download at http://sourceforge.net/projects/x64dbg/

The official site of the debugger is: http://x64dbg.com and the project is maintained at bitbucket.org

The interface provided by this debugger is similar to Olly Debugger which is great. It has support for plugins similar to Olly Debugger as well.

There is a good description of the components (for instance, Debugging Core engine, Disassembler Engine) used to develop x64_dbg here: http://x64dbg.com/#credits

Now, let us use x64_dbg to debug a binary and understand how the arguments are passed to a function in 64-bit Binaries. We know that in 32-bit Windows Binaries, the arguments are passed through the stack.

Let us consider a function called sum() which takes 4 arguments as an input and calculates the sum of these numbers. For a 32-bit binary, the arguments would be passed on the stack as shown below:

The C program which implements the sum() function:



And the corresponding disassembly:

push d
push c
push b
push a
call sum
mov ebx, eax

Inside the function sum, the arguments would be accessed as shown below:

push ebp
mov ebp, esp
sub esp,
mov eax, dword ptr ds:[ebp+0x8]
mov ebx, dword ptr ds:[ebp+0xc]
mov ecx, dword ptr ds:[ebp+0x10]
mov edx, dword ptr ds:[ebp+0x14]

As you can see above, the function, sum accesses the arguments from the stack using ebp (function prolog will set ebp to esp). Both the local variables and the arguments are referenced using ebp.

Now, let us consider the same function in a 64-bit binary and see how the arguments are passed to the function as shown below.

First, we locate the main subroutine. You can locate the main subroutine similar to the way we locate it for 32-bit Windows Binaries. Below we can see the call to main() subroutine with the two arguments, argc and argv passed to it.


Inside the main subroutine, let us look at how the parameters are passed to the function, sum() and how they are accessed within the function.




As you can see, the 4 arguments are passed to the function sum using the registers, rcx, rdx, r8 and r9. There is still a similarity with the calling convention used in 32-bit Windows Binaries and that is, the return value will be present in the rax register.

Now, let us look at the disassembly of function, sum():


Here, we can see that the 4 arguments are accessed from the registers and saved on the stack before the space for local variables is created on the stack.

So, now we know how the arguments are passed in the 64-bit Windows Calling convention and this will be helpful while reversing 64-bit windows binaries. Please note that there is a similar calling convention used for 64-bit binaries on Linux as well.

In some security sandboxes, the injected DLL will apply Deep API hooks in user mode. Deep API hooking refers to hooks applied at lower level (closer to the user mode to kernel mode transition).

For instance, Sleep() and SleepEx() APIs are imported from kernel32.dll

These APIs will in turn call ZwDelayExecution which is imported from ntdll.dll

If we apply a hook at ZwDelayExecution, then we do not necessarily need to apply an API hook at the wrapper APIs like Sleep() and SleepEx().

Also, in some cases, viruses could bypass trivial wrapper API hooks by calling the native API imported from ntdll.dll

Let us have a look at a native API like ZwDelayExecution on Win XP SP3:





0x7fff000 = address of KUSER_SHARED_DATA structure
At offset, 0x300 in the KUSER_SHARED_DATA structure, we have the pointer to SystemCallStub

Now, the first instruction in the above Native API is of size 0x5 bytes. Since we require 0x5 bytes for an inline API hook, we can easily place our API hook there.

Let us look at ZwDelayExecution on Win 7 64-bit



As we can see, size of the first instruction is 0x3 bytes and the second instruction is 0x5 bytes. As a result of this, it is not trivial to place an inline hook for the native APIs on Win 7 64-bit in user mode.

This would also mean, that most security sandboxes would apply API hooks at wrapper APIs like Sleep() or SleepEx() imported from kernelbase.dll. This makes it easier to detect and bypass API hooks on Windows 7 64-bit.

c0d3inj3cT

On Windows 7 (32-bit and 64-bit), a new module called Kernelbase.dll was added. What is the purpose of it?

If we check the APIs exported by kernel32.dll, we can see an API redirection performed by the Operating System.

Calls to APIs imported from kernel32.dll are redirected to kernelbase.dll

Let us have a look at it in a debugger (windbg).

Open a new process (notepad.exe) and attach windbg to it:

Below is the default list of loaded modules for notepad.exe


We can see an extra module called kernelbase.dll loaded along with notepad.exe

Let us check the API prolog of a function imported from kernel32.dll. For instance, Sleep() is a function imported from kernel32.dll


We can see that the first instruction at the API prolog of Sleep() is a jmp instruction followed by a sequence of nop instructions.

jmp     qword ptr [kernel32!_imp_Sleep (00000000`7745d7a0)]

This will redirect the control flow to kernelbase.dll as shown below:


This will in turn redirect the control flow to SleepEx in kernelbase.dll

Why do we need to know this?

In most of the security sandboxes which are used to analyze viruses, they inject DLLs into the process being analyzed. The injected DLL is used to perform API hooking in order to log the activities performed by the virus. It is common for sandboxes to place inline hooks for APIs imported from kernel32.dll. However, as we can see above, in case of Windows 7 (32-bit and 64-bit), it is better to place an API hook directly at kernelbase.dll

c0d3inj3cT

Found an RDP bruteforcer in the wild.

MD5 hash: e5855ed7b278e0bcf877d89c84b909ac

Obtained the binary from this URL: http://217.12.219.181/test/w.exe

Callback URL: http://78.154.54.42/www/cmd.php

Sends an HTTP POST request to it. Each time it connects to the above URL, it receives a new set of Server IP addresses to bruteforce along with the usernames and passwords.


Below you can see the multiple attempts to connect to the IP addresses on port 3389:


After sending an initial HTTP POST Request to the callback server, it will download a new binary:


URL of Binary: http://78.154.54.42/www/bin/1.exe?1680638915

This downloaded binary will replace the initially dropped, winlogon.exe file in the %appdata% folder with win!ogon.exe.

Below is the list of usernames and passwords used by it to perform the RDP bruteforcing:

logins:

pos
pos1
pos01
admin
administrator
micros
microssvc
client
client1
shop
station01

passwords:

admin
pos
pos1
pos01
password
Password
Password1
client1
administrator
micros
microssvc
shop
client
station
123456

Some of the subnets which this bruteforcer targets are:

71.221.6.0/24
68.223.28.0/24
68.223.29.12/24
24.223.48.0/24
24.224.49.0/24
54.223.70.0/24
54.223.71.0/24
68.31.92.0/24
68.31.93.0/24
24.223.114.0/24
24.223.115.0/24
50.223.136.0/24
68.31.156.0/24
68.31.157.0/24
50.223.177.0/24
68.223.199.0/24
68.223.200.0/24

Data is exchanged between the virus and the callback server over a plaintext communication channel.

Login Panel on the callback server:

http://78.154.54.42/www/



c0d3inj3cT

Today I found a virus which makes use of TLS callbacks. This technique has been known for quite sometime however it is not common to find it being used in malwares. In the recent past, we saw Win32/Napolar/Solarbot making use of it. Here are the details of the virus I discovered:

MD5 hash: 2015a6e37b951358cb5475de9a591444
Being circulated on the following URLs:

http://noobgirls.com/pussy.exe
http://noobgirls.com/pussy.php

TLS Directory of the binary shows the AddressOfCallbacks:


We can debug this binary using Olly Debugger. The version 2 of Olly has an option that allows you to break at the TLS Callback routine if they are present.


We break at the entry point of the first TLS callback. I have highlighted the AddressOfCallbacks array in the memory dump. We have only one TLS callback routine.


This binary also makes use of a lot of junk instructions. Since in the x86 instruction set, it is possible to synthesize NOP instructions in multiple ways, this binary makes use of a long sequence of such instructions between relevant code sections. This is done to deter reverse engineering.


Here is another example of the usage of junk instructions in a loop. The only relevant instruction executed is to save the ImageBaseAddress of the binary. The other instructions are inserted to increase the size of code section.


All the function names and module names are stored encrypted in the binary. Below is the decryption routine:


Once again you can see the usage of junk instructions in the decryption routine.

It makes use of undocumented functions like RtlRegisterSecureMemoryCacheCallback()

After executing the first TLS callback routine, it will attempt to execute the second TLS callback routine however since the address is set to 0x1 in the AddressOfCallbacks array, it will result in an exception.

We can set a breakpoint at the OEP of the binary (AddressOfEntryPoint in the PE Header) as shown below:

Once we pass the exception in the debugger, we break at the OEP of the binary.

We can continue debugging from here.


At present this binary is detected as malicious only by few AV engines on VT:

https://www.virustotal.com/en/file/38df495f694472029026d10296dc9e40608d638ca17bdbda7d3dd132b9b73007/analysis/

Disk activities performed by it are common:

1. Makes a copy of itself in the path: C:\Documents and Settings\Administrator\Application Data\\
2. Deletes itself from the original location.
3. Creates a new folder, "Address Book" in the directory: C:\Documents and Settings\Administrator\Application Data\Microsoft\ and drops the file, Administrator.wab in it.
 4. Makes itself persistent by adding the path to replicated file in the Registry key: HKU\\Software\Microsoft\Windows\CurrentVersion\Run\

Network Communication:

It communicates with the callback IP addresses over UDP on different destination ports. All the data exchanged is encrypted:

121.6.46.119:5693
66.131.90.144:5646
58.1.157.12:4195
107.221.229.216:6240
125.4.34.229:6705
121.117.209.51:2500
81.149.16.130:4344
72.204.26.84:5783
71.2.148.162:8650
184.3.61.57:8477
60.244.81.6:6006

As can you see, both the destination IP addresses and port numbers are random. Makes it more difficult to detect the network callbacks and uniquely identify this traffic.

c0d3inj3cT

Today I saw the usage of MMX instructions in the decryption routine of a self modifying code as shown below:



MOV EDI,DWORD PTR SS:[ESP]
MOV ESI,6581DBCA
MOV EAX,704
MOV ECX,DDDDFDDD        ; set ECX to a large value
IMUL EBX,EBX,21
XOR EDX,EDX
TEST EBX,EBX
ADD EBX,3
SUB EBX,1
MOV EBX,1                ; junk instructions
LOOPDNE SHORT 0014DB72    ; loop used to introduce delay in execution
SUB EAX,4
MOVD MM0,DWORD PTR DS:[EDI]    ; usage of MMX registers
MOVD MM1,ESI
PXOR MM0,MM1                ; MMX XOR instruction used
MOVD DWORD PTR DS:[EDI],MM0
ADD EDI,4
TEST EAX,EAX
JNZ SHORT 0014DB86
RETN

The reason for using MMX XOR instructions instead of the general x86 XOR instructions might be to bypass code emulation. It is a known method to make use of undocumented instructions in the code to defeat the code emulators. I am not sure if the MMX instructions are implemented in the code emulators.

In the self modified code, it uses common anti debugging tricks by checking the BeingDebugged and NtGlobalFlags fields in PEB.

After this, it executes the CPUID instruction with eax set to 1 (CPUID_GETFEATURES) and checks the value of the bit, CPUID_FEAT_EDX_MMX. This check is done to see if the CPU supports MMX instructions.



Below is another code section where it is using MMX registers in a delay execution routine:



MOV ECX,0D55ABBF    ; set ECX to a large value
NOP
XOR EAX,EAX
XOR EDX,EDX
RDTSC
NOP
MOVD MM1,EAX
MOVD MM0,EDX
LOOPD SHORT 0014D4ED
CMP ECX,0
JNZ 0014DB53
EMMS
JMP 0014D9BA

It is good to the see usage of MMX instructions in a malware. We will most likely see the usage of more FPU/MMX instructions in the malwares.

Since most security vendors these days make use of a sandbox to run the malware, such instructions can be used to defeat the emulators.

c0d3inj3cT