Changing the Overflow Buffer
Let’s try to figure out this offset misalignment.
Reviewing the first part of our large padding buffer of “A” characters,
we notice that it starts with a call to malloc with the size 780:
This number should seem familiar.
In the beginning of this Topic, we noted that 780 is the offset in bytes required
to overwrite the return address on the stack and take control of the EIP register
The malloc function only allocates a block of memory based on the requested size.
This buffer needs to be properly initialized,
which is done using the memset function right after the call to malloc.
Using memset will fill the memory allocation with a particular character,
in our case “0x41”, the hex representation of the “A” character in ASCII.
The next line of code in the exploit is particularly interesting.
We find a call to memset, which sets the last byte in the allocation to a NULL byte
This may seem confusing at first; however, continuing to read the code,
we arrive at the lines where the final buffer is created.
The code starts by allocating a memory block for the buffer character array
using malloc, then filling the array with NULL bytes.
Next, the code fills the buffer character array by copying the content
of the other variables through various string manipulation functions.
Knowing that the final buffer must be constructed as a string is very important.
The C programming language makes use of null-terminated strings,
meaning that string manipulation functions determine the end and the size of a string
by searching for the first occurrence of a NULL byte in the target character array.
Since the allocation size of our initial padding buffer is 780,
by setting the last byte to null,
we end up concatenating a string of “A” characters that is 779 bytes in length.
This explains the misaligned overwrite of EIP.
We can quickly fix this misalignment by increasing the requested memory size
defined by the initial_buffer_size variable by 1.
As a final test, we’ll again compile the code.
First, we’ll set up a Netcat listener on port 443 to catch our reverse shell.
We’ll restart the Sync Breeze service on the target machine.
Next, we’ll run the exploit.
Finally, we’ll switch to our Netcat listener.
Excellent! We have a shell.
In addition, this exploit no longer requires access to a Windows-based attack
platform in the field, since we can run it from Kali.