Whitelist: STACK OVERFLOW / 3 - Exploiting MiniShare file sharing server

STACK OVERFLOW / 3 - Exploiting MiniShare file sharing server

- Layout for this exercise:

0 - Introduction

- MiniShare is a minimalist HTTP server for Microsoft Windows under the GPL. The purpose of this software is to be simple and intuitive, so only the necessary features of the HTTP / 1.1 protocol are implemented. Most actions are feasible using the mouse. For example, you can share files by drag'n'drop. It is possible to use the command line for advanced use.

- A buffer overflow vulnerability was registered on 2004, and documented at Exploit Database:

https://www.exploit-db.com/exploits/616/

1 - Installing and running Minishare

- The program can be downloaded from Exploit Database, as seen in previous image.

- Once installed and running:

- Checking that the program is running at the victim machine:

- From the attacker, it can be checked that the port 80 is open at the victim machine, and the version of the software is actually MiniShare:

- The program can be started with Immunity Debugger:

2 - Overwriting the stack

- Writing a basic Python script to overwrite the stack of the victim with a set of 3000 'A' characters:

- Giving execution permissions to the exploit:

- Launching the exploit:

- The program crashes, because it is forced to be executed in a non accessible memory area like 41414141 (AAAA in ASCII):

3 - Controlling the EIP

- With the purpose of detecting where the EIP is overwritten, an easily recognizable string of 3000 bytes is created with a Ruby script, and sent to the victim.

etc ...

- The string is introduced into the exploit:

- Once MiniShare restarted with Immunity Debugger, the exploit is launched against the victim:

- The program crashes, but now EIP is overwritten with 43366843, and ESP with 68433768:

- Using another Ruby script, both addresses are located into the memory dump:

- Now, the Python script is modified according to the previous results:

i) the set of 'A's will reach up to the EIP location.
ii) EIP will be overwritten with four 'B's.
iii) the rest of the stack will be overwritten with 'C's, where ESP points directly to the beginning of this section.

- Restarting MiniShare, and launching the exploit:

- As expected, the program crashes. EIP is overwritten with four 'B's, and ESP (03AA38D0) points to the start of the 'C' section. The 'C' area will be the best one to locate the future shellcode.

4 - Hunting bad characters

- Bad characters are those ones interpreted literally by the program, so that the program is truncated in the middle of the execution.

- With the purpose of identifying bad characters, a string with all the possible hexadecimal characters is created.

- The Python script is modified, introducing the AllChars string in the 'C's section:

- Again, MiniShare is restarted with Immunity Debugger.

- Launching the exploit:

- The program crashes as usual, because EIP points to a non executable area of 'B's:

- However, a close inspection of the memory details that the buffer execution has been interrupted just after the four 'B's, just where the AllChars string would begin to be executed. This means that the character '0x00' truncates the execution of the rest of the buffer:

- So, '\x00' is clearly a bad character, and it should be removed from the exploit:

- Let's go on searching for more bad characters.

- Again, MiniShare is restarted with Immunity Debugger.

- Launching the new exploit:

- Now, the buffer execution has been interrupted just after '0x0C'. This means that the character '0x0D' truncates the execution of the rest of the buffer:

- So, '\x0D' is a bad character, and it should be removed from the exploit:

- The new exploit:

- Again, restarting MiniShare with Immunity Debugger, and launching the exploit:

- Now, the execution of AllChars has been completed,from x01 to xFF, meaning that there no more bad characters.

- To sum it up, there is 2 bad characters, that being interpreted literally by the compiler, its immediate effect consists in truncating the normal execution of the program. Once removed, the buffer is executed correctly.

0x00 = Null Byte = terminates a string copy operation.

0x0D = Carriage Return = resets to the beginning of a line of text.

5 - Generating a shellcode

- msfvenom helps generating a shellcode, with these options:

a) payload: -p windows/shell_reverse_tcp
b) local host, attacker's IP = LHOST = 192.168.1.11

c) c) local port, LPORT = 443, where the attacker listens for a reverse connection
d) format = -f c, language Cf

e) encoding = -e x86/shikata_ga_nai
f) EXITFUNC = thread, the execution of the shellcode does not shutdowns minishare.exe
g) bad characters = -b "\x00\x0D"

- The Python script is redefined to include the shellcode:

6 - Redirecting the flow execution

- The goal of this part of the attack is to find an stable way of redirecting the execution flow to the memory section (now, full of 'C's, and pointed by ESP), where the shellcode will be located.

- One way of achieving that goal would be finding an instruction JMP ESP located in a memory section not subject to changes. Let's remember that techniques like ASLR or DEP rebase the memory address allocations in each reboot of the system.

- Looking for executable modules:

- For instance, clicking on USER32.DLL:

- Searching for a JMP ESP command:

- One JMP ESP is detected at 75EF6D53:

- The set of four 'B's on the Python exploit is replaced by the memory address 75EF6D53 , introduced in reverse order '\x53\x6D\xEE\x75' due to the fact that x86 processor architecture follows the Little Endian format (least significant byte occupying the lowest memory position):

- Also, introducing a bunch of NOP (\x90) instructions for ensuring that the shellcode is going to actually be executed.

7 - Exploiting the victim

- Before launching the final attack, the server MiniShare is restarted at the victim Windows 7.

- Then, from the attacker Kali, using netcat, a listening session is setup on port 443: