Elusive Thoughts: 15/04/2012

21/04/2012

Malware Analysis of MSFPayload

Intro

Nowadays the only people that can actually do a decent Mal-ware analysis are ONLY antivirus research vendors such as Symantec and McAfee. The only thing a Security administrator or an Information Security Consultant can do is Mal-ware behavior analysis. That it is the initial stage of lets say a high profile Mal-ware analysis, but that might not be enough. There are no more than 1000 human beings in this planet that can properly reverse engineer a worm such as Confliker and start writing disinfection tools from scratch (or maybe there are, who knows) or they cannot do it in a reasonable amount if time.

So the next best think from fully reverse engineering a Trojan horse is to do a behavioral analysis and try to confine or mitigate the malicious software. But to me it seems that it is not clear to many people on how to do that or what disinfection really means. For me disinfection means to completely identify how a virus behaves and use proprietary tools to restrain it in such a manner that is going to be no risk.

Lately I was doing some Mal-ware analysis on behalf of a client and I decided to write a mini guide on how to perform a disinfection strartegy. So for the purposes of this article I am going to do a Mal-ware analysis of an MSFPayload executable, why? Because is free, open source point and "single point and click" hacking tool. As already demonstrated in a previous article found here someone can embed a MSFPayload in practically any executable by using free Windows tools that come with default windows installations. So what are the techniques of Mal-ware is using?

Occupy Memory Residency

Memory-resident programs are those that can be placed in, and remain in, an affected system's main memory space after execution. Memory residency enables a piece of malware to be readily available whenever needed, ensuring that the malware is easily accessible or can monitor every event on an affected system. This is a malware's way of controlling every activity on an affected system when a condition is satisfied. To find out if a malware is resident in the memory, you may need to invoke system tools like the Task Manager in Windows NT-based systems. On Windows 95- or 98-based systems, you can press CTRL-ALT-DEL, which displays a window containing all the running processes in memory. Once you have full view of the things that are currently in memory, check if a malware is there or not. This is tricky and at the same time risky. Terminating a memory-resident program that is critical to a system may cause some undesirable results, such as displaying the Blue Screen of Death or even triggering the system to restart. It is advisable to check if a specific memory-resident program is indeed alien to the system, which is not an easy task.

Spoof Process Names

Contemporary malware tends to use process names that look strikingly similar to common process names. For example, WSOCK32.DLL, a common process in memory handling the library of socket functions, can be spoofed as WSOCK33.DLL. Another is KERNE132.dll (notice that the L in KERNEL is actually the number 1) can be mistaken for the real KERNEL32.DLL. Sometimes the names are actually valid but the path is different. The KERNEL32.DLL is always found in the \Windows\System32 directory but some malware puts it in \Windows\System (in the example displayed below you can see how MSFPayload is using mswinsoc.dll).

Alter Start Up locations

Other areas where AutoStart entries can be found are in the files, System.ini and Win.ini. A malware often modifies these with links to itself added to the "run=" or "load=" sections of the files. These files are located at the Windows Directory (typically C:\Windows). Following the same approach that you followed with the registry entries, you can remove them from the AutoStart entries after you have verified that they are malicious. Again, back up these files before making any modification just in case the entries are not malicious and you have to restore the files to their original form. All the necessary system configuration files can be accessed, viewed and edited with the Sysedit program. To invoke the program, click "Start", and then "Run", and then type "Sysedit" in the "Open:" box. Another place where you can find autostart entries are in the Start > (All) Programs > Startup folder. The entries here are also referenced and are executed immediately after system startup. Similarly, you may need to back up these files before tinkering with them. You can also have a look at msconfig wizard to see all services and programs executed from OS.

Malicious Macros

Applications like word processing, spreadsheets or PowerPoint presentations are often vulnerable to macro viruses. You can check for malicious activities by checking for macros within these files. To do this, access the macros organizer (you may refer to your applications help file) and check if there are any unknown macros inside, press the ALT-F11 keys in the more recent offerings of Microsoft Office Family (beginning in Office 97 and up). However, some macro viruses tend to hide themselves from users by changing the foreground/background of the macro font display or by adding multiple tabs to make the text invisible to the default view pane. The following is an explanation of procedures readers can use for two different applications that use macros: MS Word and Excel.

Infected MS Excel Documents

Search your hard drive for any folder name XLStart. For Excel, this folder contains all the things necessary for customization and this includes macros as well. You can transfer the contents of this folder to a temporary directory. Open Excel and turn on the Macro Virus Protection. After doing so, you can now open the Excel file that may be infected and then the Macro Virus Protection should be able to figure that out for you.

What Mal-ware is and how?

Once executed, Mal-ware can perform its intended malicious function on a system. Unfortunately, it may not always be apparent to users that their system is indeed infected. Mal-ware is an ordinary program doing things that should not be doing, nothing more nothing less. I am going to use the same payload I used to do the demo on a previous articles, yep the one called ClickMe.exe. So what happens if we generate an MSFPayload that spawns a Shell and then listens for a connection, what tools should someone use? Well I am using the following tools:

Process Monitor v3.01 (from SysInternals)
Fport v2.0 (from McAfee)
Wireshark v1.6.7 (former Ethereal)
OllyDbg v 2.0

So what I am going to do next is to double click ClickOnMe.exe and start analyzing how it behaves, using the tools reported above and looks for thinks such as what is it's memory space, what dll file does it use, what connections does it open.

Using Process Monitor for recording MSFPayload

So lets start with process monitor and try to record the behavior of the malicious file. What I am going to do is first launch the tool, double click on ClickOnMe.exe and then see what can we see from there. When you launch process monitor you can see that there is a filter button, so what I would do is to filter the process image name (we know it is ClickOneMe.exe)

Note: From the drop down list I checked Process Name and by inserting the process image name I filtered the desired executable. Something else someone cold do is to export the results into a CSV file, imported to an excel and do further analysis on how everything happened (time is also included).

Note: Se the XML format you can use, including all this valuable information such as stack trace and stack symbol resolution, and all that with a free tool, amazing ee?

The most interesting feature of this tool is the process activity tool that records all behavior of the process and timeline, just see below the features:

Note: Have a look at the registry activity, the tool is actually parting with the PC. It has totally 257 registry activities, amazing again. It also does some strange file I/O, later on we are going to have some further analysis on how to take advantage of this feature.

Note: This is one of the most interesting feature a process monitoring tool should have because if you click in the button save you can export all registry keys accessed from the process and then write a quick disinfection batch file e.g. deleting all created registry keys from the malicious process by using the command REG DELETE KeyName [/v ValueName | /ve | /va] [/f] from command prompt or what ever tool you use. You can also filter the registry keys associated with the Trojan based on access rights the Mal-ware has (e.g. read, write e.t.c) usually a Mal-ware is running on users permissions.

Another very cool feature of the tool is the file monitoring capability it has. Process Monitor can actually record all file accessed, modified and used by the Mal-ware while running, filtered per path, extension, and folder name:

Note: See the tool differentiating, how the Mal-ware treats WINDOWS, Prefetch and System32 system files. Metasploit has done a good job optimizing the behavior of MSFPayload utility. ClickOnMe.exe generates even a prefetch to optimize it behavior.

Prefetcher as MSFPayload Mal-ware accelerator

The Prefetcher is a component of versions of Microsoft Windows starting with Windows XP. It is a component of the Memory Manager that speeds up the Windows boot process, and shortens the amount of time it takes to start up programs. In Windows Vista, SuperFetch and ReadyBoost extend upon the prefetcher and attempt to accelerate application and boot launch times respectively by monitoring and adapting to usage patterns over periods of time and loading the majority of the files and data needed by them into memory so that they can be accessed very quickly when needed. When Mal-ware is using prefetch then it can optimize it's performance.

Suspicious dll files loaded by MSFPayload

One of the not so few dll files that our MSFPayload loads implies that network activity is happening from the Mal-ware. If you click to expand the plus sign in system32 you will see that mswsock.dll is used by the Mal-ware which means that an outbound connection was attempted. Winsock dll is a windows socket library. One of the many interesting function implemented in Winsock.dll is the gethostbyname which by the way is deprecated. The function mentioned tells us that our Trojan can do a DNS address resolution and sent probably personal data (of course we would have to be sure what function is used).

Suspicious files loaded by MSFPayload

Now if you check the AppPatch windows file system you will see that SysMain.sdb was used, which contains both matching information and compatibility fixes per application. It can be found in the %Windir%\AppPatch directory.

Using FPort for recording MSFPayload

Fport is used to identify unknown open ports and their associated applications. FPort supports Windows NT4, Windows 2000 and Windows XP, it reports all open TCP/IP and UDP ports and maps them to the owning application. This is the same information you would see using the 'netstat -an' command, but it also maps those ports to running processes with the PID, process name and path. Fport can be used to quickly identify unknown open ports and their associated applications. Someone could use FPort to take periodically snapshots from the system your are trying to disinfect and that way record all connections from a possibly malicious software (you can add a task scheduler). The output of FPort concerning the ClickOnMe.exe is:

FPort v2.0 - TCP/IP Process to Port Mapper
Copyright 2000 by Foundstone, Inc.

Pid   Process                Port Proto   Path
3268 ClickOnMe -> 2565 TCP   C:\Documents and Settings\jerry\trojan\ClickOnMe.exe
3268 ClickOnMe -> 9000 UDP   C:\Documents and Settings\jerry\trojan\ClickOnMe.exe

Note: See that the MSFPayload uses both TCP and UDP.

Using Wireshark for recording MSFPayload

Wireshark is the world's foremost network protocol analyzer. It lets you capture and interactively browse the traffic running on a computer network. It is the de facto (and often de jure) standard across many industries and educational institutions. Wireshark development thrives thanks to the contributions of networking experts across the globe. It is the continuation of a project that started in 1998.

We canuse Wireshark to record the MSFPayload and see how the payload looks like in the wire. When the ClickOnMe.exe tries to spawn a reverse shell to the attacker and then start listening for a connection (meaning it binds a shell to the desired port). So lets see what it does it. This is how start listening for all packets by selecting my network card (click to enlarge):

Note: This is how you start listening the net-card. Because tons of tutorials exist out there about Wireshark I am not going to waste more time on Wiresharking the MSFPayload.

Using OllyDebug for recording MSFPayload

OllyDbg is a 32-bit assembler level analyzing debugger for Microsoft Windows. Emphasis on binary code analysis makes it particularly useful in cases where source is unavailable. OllyDbg is a shareware, but you can download and use it for free.With OllyDbg you can analyze all sorts of Mal-ware and verify information that you collected from other software.

So what I would do is to launch MSFPayload and the attack the process and this is what you get:

Note: The process terminates immediately after it launches, but that is the stack footprint we get from OllyDebugger.

Further investigation with Olly Debugger will reveal all engaged dll used from the MSFPayload (click to enlarge):

Note: You can see that the screen shot from above verifies the result from process monitor, again it reveals that mswsock.dll is used so a data confidentiality issue is what you should be looking for.

Using Olly Debugger can help you extract valuable hidden text about what the executable might be doing. In this occasion we could actually see from some ASCII dumps that the Mal-ware is connecting to something:

Address   ASCII dump
0040D230 C:H:P:A:g:X:de:Sq   bgcolor=whit
0040D250 e   Total of %d requests complet
0040D270 ed
%s
..done
Finished %d requ
0040D290 ests
   apr_socket_connect()
0040D2B0
Test aborted after 10 failures

0040D2D0

Server timed out

apr_poll
0040D2F0      apr_sockaddr_info_get() for
0040D310 %s error creating request buffe
0040D330 r: out of memory
   INFO: %s hea
0040D350 der ==
---
%s
---
Request too
0040D370 long
   %s %s HTTP/1.0
%s%s%sCo
0040D390 ntent-length: %u
Content-type:
0040D3B0 %s
%s
    PUT POST    text/pla

Note: From the HTTP/1.0, PUT and POST keywords we can understand that the Mal-Ware is using Http to communicate with the attacker. We also know that Meterpreter payload is using http to communicate with the attacking machine. Show by going through these type of details we can find a lot of hidden information and make almost certain the connect back IP. We can even identify how many failed connection it will do until it stops trying to connect back to some IP.

The text shown below shows how it might be constructed our executable:

http://www.zeustech.net
0040E9C0 /<br>
   This is ApacheBench, Ve

Note: If we Google zeustech.net we will find that is a company with traffic manager appliances. Now if we Google ApacheBench (ab) we will find out that is a single-threaded command line computer program for measuring the performance of HTTP web servers. Originally designed to test the Apache HTTP Server, it is actually generic enough to test any web server.The ab tool comes bundled with the standard Apache source distribution, and like the Apache web server itself, is free, open source software and distributed under the terms of the Apache License.

Detecting Mal-ware through ApacheBench signature

Using the above information we can use industry antivirus software to build costume IPS and AV signatures:

Example Usage (taken from Wiki):

    ab -n 100 -c 10 http://www.something.com/

This will execute 100 HTTP GET requests, using 10 threads (10 requests per thread) to the specified URL, in this example, "http://www.yahoo.com". If someone goes to the relevant web page can actually find out about a the little details. So my assumption is that Metasploit is using Apache Bench some how to generate the shellcodes.There is a very interesting google-code project about Apache Bench you can find here.

Finally Removing The Mal-ware

OK we identified the Mal-ware, we found all the changes the Mal-ware did to our system now what? Well the question is relatively easy, you remove the virus. The process of doing that is pretty much easy. First you record all changes through the tools we described then you export the results in CVS format and import them into the excel you process the data e.g. identify new malicious registry keys, maliciously generated files e.t.c. After we do that we generate a Vb-script or a batch file performing the necessary actions to remove the virus. You can actually automate this process by writing an excel file that spits the desired Vb-script or use batch files using macros or you can simple use a bash script to do that by using various delicious tools. The Vb-script or a batch skeleton should consist of 4 sections:

[Section 1]

The Registry Key section (we do removing or deleting keys):

Registry keys to delete.
Registry keys to write.

[Section 2]

The File/Folder Section (we do removing or restoring files/folders):

Malicious files/folders to delete.
Malicious files/folders to restore.

[Section 3]

The Process Section (we do process killing):

Malicious process to kill (kill process with the desired process image name).
Malicious service to kill (kill service and make sure it does not restart).

[Section 4]

The Network Section (we do network activity killing):

Malicious Network activity to block ( e.g. Write costume signatures for host based IPS)
Malicious Network activity to record (e.g. Write costume signatures for host based IDS)

Further disinfection actions can be taken using other antivirus tools such as host integrity and software blocking tools. We can then distribute the appropriate Vb-script or batch file using Active Directory log-in scripts or other appropriate solutions such as software delivery tools.

Epilogue

I proved once more that with freeware tools you can do lots of interesting stuff and one of them is Mal-ware analysis.

References:

18/04/2012

Over The Flow (Part 2)

Intro

This post is the next part of my previous article called Over The Flow (Part 1). In this post I will reproduce the server crush and try to identify how to position the shellcode meaning identify the EIP register position using Olly Debugger v1.0. In the previous post I found out the server crushed when I inserted 126 end brackets (meaning this character }, translating to 7D in Hexadecimal) in the command LIST. So lets not lose any time. But before I do that I will explain some preliminaries first about the stack and the CPU registers.

A little about the assembly

x86 assembly language is a family of backward-compatible assembly languages, which provides some level of compatibility all the way back to the Intel 8008. x86. Assembly languages are used to produce object code for the x86 class of processors, which includes Intel's Core series and AMD's Phenom and Phenom II series. Like all assembly languages, it uses short mnemonics to represent the fundamental operations that the CPU in a computer can perform.

A little about the stack as a generic structure

In computer science, a stack is a last in, first out (LIFO) abstract data type and linear data structure. A stack can have any abstract data type as an element, but is characterized by two fundamental operations, called push and pop. The push operation adds a new item to the top of the stack, or initializes the stack if it is empty. If the stack is full and does not contain enough space to accept the given item, the stack is then considered to be in an overflow state. The pop operation removes an item from the top of the stack. A pop either reveals previously concealed items, or results in an empty stack, but if the stack is empty then it goes into underflow state (It means no items are present in stack to be removed).

Note: A simple representation of the stack.

A stack is a restricted data structure, because only a small number of operations are performed on it. The nature of the pop and push operations also means that stack elements have a natural order. Elements are removed from the stack in the reverse order to the order of their addition: therefore, the lower elements are those that have been on the stack the longest.

A little about the stack in Windows NT family

In Windows NT operating system family threads is a kernel build in feature, meaning that Windows cannot fork processes unlike Linux operating systems. That is why it is very common for a process to spawn threads to handle the assigned tasks. In Windows NT series a stack is allocated per thread and each thread will get by default a 4K stack allocated.

Note: As you can see threads share the same program code, data and files.

We should also note at this point that Windows executables are structured as defined in the PE-COFF standard.The Common Object File Format (COFF) is a specification of a format for executable, object code, and shared library computer files used on Unix systems. It was introduced in Unix System V, replaced the previously used a.out format, and formed the basis for extended specifications such as XCOFF and ECOFF, before being largely replaced by ELF, introduced with SVR4. COFF and its variants continue to be used on some Unix-like systems and on Microsoft Windows.

When a COFF file is generated, it is not usually known where in memory it will be loaded. The virtual address where the first byte of the file will be loaded is called image base address. The rest of the file is not necessarily loaded in a contiguous block, but in different sections. Relative Virtual Addresses (RVAs) are not to be confused with standard virtual addresses. A relative virtual address is the virtual address of an object from the file once it is loaded into memory, minus the base address of the file image. If the file were to be mapped literally from disk to memory, the RVA would be the same as that of the offset into the file, but this is actually quite unusual.

Note: that the RVA term is only used with objects in the image file. Once loaded into memory, the image base address is added, and ordinary VAs are used. So when we load our executable to the debugger we see a contiguous space of addresses allocated.

A little about CPU registers

In computer architecture, a processor register is a small amount of storage available as part of a CPU or other digital processor. Such registers are (typically) addressed by mechanisms other than main memory and can be accessed more quickly. Almost all computers, load-store architecture or not, load data from a larger memory into registers where it is used for arithmetic, manipulated, or tested, by some machine instruction. Manipulated data is then often stored back in main memory, either by the same instruction or a subsequent one. Modern processors use either static or dynamic RAM as main memory, the latter often being implicitly accessed via one or more cache levels. A common property of computer programs is locality of reference: the same values are often accessed repeatedly and frequently used values held in registers improves performance. This is what makes fast registers (and caches) meaningful.

Processor registers are normally at the top of the memory hierarchy, and provide the fastest way to access data. The term normally refers only to the group of registers that are directly encoded as part of an instruction, as defined by the instruction set. However, modern high performance CPUs often have duplicates of these "architectural registers" in order to improve performance via register renaming, allowing parallel and speculative execution. Modern x86 is perhaps the most well known example of this technique.

A little about general-Purpose CPU Registers

A register is a small amount of storage on the CPU and is the fastest method for a CPU to access data. In the x86 instruction set, a CPU uses eight general purpose registers: EAX, EDX, ECX, ESI, EDI, EBP, ESP, and EBX. More registers are available to the CPU. Each of the eight general-purpose registers is designed for a specific use, and each performs a function that enables the CPU to efficiently process instructions.

The EAX register, also called the accumulator register, is used for performing calculations as well as storing return values from function calls. Many optimized instructions in the x86 instruction set are designed to move data into and out of the EAX register and perform calculations on that data. Most basic operations like add, subtract, and compare are optimized to use the EAX register.

As previously noted, return values from function calls are stored in EAX. In addition, you can determine the actual value of what the function is returning. The EDX register is the data register. This register is basically an extension of the EAX register, and it assists in storing extra data for more complex calculations like multiplication and division. It can also be used for general purpose storage,but it is most commonly used in conjunction with calculations performed with the EAX register.

The ECX register, also called the count register, is used for looping operations. The repeated operations could be storing a string or counting numbers. An important point to understand is that ECX counts downward, not upward.

In x86 assembly, loops that process data rely on the ESI and EDI registers for efficient data manipulation. The ESI register is the source index for the data operation and holds the location of the input data stream. The EDI register points to the location where the result of a data operation is stored, or the destination index. An easy way to remember this is that ESI is used for reading and EDI is used for writing.

Using the source and destination index registers for data operation greatly improves the performance of the running program. The ESP and EBP registers are the stack pointer and the base pointer,respectively. These registers are used for managing function calls and stack operations.

When a function is called, the arguments to the function are pushed onto the stack and are followed by the return address. The ESP register points to the very top of the stack, and so it will point to the return address. The EBP register is used to point to the bottom of the call stack. In some circumstances a compiler may use optimizations to remove the EBP register as a stack frame pointer; in these cases the EBP register is freed up to be used like any other general-purpose register.

The EBX register is the only register that was not designed for anything specific. It can be used for extra storage. One extra register that should be mentioned is the EIP register. This register points to the current instruction that is being executed. As the CPU moves through the binary executing code, EIP is updated to reflect the location where the execution is occurring. A debugger must be able to easily read and modify the contents of these registers. Each operating system provides an interface for the debugger to interact with the CPU and retrieve or modify these values.

Note: This is the CPU register collection.

Below you can see the conceptual representation of the stack:

Note: This is how a loaded function looks when loaded in CPU.

Now when we attach the debugger to the IMAP4.exe executable we would see all registers occupied by the desired process. And by saying that I mean the Floating Point Unit (FPU, colloquially a math co-processor) of IMAP4 process. The following image shows an overview of the registers and stack of the assembly language:

Note: See the general purpose registers, along with the stack and base pointer.The stack is a very important structure to understand when developing a debugger. The stack stores information about how a function is called, the parameters it takes, and how it should return after it is finished executing. The stack is a First In, Last Out (FILO) structure, where arguments are pushed onto the stack for a function call and popped off the stack when the function is finished.

A little about debuggers

A debugger or debugging tool, a computer program that is used to test and debug other programs (the "target" program). The code to be examined might alternatively be running on an instruction set simulator (ISS), a technique that allows great power in its ability to halt when specific conditions are encountered but which will typically be somewhat slower than executing the code directly on the appropriate (or the same) processor.

A "crash" happens when the program cannot normally continue because of a programming bug. For example, the program might have tried to use an instruction not available on the current version of the CPU or attempted to access unavailable or protected memory. When the program "crashes" or reaches a preset condition, the debugger typically shows the location in the original code if it is a source-level debugger or symbolic debugger, commonly now seen in integrated development environments. If it is a low-level debugger or a machine-language debugger it shows the line in the disassembly (unless it also has online access to the original source code and can display the appropriate section of code from the assembly or compilation).

Attaching the IMAP4 process to our debugger

We will now attach our vulnerable program to Olly Debugger v1.0. There are subtle differences between opening a process and attaching to a process. The advantage of opening a process is that you have control of the process before it has a chance to run any code. This can be handy when analyzing Mal-ware or other types of malicious code. So the string that crashed the server had this format a001 LIST [ }*126 ] CRLF. Now I am going to run Olly Debugger v1.10 and attach the IMAP4 server to our debugger. We do File -> Attach and we get this picture:

Note: See that the debugger opens up a task like windows and show all running processes. We click the IMAP4.exe running to attach it.

Note: This is the part of the window that show the application registers (I know it is getting darker and darker). Take a look at the EIP register.Have a look at the FPU of our process you can see that the first register is EBX, second comes ECX, third EDX, forth ESI and last EDI. While EIP has a totally different address.

A little about the EIP register

The instruction pointer is called IP in 16-bit mode, EIP in 32-bit mode,, and RIP in 64-bit mode.The instruction pointer register points to the memory address which the processor will next attempt to execute the next program command.

What does EIP register contain and how to access it:

The EIP register always contains the address of the next instruction to be executed.
You cannot directly access or change the instruction pointer.
However, instructions that control program flow, such as calls, jumps, loops, and interrupts, automatically change the instruction pointer.

Mapping the EIP register

In order to map the position of the EIP register we would use two tools from the metasploit the patten_create.rb and the pattern_offset.rb. In order to use this tools you would have to go to C:\metasploit\msf3\tools (this path is for the metasploit installed in windows). then type patten_create.rb 1000 (we know that). The following screen shot shows how to use the tool:

The following window shows how the pattern_offset.rb works:

Note: This screen shots do not use the metasploit version (I made some modifications for my convenience).

So now I will use the pattern to locate the exact position of the EIP register, the following simple python script will do the job:

Note: See that the ESI register was overwritten, but what about the EIP address? (check out that the application paused but not terminated). The EIP address was not overwritten before the Shift+F9 which means that the operating system (OS) handled the buffer overflow. Well this happened because the OS through an exception using the Structured Exception Handling mechanism.

About Structured Exception Handling (SEH)

Microsoft supports SEH as a programming technique at compiler level only (It means that when you write the code you do not have to take into consideration exception handling, the compiler does everything for you, simplistically speaking of course!!!) this type of programs are called SafeSEH programs. More specifically SafeSEH is a security feature that protects the Structured Exception Handler from being corrupted or hijacked in the event of a buffer overflow. MS Visual C++ compiler features 3 non-standard keywords: __try, __except and __finally are for this purpose. Other exception handling aspects are backed up by a number of Win32 API functions, e.g. RaiseException to raise SEH exceptions manually.

An exception is an event that occurs during the execution of a program, and requires the execution of code outside the normal flow of control. There are two kinds of exceptions: hardware exceptions and software exceptions:

Hardware exceptions are initiated by the CPU. They can result from the execution of certain instruction sequences, such as division by zero or an attempt to access an invalid memory address.
Software exceptions are initiated explicitly by applications or the operating system. For example, the system can detect when an invalid parameter value is specified.

Structured exception handling is a mechanism for handling both hardware and software exceptions. Therefore, your code will handle hardware and software exceptions identically. Structured exception handling enables you to have complete control over the handling of exceptions and provides support for debuggers.

More specifically imagine when a thread faults, the operating system using SEH gives you an opportunity to be informed about the fault. When a thread faults, the operating system calls a user-defined callback function. This callback function can do pretty much whatever it wants. For instance, it might fix whatever caused the fault, or it might help you exploit the vulnerable program. Regardless of what the callback function does, its last act is to return a value that tells the system what to do next. (again simplistically speaking).

Theoretically someone can mitigate these risks by:

Enabling Structured Exception Handling Overwrite Protection (SEHOP)
Recompiling software using a newer version of Microsoft Visual C++

Windows Vista Service Pack 1, Windows 7, Windows Server 2008 and Windows Server 2008 R2 now include support for Structured Exception Handling Overwrite Protection (SEHOP). This feature is designed to block exploits that use the Structured Exception Handler (SEH) overwrite technique. This protection mechanism is provided at run-time. Therefore, it helps protect applications regardless of whether they have been compiled with the latest improvements, such as the /SAFESEH option.

Locating the SEH handler to exploit IMAP4.exe

From the Hackers perspective it is not needed all the information mentioned above, the only thing the hacker needs to know is a way to overwrite the default SEH handler, which translates to knowing how the SEH is structured in the stack and finding the end of the SEH chain, were the default handler is located.

The exception handlers are all linked to each other and they form a linked list chain on the stack, that is palced relatively close to the bottom of the stack. When an exception occurs, Windows retrieves the head of the SEH chain walks through the list and tries to find the suitable handler to close the application properly.

So again simplisticly speaking SEH is a per-thread structure in memory that provides a linked list of error handler addresses that can be used by Windows programs to gracefully deal with exceptions, like the one we generated in the previous post when we fuzzed the application.

The screen shot below show the end of the SEH chain for our program:

Note: This is a Olly Debugger v1.0 screen shot before any injection is made. See the default SE Handler seats below the End of SEH chain and is 01CCFFE. Also see the address of the Next record address which is FFFFFFF indicating that this is the end of the SEH.

If you go the debugger (meaning Olly Debugger v1.0) attach the executable IMAP4 you can see the SEH chain by doing a View -> SEH Chain. Well if you do that you will see that in the SEH windows there only one entry.

Note: This is the IMAP4.exe SEH Chain entry table.What you should see now is an intact SEH chain – one that hasn’t been overwritten. You can tell this because the handler address is a valid one within kernel32dll (from the SEH chain window – see screenshot above) and because the SEH entry near the bottom of the stack is preceded by an entry with the data FFFFFFFF (this stack entry should be marked as “Pointer to next SEH record” shown in previous screen shots).

When we performs a regular stack based buffer overflow, we overwrite the return address of the Extended Instruction Pointer (EIP) and when doing a SEH overflow, we continue overwriting the stack after overwriting EIP, so we can overwrite the default exception handler located at the end of the SEH chain, in our exploit there is only one entry in the SEH chain so there is only one default SE Handler at the bottom of our stack.

So again when the exception is triggered the program flow go to the default SE Handler (for the reasons described above). All we need now is to insert some code to redirect the execution to our payload. As the Next SEH pointer is before the SE handler we can overwrite the Next SEH (which again in our case is the end of the SEH).Since the shellcode is located after the Handler. We must trick the SE Handler to execute a POP POP RET instruction to set the address in such a way so the Next SEH will be placed in the EIP, there for executing the code in Next SEH.

Now as already mentioned what we need to do is to overwrite the exception handler of the vulnerable application and make the program return to our shellcode using the next SE Handler , which by the time that happens our shellcode will be already loaded to our stack (meaning one of the stack registers e.g. ESP/ECX e.t.c). In order to do that we would have to use the metasploit tools pattern_create.rb and pattern_offset.rb. So again with the use of a simple Python script I am injecting the string generated from the pattern_create.rb (remember that in the previous part we identified that the buffer had length 126 characters, with an ending character of }represented as 7D in Hexadecimal).

This is our simple Python program that is going to do the dirty job:

Note: As you can see I modified the beginning of the the unique pattern so as to overwrite the SEH pointer with 4 A's and the handler with 4 C's. I used the information of the pattern_offset.rb to calculate the SEH distance which by the way was 2 ( again I made sure I kept the size of the string to 126 characters, ending with a single }).

So the vulnerable IMAP4.exe that loaded to Olly Debugger v1.0 looks like this (this is the memory dump):

Note: See that we had a Structured Exception Handling (SEH) crash capture.See that the address 01BAFFA8 points to the SEH handler and also have a look to the string that overwrote the pointer to the next SEH record. If you look carefully the string that overwrote the Pointer to the next SEH record is 42424242 which translates to 4 B's and the string that overwrote the SE handler is 43434343 which translates to 4 C's. The tool pattern_offset.rb gave me the number 2, which verifies that the SEH Chain default handler is located at the bottom of the stack.

The following screen shot from Olly Debugger v1.0 shows the View -> SEH Chain, before the Shit+F9 pressing of the button:

Note: You can also see the thread hexadecimal.

The program after the string injection pauses, meaning that the SEH trough's a software interrupt which gets captured by Olly Debugger v1.0 and pauses the program execution. Now if I press Shift+F9 the code executes lets say normally. If you look at the EIP register you will see that it was overwritten with the handlers 4 C's.

Note: As expected the handler was passed to the EIP.

If we press the play button we get this window:

Note: Again a none readable address for EIP.

It is also important to note that OllyDbg v1.0 features a plug-in architecture that allows third parties to add functionality to the debugger by providing the necessary code in a dll file which can be placed in the OllyDbg v1.0 directory.There are a number of OllyDbg plug-ins available for download from the OpenRCE site at the following URL: http://www.openrce.org/downloads/browse/OllyDbg_Plugins

In this section, I will briefly cover the use of one plug-in that is particularly useful when writing SEH exploits – OllySSEH.This plug-in is available from the following link and allows you to easily see which modules loaded with an application can be used to provide overwrite addresses when writing an SEH exploit.

http://www.openrce.org/downloads/details/244/OllySSEH

To install the plug-in, simply take the OllySSEH.dll file from the \ollysseh\Project\Release\ directory in the zip file, and copy it to the OllyDbg main program directory. Then restart OllyDbg v1.0.

The following screen shot shows the SSEH for our vulnerable application:

Note: See that all module from the application did not use the SSEH technology, the SSEH flag is set to OFF.

The SEH Handler and the POP POP RET

One of the simplest ways in which to perform software exploitation is to use instructions located in specific areas of memory to redirect code execution to areas of memory that we can control. In the case of the vulnerability described so far in this tutorial we have managed to set the EIP register to locations of our choosing both via directly overwriting a RETN address on the stack and by using an overwritten SEH entry to redirect execution via the windows error handling routines. If we want to use this control over EIP to redirect to our own code inserted within the application, the simplest way to proceed is to find instructions that can perform this redirection at known locations within memory.

The best place to look for these instructions is within the main executables code or within the code of an executable module that is reliably loaded with the main executable. We can see which modules we have to choose from by allowing the program to run normally and then checking the list of executable modules in OllyDbg v1.0.

The steps we have to follow to exploit the application are:

When the exception is triggered the program flow go to the SE Handler.
All we need is just put some code to jump to our payload.
Faking a second exception makes the application goes to the next SEH pointer (not needed for our example).
As the Next SEH pointer is before the SE handler we can overwrite the Next SEH.
Since the shellcode sits after the Handler, we can trick the SE Handler to execute POP POP RET. instructions so the address to the Next SEH will be placed in EIP, therefore executing the code in Next SEH.

In order now to locate the POP POP RET command sequence we can use Olly Debugger v1.0 and engage the search command utility by right clicking options Search for->Sequence of commands or Search for->All sequences, to either search for individual instances or all instances of a particular command sequence.

Let’s try searching for all instances of POP, POP, RET sequences in USER32.dll. Make sure that module is still selected in the CPU View, then right click on the top left hand pane and select Search for->All sequences. Then, in the find sequence of commands window that appears type the following:

POP r32
POP r32
RETN

The Olly Debugger v1.0 utility screen shot looks like this:

Note: Where “r32″ is shorthand for any 32 bit register (e.g. ESP, EAX, etc).

Epilogue

In this article we managed to overwrite the SEH Next record pointer register and the SE Handler register with desired sequence of characters the 4 B's and 4 C's. In part 3 we will talk about shellcodes and in part 4 we will do the shellcode injection.

To be continued...

Reference:

Pages

21/04/2012

Malware Analysis of MSFPayload

18/04/2012

Over The Flow (Part 2)