Win 32 Bit Buffer Overflow Vulnerability — SyncBreeze.exe Writeup

Hi All,

In this blog post, I will explain Windows 32 bit buffer overflow vulnerability that exists in Sync Breeze.exe.

Necessary Programs:

Immunity Debugger

Mona.py

Sync Breeze 10.0.28

First, we need to install our vulnerable application and make sure that it is running in the service level. Once we make sure that it is running as it should be, we enable its web interface running at port 80.

Figure 1 : Running SyncBreeze as a Service

Figure 2 : SyncBreeze Web Interface

Run Immunity Debugger and attach the service.

Figure 3 : Attaching SyncBreeze in Immunity Debugger

Figure 4 : Immunity Debugger Screen

Fuzzing the application manually is good but we need to automate this process.

Before further going, what is Immunity Debugger?

Immunity Debugger is a powerful way to write exploits, analyze malware, and reverse engineer binary files. It builds on a solid user interface with function graphing, the industry’s first heap analysis tool built specifically for heap creation, and a large and well supported Python API for easy extensibility.

I developed a Python fuzzer named fuzz1.py

Figure 5 : Source Code of fuzz1.py

Figure 6 : Running fuzz1.py

The application died at 900. So we can conclude that our exploit memory size is approximately 900. Since EIP is overwritten by AAAA, the application stopped running. In other words, access violation has occurred whiled executing AAAA. Another interesting thing is that ESP points to an address that is full of AAAA, meaning that we can also control the content of ESP.

Figure 7 : Memory Layout of the Fuzzed Application

EIP points to 41414141, which is hexadecimal representation of AAAA.

It is time to learn at which offset it is. How do we learn this information? It is not super hard to find out. Metasploit has a good tool in order to create unique set of characters so that you can easily find out at which offset EIP is. Recall that our length is 900 but for simplicity we will create with a length of 1000.

Figure 8 : Msf Tools

Figure 9 : msf-pattern_create usage

Figure 10 : Creating 1000 Byte Length Unique Pattern

We need to supply length.

In our fuzzer script, we need to place this unique pattern. Instead of sending all the A’s, we will send msf pattern.

Figure 11 : Source Code of fuzz2.py

Figure 12 : Running fuzz2.py

Program crashed again but this time eip has 42306142 value. We will try to locate the offset.

EIP location is : 42306142

Figure 13 : Locating Offset

Figure 14 : msf-pattern_offset usage

Figure 15 : Locating Offset

Our offset is 780. That means we need to send 780 byte just before controlling the EIP. As a next step, we will check whether we can fill EIP with BBBB. If so, we make sure that we succussfully locate the exact place of EIP.

Figure 16 : Source Code of fuzz3.py

Figure 17 : Running fuzz3.py

Figure 18 : Controlling EIP

Yes! We successfully manage to control EIP. EIP is fulled with 42, which is hexadecimal representation of B.

Now that we can control EIP, what should we do for the next step? Notice that we can write to ESP area. The idea would be that we might place a shellcode (for instance, a reverse shell) in ESP and we can have the application point ESP through EIP, more specifically, through JMP ESP instruction and then start executing code in ESP. We now need to find JMP ESP instruction in the program. To be able to find ESP, we will take adventage of mona.py.

If you write “!mona” to immunity debugger, you see a list of commands that you can use within mona.py. In our case, we will use JMP command to find pointers that will allow us to jump to a register.

Command : !mona jmp -r esp

Figure 19 : Mona Command

Figure 20 : Figure of JMP ESP Addresses

Address Location : 10090C83 → JMP ESP

We choose “0x10090C83” as address regarding jmp esp. Also, if you look at it in a detailed way, there is no ASLR, rebase, safeSEH, which are memory protection mechanism against exploits. However, you cannot directly write “0x10090C83” as address to EIP. We have a small problem here. The problem is that this is a memory address to the binary and it has to be in little endian format. We need to convert this memory address to little endian format. There are two ways so as to achieve it. First, we can do it manually and write “\x83\x0c\x09\x10”. The other way is that you can import struct library and use the pack function. We will write “\x83\x0c\x09\x10” in this case.

Once we arrange JMP ESP instruction, we now need to take bad characters out.

Figure 21 : Code Snipped from fuzz4.py

Figure 22 : Analyzing Bad Characters

badchars = \x00\x0a\x0d\x25\x26\x2b\x3d

Once we arrange bad chars, we are now moving into the shellcode and we should not place our shellcode just the beginning of ESP. We need to place some NOPs so that there will be a slight transition and our exploit will be more reliable. I generally go with 16 bytes of NOP. Once we finish this operation, we need to create our shellcode payload. We will use msfvenom to generate a shellcode.

Figure 22 : Generating a Shellcode via Msfvenom

Figure 23 : Code Snipped from fuzz5.py

Figure 24 : Configuring Metasploit for Listening and Getting a Reverse Shell

We have successfully managed to get a reverse shell from the target server. We are now executing code remotely. We have Remote Code Execution (RCE) by making the advantage of stack based buffer overflow vulnerability.

Thanks for reading.

Can ÖZKAN