Fixing the Exploit
Let’s more closely review the C code.
Further inspection reveals the use of a return address
located in the Visual Basic runtime,
which is not part of the vulnerable software.
If we examine the loaded modules in the debugger on our Windows client,
we’ll notice that this DLL is absent,
meaning that the return address will not be valid for our target.
To verify this, we’ll first need to start the Sync Breeze Service
on the Windows 10 client.
Next, we can launch Immunity Debugger as administrator.
Then click on File, Attach, and select the syncbreeze process.
Once attached, we’ll click on the View menu, then Executable modules.
From there, we can verify that the DLL is not present
by checking the Name and Path values.
Given that the Python version of the exploit is marked as EDB Verified
which means it’s proven to be working,
we can replace the target return address with the one contained in that version.
Continuing our analysis of this C exploit,
we’ll notice that the shellcode variable seems to hold the payload.
Since it is stored as hex bytes, we cannot easily determine its purpose.
The only hint given by the author refers to a NOP slide
that is part of the shellcode variable:
Since bad characters are already listed in the Python exploit,
we can generate our own payload with msfvenom,
remembering to target the x86 platform,
and format it for C code:
Let’s compile the exploit code to determine if it generates any errors.
Now that we have an updated, clean-compiling exploit,
we can test it out.
We’ll return to Immuntiy Debugger with Sync Breeze attached.
We’ll press control-g,
follow the JMP ESP address,
and press F2 to set a breakpoint on it.
Once our breakpoint has been set in the debugger, we can press F9
and let the application run normally
and attempt to execute our exploit from Kali.
Because this binary is cross-compiled to run on Windows,
we cannot simply run it from our Kali machine.
To run this Windows binary, we’ll need to use wine,
which is a compatibility layer used for running Windows applications
on several operating systems.
Surprisingly, we do not hit our breakpoint at all.
Instead, the application crashes
and the EIP register
seems to be overwritten by an unexpected value.
By analyzing both the value stored in EIP
and the buffer sent to the target application,
we’ll notice that our offset to overwrite the return address on the stack
seems to be off by one byte.
The wrong offset forces the CPU to POP a different return address from the stack
rather than the one we intended.
We’ll examine this discrepancy in the next section.