SEIG Modbus Driver v3.34 CVE-2013-0662

Introduction

The Modbus Serial Driver creates a listener on Port 27700 / TCP. When a connection is made, the Modbus Application Header is first read into a buffer. If a large buffer size is specified in this header, a stack-based buffer overflow results.

The final idea of ​​this article is to reproduce and detail the process by which the vulnerability can be detected and exploited, including why it occurs. To study the vulnerability we can choose two methodologies:

Binary Diffing:

This paper is organized as follows. In this paper, we present a new methodology for analyzing the vulnerability of a software application. We will choose this methodology.

The steps to follow are those:

• Install the BinDiff plugin from IDA Pro
• Install the fixed version and detect the binary listening on port 27700
• Make a copy of the binary in a folder
• Delete the fixed version
• Install vulnerable version
• Make a copy of the vulnerable binary in a folder
• Disassemble with IDA Pro the corrected version in order to generate the idb file
• Disassemble with IDA Pro.
• Use BinDiff to find differences between software versions

Fuzzing:

This technique is based on obtaining the program processes and modifies randomly (dumb fuzzing) in order to corrupt the software parsers and generate a crash in the program. 

Binary Diffing

Installation:

First we must install the patched software in Windows XP SP3.

Then we start the application.

According to the description of the CVE, the vulnerability is found in the list 27700, so we list the listening ports with the command: netstat -ab. 

Next we copy the file .exe to our reversing windows 7 machine. After that, we will eliminate or uninstall the fixed version and install the vulnerable one. Finally we copy the vulnerable file .exe to our reversing windows 7 machine. 

Generate the .idb file of corrected version

We open the .exe file patched with IDA Pro and when the analysis finishes we close and we click Pack Database to generate the .idb file. 

Open the vulnerable version and use bindiff

Open this version and Edit/Plugins/Bindiff4.3.0 

This reduces the research surface to only 5 functions that must be analyzed one by one to detect the bug. Click right in sub 409600 function and View Flowgraphs:

We can see what could be a possible patch to avoid a buffer overflow, we can see how multiple network functions are involved in the patch and then in memory address 0x00409da0 is compared EBP register with 0x40e. 

In patched version, if EBP register is greater than 0x40e the flow is directed to a socket close.

But what happens in the vulnerable version? If we analyze the flow with IDA Pro we can see that below the next function call is made sub_409B00

In an ideal case, the execution flow will continue until reaching the next function call sub_401000:

Then we find another interesting function it contains multiple calls to strcpy and memcpy functions so it seems like a good reversing starting point.

Reversing Server network protocol

After rename some functions like recv and parser we apply some reverse engineering last one. We open IDA Pro in Windows XP machine for attaching to process although if you want you can use windows remote server for debugging through IDA Pro in Windows 7. Also I'm going to use Ubuntu for attack machine and exploit development. We know that binary is a server that is listening on port 27700 therefore we must be able to know how the server treats the packets sent by a client that we create and thus be able to study the protocol of communication between client and server. Once we have placed different breakpoints, we run the client.

We can see that the first thing is evaluated is "AABB" string that is included between 3 and 7 byte of our packet sent:

next the third and fourth bytes are compared with 0xffff and if it is not equal, the conditional jump JZ will not be performed. It is of vital importance to add in our request the conditions.

We continue debugging and we see how after the recv call is set with the value 0x0 making the corresponding jump JZ and not directing the flow of execution where should. 

In order to understand why it returns the value 0x0 we have to enter into the function. Researching we realize that the following 2 bytes at 0xffff must be equal to the result of a size (0x10d). But this will be in EBP register with -1 decrement so we just send 0x10e.  Finally we enter into the function recv (renamed) and the comparison is made using the test instruction of ESI register (size 0x10d). So it will be zero and return value of function is 0x1. Win! And why 0x10e? Because in our client we sent 270 bytes of B's therefore we deduce that these bytes are taken into account for size.

Client made until now:

Next step is bypass another check. The following check we must send 0x0064 due to the operation AND with 0xffff and subtract with 0x64 hardcoded value and the result will be 0x0 so the conditional jump JZ is taken. The client is the following right now:

We send and JZ is taken:

Finally, now that we have studied the server-client interaction, we will send a buffer large enough (2048 bytes) to cause the buffer overflow. Boom! EIP Overwritten!.

Exploitation

Now we have to know in which part of the buffer sent are the 4 bytes that overwrite the EIP register therefore we use metasploit to create a pattern and determine the offset.

We run exploit and we get this string overwritten EIP register "9By0"

Exact offset.

This would be the exploit we run and we got the EIP register is 0x41414141

Finally we need a gadget like push esp; ret to execute our shellcode. 

We generate the shellcode with msfvenom and calculate the difference with padding so we have nops + 324 bytes of shellcode. Final exploit:

And boom !! Shell: D