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