Control-Flow Hijacking Buffer Overflow Vulnerabilities

Project Goal
This project will give you hand-on experience with control-flow hijacking attacks. We will be using
the SEED Labs setup (hence the above copyright notice). However, be aware the project is different
from one on SEED Labs.
In each task, you will be asked to by perform the exploit under specific conditions (e.g., with ASLR
enabled or disabled). Pay attention to the setup make sure you solve the lab smoothly.
For each step, utilize gdb to understand how the programs work and test your inputs. See lecture3
and lecture4 for reference.
This project must be done in groups of 2 or 3 students.
Deliverables:
1- A PDF report showing (print screen /code) for the required deliverables (if you submit
another extension than a PDF you will lose 30% automatically). Note that not all steps have
deliverables. All deliverables are clearly marked in this document and are numbered. You
should only submit those.
2- A zip folder containing your code, please follow the submission guidelines at the end of this
document.
Task 1: Configuring the project and ASLR
1- Unzip the proj2 folder. Once you do this, you will find a c file for each task (i.e., named
task2.c, task3.c …etc). These are the vulnerable programs you will exploit. Also, you
will find files named exploit3.py, exploit4.py…etc. These are the files you will use
to launch the attack. While working on the project, you can use any method to setup the
exploit (e.g., manually). However, once you find a solution, you will need to put it inside the
exploit template (read the comments in the files). Note that some tasks do not have an exploit
file (e.g., task2) and some tasks have an additional file (i.e., task7). Pay attention to the
instruction in each task carefully.
Copyright © 2006 – 2016 by Wenliang Du. This work is licensed under a Creative Commons
Attribution-NonCommercial-ShareAlike 4.0 International License. If you remix, transform, or
build upon the material, this copyright notice must be left intact, or reproduced in a way that is
reasonable to the medium in which the work is being re-published.
2- Now that you unzipped the folder, you will need to configure the project. Open the
proj2setup.h file, and you will see the following line:
You will replace the X above with the last 3 digits of the student ID of a member in the
group, or the next multiple of 8 of the last 3 digits (you can choose ANY member). For
example, if your student ID is 442123456, then replace X with 456. Note that this is the size
of the buffer in all subsequent tasks. That is:
The above line means that the size of buffer will be whatever value you put instead of X.
Now compile the files. Open a terminal in the project directory and run the following
command:
If you changed X correctly you should see the executable files for task2→task7.
Deliverable 1: provide a clear print screen of BUFFER_SIZE you chose.
3- ASLR: The makefile already built the binaries with the required defenses for each task (e.g.,
with or without DEP). However, ASLR is configured by the OS, and you will need to change
it manually depending on the requirement for each task. To see the state of ASLR, type the
following command in the terminal:
This should print the number 2, meaning that ASLR is enabled. For any task that requires you
to disable ASLR, run the following command:
Now check the state of ASLR again,
You should get a 0, meaning that ASLR is disabled. To enable ASLR again, you will replace
echo 0 with echo 2, that is:
If you check the state of ASLR again you will see it back to 2, meaning it is enabled again. In
the following tasks, pay attention to whether the task requires ASLR to be enabled or not.
Finally, be aware that whenever you shutdown or restart the VM, ASLR will be enabled
again by default, even if you disabled it before shutting or restarting the device. If you work
on a task at separate time periods, make sure you configure things correctly.
~/…/proj2$ make all
#define BUFFER_SIZE X
seed@VM:~$ cat /proc/sys/kernel/randomize_va_space
seed@VM:~$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
seed@VM:~$ cat /proc/sys/kernel/randomize_va_space
seed@VM:~$ echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
char buffer[BUFFER_SIZE];
Task 2: Running your shellcode
Open task2.c. You will see the following line:
The goal of this task is put a functioning shellcode above. Such that when you run task2 executable
you will get: (1) The size of the shellcode; (2) an open shell. Note that the size of the shellcode is
different depending on the one you are using. The output should be similar to the following:
When you put your shellcode in task2.c, you must run make all again to re-compile the
executable. See Lecture3 slides for hints.
Deliverable 2: provide a print screen running task2 correctly, showing the size of your shellcode.
Mention how you obtained/generated the shellcode.
Task 3: Exploiting a buffer overflow using code injection
The task3.c file includes a buffer overflow vulnerability. It was built with the following defenses:
DEP Disabled
Stack canary Disabled
ASLR Disabled
(Make sure to disable ASLR when working on
this task as was shown in task 1)
The goal of this task is to use code injection to open a shell in the task3 binary. You should use the
shellcode you developed from task 2 as part of your payload here.
The task3 program takes its input from the command line and prints a greeting message. For
example, will use the name Zaid as the input:
Alternatively, we can use the exploit3.py file as template to automate the process. Open the
exploit3.py file and change the following:
char shellcode[] = “”; // Put your shellcode here
seed@VM:~$ ./task3 Zaid
Hello, Zaid
final_payload = “Zaid”
seed@VM:~$ ./task2
[+] Your shellcode length is: 77 bytes
$
Now run task3 with the following command:
Your goal in this task and in other tasks is to find a payload that will open a shell. You may work
manually but make sure you use the template file in the end.
Deliverable 3:
1. A print screen running task3 correctly (opening a shell)
2. Write down the values you used in exploit3.py for ret_addr and nop_length.
3. Explain why and how did you choose the value for nop_length?
4. What value did you choose for ret_addr_factor? Explain why you made your choice?
Task 4: Bypassing stack canary with code injection
The task4.c file includes a buffer overflow vulnerability. It was built with the following defenses:
DEP Disabled
Stack canary Enabled
ASLR Disabled
(Make sure to disable ASLR when working on
this task as was shown in task 1)
Here the task4 binary takes 2 inputs from the command line. You can run it as the following:
Again, you can do this using exploit4.py:
Then run it using command line
The goal here remains the same, craft an input that will open a shell. However, here you have the
stack canary enabled (hint: Use the second input to directly corrupt the return address).
Deliverable 4:
1. A print screen running task4 correctly (opening a shell)
2. Explain what you used in exploit4.py in to get a shell (briefly, no more than five
lines).
seed@VM:~$ ./task3 `python exploit3.py`
Hello, Zaid
seed@VM:~$ /task4 Zaid 1
Hello, Zaid, you are number 1
final_payload = “Zaid” + ” 1″
seed@VM:~$ ./task4 `python exploit4.py`
Hello, Zaid, you are number 1
Task 5: Bypassing (stack canary + DEP) with code reuse
The task5.c file includes a buffer overflow vulnerability. It was built with the following defenses:
DEP Enabled
Stack canary Enabled
ASLR Disabled
(Make sure to disable ASLR when working on
this task as was shown in task 1)
Here the task5 binary is the same as the one in task 4. Except we cannot inject code here.
Alternatively, you will need to use an existing code in task5.c to open a shell.
Deliverable 5:
1. A print screen running task5 correctly (opening a shell)
2. Explain what you used in exploit5.py to get a shell (briefly, no more than five lines).
Task 6: Bypassing (stack canary + DEP + ASLR)
The task6.c file includes a buffer overflow vulnerability. It was built with the following defenses:
DEP Enabled
Stack canary Enabled
ASLR Enabled
(Make sure to enable ASLR when working on
this task as was shown in task 1)
Here the task6 binary is the same as the one in task 5. Except we enabled ASLR. Note that if you
use gdb, it might run without enabling ASLR (i.e., you will get the same addresses) unless you
explicitly configure it to use ASLR.
Deliverable 6:
1. A print screen running task6 correctly (opening a shell)
2. Explain what you used in exploit6.py to get a shell (briefly, no more than five lines).
3. What benefits we got by enabling ASLR without PIE here?
Task 7: Bypassing (stack canary + DEP + ASLR) with PIE-enabled
The task7.c file includes a buffer overflow vulnerability. It was built with the following defenses:
DEP Enabled
Stack canary Enabled
ASLR Enabled
(Make sure to enable ASLR when working on
this task as was shown in task 1)
Here the task7 binary is the same as the one in task 6. Except we compiled with executable with
PIE enabled. Note that if you use gdb, it might run without enabling ASLR (i.e., you will get the
same addresses, and not see the effect) unless you explicitly configure it to use ASLR.
The payload here should follow the same structure from task 6. However, you will not always get a
shell here. Instead, will need to run exploit7.py multiple times to get a shell.
To solve this part, perform an objdump for task7 and check what parts of the addresses are static.
The next step, you will need to figure which bytes are randomized by ASLR. Once you found which
bytes are randomized, change the ret_addr you used in task 6 accordingly. Note that you can pick
any values for the randomized bits of ret_addr. Once you constructed your payload in
exploit7.py, run the run_task7.sh script using the following command:
This should run until you get a shell after N trials (N will vary each time you try). The script will
print duration and how many times it ran until you get a shell as in the following:
Deliverable 7:
1. A print screen running task7 correctly (opening a shell)
2. How many bits are randomized in the text section? Which ones are they (e.g., bits 11-15)?
3. Execute source run_task7.sh, until you get a shell and record the number of times
needed to obtain a shell (i.e., 23 above). Whenever you get a shell, type exit, then
CTRL+C and run source run_task7.sh until you record 10 values. Put these in a
table.
4. What is the average number of times to break ASLR from the previous question?
Hand in Instructions
1- Submit your answers as a PDF on LMS. You are only required to include the above deliverables
(i.e., 1—7).
2- Create a folder and name it proj2_studentID1_StudentID2_StudentID3, where student
ID is the student ID for each member in the group. Copy all project files (i.e., all files inside
proj2 directory) inside this folder. Compress this folder as a zip folder and submit it separately.