AdSense

Wednesday, November 2, 2016

STACK OVERFLOW / 1 - Exploiting SLMail email server


STACK OVERFLOW: EXPLOITING SLMAIL


- Layout for this exercise:





0 - Introduction

- The POP3 server of Seattle Lab Mail 5.5 suffers from an unauthenticated buffer overflow vulnerability when receiving a very long password. This vulnerability can be exploited in any version of Windows running the executable smail.exe.

- Related information:

https://www.cvedetails.com/cve/CVE-2003-0264/

https://www.rapid7.com/db/modules/exploit/windows/pop3/seattlelab_pass

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




1 - Installing and running the SLMail service


- Launching the installer in the victim, a Windows 7 machine:
















- The service is started with administrative privileges:











- From the attacker Kali, checking that the service is running on the victim Windows:















2 -  Overwriting the stack

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






- Giving execution permissions to the  exploit:



- Attaching SLmail process to Immunity Debugger:








- Let's notice that the PID would change any time the program is run:




- Running the program   .


- Launching the exploit from the attacker Kali to the victim Windows 7:





- The stack is overwritten and the program crashes because it is forced to access a non executable address (0x41414141 is the hexadecimal representation of 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 3500 Bytes is created and sent. 

- This string holds a unique pattern created with a Ruby script. In that way, it will be very easy to recognize and detect the bytes that are actually overwritting the EIP.


etc ...


- The string is introduced in the Python exploit:




- Again, SLMail service is restarted and the process attached to Immunity Debugger.


- Launching the new exploit: 



- The program crashes, but now the EIP and ESP are overwritten with 39694438 and 44306A44:








- Using a Ruby script to detect the position where both 
39694438 and 44306A44 are located:







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


i) the set of 'A's will reach up to the EIP location.
ii) EIP is 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.




- Again, SLMail service is restarted and the process attached to Immunity Debugger.

- Launching the new exploit:




- As expected, the program crashes. EIP is overwritten with four 'B's, and ESP (0163A128) 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, SLMail service is restarted and the process attached to Immunity Debugger.

- Launching the new 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 strings would begin to be executed. This means that the character '0x00' truncates the execution of the rest of the buffer:




- So, '\x00' should be removed from the exploit:







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

- Again, SLMail service is restarted and the process attached to Immunity Debugger.

- Launching the new exploit:









- Following in dump the evolution of the buffer execution:





- Now, the execution of the buffer has been interrupted just after '0x09', so we conclude that '0x0A' is also a bad character:





- Removing 
'0x0A' from the exploit:






- Again, SLMail service is restarted and the process attached to Immunity Debugger.

- Launching the new exploit:








- Now, the execution of the buffer has been truncated between '0x0C' and '0xE', so we conclude that '0x0D' is also a bad character:










- Removing 
'0x0D' from the script:






- Again, SLMail service is restarted and the process attached to Immunity Debugger.

- Launching the new exploit:









- Now the whole set of characters is correctly executed, so there are no more bad characters: 




- To sum it up, there are 3 bad characters that being interpreted literally by the compiler, their immediate effect consist on 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.
0x0A = Line Feed = advances by the space of one line.


5 - 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 'Ç'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. 


mona.py is a tool written in Python and available with Immunity Debugger that helps finding a reliable JMP ESP instruction.

- First, all modules are examinated, and SLMFC.DLL is identified as not having memory protection techniques: Rebase = False, SafeSEH = False, ASLR = False.









- Now, let's find the opcode of instruction of JMP ESP:




- Again, using mona.py, the module SLFC.DLL is searched until finding a JMP ESP instruction (opcode \xFF\xE$):





- One JMP ESP instruction is detected at address 5F4A358F: 




- Following the memory address 
5F4A358F:






- As indicated by mona.py, the JMP ESP is found at 
5F4A358F:




- Then, the set of four 'B's on the Python exploit is replaced by the memory address 
5F4A358F, introduced in reverse order '\8F\x35\x44\x5F', due to the fact that x86 processor architecture follows the Little Endian format (least significant byte occupying the lowest memory position):




6 - 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 = 10.11.0.203
c) local port, LPORT = 443, where the attacker listens for a shell 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 shutdown smail.exe
g) bad characters = \x00\x0A\x0D





- 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.




- The final exploit:



7 - Exploiting the victim


- Now, to test the exploit, the attacker sets up a listener session on port 443: 



Again, SLMail service is restarted:





- Launching the exploit, the attack is successful, because the attacker achieves a remote shell of the victim:





- Also, it can be checked that after running the exploit in the victim, the process SLmail.exe is still alive:







ALTERATION OF A PROGRAM AT RUNTIME - Example 2 - Changing output - Evans Debugger with Linux


ALTERATION OF A PROGRAM AT RUNTIME - Example 2 - Changing output - Evans Debugger with Linux

EDB-Debugger (Evan's Debugger) is an analyzer, debugger and disassembler for multi architecture binary files with ELF format (executable and linkable format). EFL is the standard format for executable files, object code, shared libraries, and memory dump.

- The goal of the author, Evan Teran, was to create a similar tool to OllyDbg analyzer for usage with Linux systems. Although GDB (GNU Debugger) is available for Linux, this analyzer only works through command line, providing no GUI. 

- In this example EDB-Debugger will be used to alter the runtime operation of a program written in C language.

- First we create a simple program (prueba.c) in C language, the result of which is to print out the string HOLA:




- Compiling:




- Running, and the result is that the program prints the string HOLA in the console:




- To begin the analysis the executable file is loaded in the debugger EDB:




- Running the program, the output is the expected HOLA:




- Then we seek the location of the string HOLA within the program. The path is as follows: Plugins -> Binary Searcher -> Binary String Search Ctrl + F




- EDB allows to enter directly characters searched in ASCII. The result of that search string in hexadecimal is 48 4F 4C 41 = H O L A, located in the memory segment between positions 0804840F and 0804940F:




- Indeed, in previous memory position we find the following statement, one of whose operands is 0x414C4F48.




The operand is stored in Little Endian format (least significant byte at lowest memory position): 

0x414C4F48 = 48 4F 4C 41 = HOLA (in ASCII)

- In order to alter program operation at runtime, right clicking on previous instruction, and in the displayed menu choosing the Edit Bytes option:




This option allows to edit the ASCII code, and where it says HOLA to write BYE:




Instruction is altered, being the operand in Little Endian format 0x455942 the ASCII value of string character BYE:




- After running the program, we see that the output is now BYE: