STACK OVERFLOW 5: EXPLOITING FREE FLOAT FTP
- Layout for this exercise:
0 - Introduction
- Free Float is a vulnerable FTP server, documented at Exploit Database:
https://www.exploit-db.com/exploits/23243/
1 - Installing and running FreeFloatFTP
- 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 21 is open at the victim machine, and running FreeFloat:
2 - Overwriting the stack
- Writing a basic Python script to overwrite the stack of the victim with 'A' characters:
- Giving execution permissions to the exploit:
- Starting the program with Immunity Debugger:
- Running the program:
- Launching the exploit from the attacker Kali to the victim Windows 10:
- The program crashes as the stack is overwritten, because it is forced to access a non executable address (0x41414141 is the hexadecimal representation for AAAA):
- Both EIP and ESP are overwritten with 'A's:
3 - Controlling the EIP
- With the purpose of detecting where the EIP is overwritten, an easily recognizable string of 1000 bytes is created with a Ruby script:
- Now, this string is introduced into the exploit:
- At this point, Free Float is restarted with Immunity Debugger.
- The exploit is launched:
- The program crashes, but now EIP is overwritten with 69413269, and ESP with 69413669:
- 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) a bunch of four NOPs (\x90) is introduced.
iv) the rest of the stack will be overwritten with 'C's
- Again, Free Float FTP is restarted with Immunity Debugger.
- Launching the exploit:
- As expected, the program crashes. EIP is overwritten with four 'B's, and ESP points to the middle of the NOPs section. The 'C' area will be the best one to locate the future shellcode:
4 - 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, 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 of 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 772052FB:
- The set of four 'B's on the Python exploit is replaced by the memory address 772052FB , introduced in reverse order '\xFB\x52\x20\x77' due to the fact that x86 processor architecture follows the Little Endian format (least significant byte occupying the lowest memory position):
- The exploit so far:
5 - 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 AllChars with all the possible hexadecimal characters is used. The Python script is modified, introducing the AllChars string in the 'C's section:
- Again, Free Float is restarted with Immunity Debugger.
- Launching the exploit:
- The program crashes as usual. However, a close inspection of the memory details that the buffer execution has been interrupted just after the NOPs, just where the AllChars strings 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, Free Float is restarted with Immunity Debugger and the exploit is launched.
- The program crashes and the execution of the AllChars string is interrupted before \x0A, meaning that it is a bad character:
- \x0A is removed:
- The process is restarted and the exploit is launched. The program crashes and the execution of the AllChars string is interrupted before \x0D, meaning that it is a bad character:
- \x09 is removed:
- Now, the execution of AllChars has been completed,from x01 to xFF, meaning that there no more bad characters.
- To sum it up, there are 3 bad characters, that being interpreted literally by the compiler, its immediate effect consists of truncating the normal execution of the program. Once removed, the buffer is executed correctly.
0x00 = Null Byte = terminates a string copy operation.
0x0A = Line Feed = advances by the space of one line.
0x0D = Carriage Return = resets to the beginning of a line of text.
6 - Generating a shellcode0x0A = Line Feed = advances by the space of one line.
0x0D = Carriage Return = resets to the beginning of a line of text.
- msfvenom helps generating a shellcode, with these options:
a) payload: -p windows/shell_reverse_tcp
b) local host, attacker's IP = LHOST = 192.168.149.129
c) local port, LPORT = 4444, where the attacker listens for a reverse connection
d) format = -f c, language C
e) EXITFUNC = thread, the execution of the shellcode does not shutdowns FTPserver.exe
f) bad characters = -b "\x00\x0A\x0D"
- The Python script is redefined to include the shellcode:
7 - Exploiting the victim
- Before launching the final attack, the server Free Float is restarted at the victim Windows 10.
- Then, from the attacker Kali, using nc, a listening session is setup on port 4444:
- The exploit is launched:
- The attack is successful, because Kali achieves a meterpreter session with the victim:
- After the attack, the process FTPserver.exe is still running:
