This lab will take place over the course of the entire term. Due dates are listed on the schedule page of this website - each week another piece of the lab is due.
You will complete this lab in groups of up to 3 people. Form your groups now from the people who are available for the same Collaboration Times as you. Use Piazza to form groups!
If it's helpful to know, the average group last semester spent about 25 hours working on completing all the exploits.
Check Piazza for the lecture videos about the topics in the lab, as well as a demo screencast of me doing Exploit 0 to get you started.
To submit exploits, you don't need to do anything! I have root on the server and can therefore access your sploits if you leave them just where they belong in the sploits/ directory of your account.
To receive an account for your group, please form groups of up to 3 people and submit this form once per group:
https://goo.gl/forms/C7k4ELNC4Whn1wPf1.
You’ll need to submit:
Your Wellesley user names.
A valid Linux account name for your group.
A valid SSH public key. If you don’t know how to do that, never fear! Check out the helpful instructions below.
This assignment aims to teach and assess the following learning goals from the course syllabus:
Discover technical security vulnerabilities in programs, web applications, and cryptography; implement attacks which exploit those vulnerabilities to compromise systems; and defend against these vulnerabilities and attacks.
Use the security mindset to analyze assumptions, find vulnerabilities, and identify privacy concerns in technical and non-technical systems of many kinds.
And more specifically within the technical area of Software Security:
Students should be able to analyze applications for buffer overflow, double-free, and format-string vulnerabilities, then implement attacks against those vulnerabilities.
You will be given shell accounts on cs342.wellesley.edu, a server which has been set up specifically for this course. On this server, there are a number of small, vulnerable binaries, called “targets”. Your goal is to exploit these vulnerable applications in order to take over the account of the user who owns them. Each target program target[i] (for i in range(0..8)) is owned by user hax0red[i] and has the setuid bit set, which means that when any user runs the target, it will run with the privileges of its owner.
Your job is to determine a malicious input for each target which exploits some vulnerability in the target. The result will be that instead of doing what it is supposed to do, the target will instead execute your shellcode, which will cause the target to execute a shell. Since the target is running setuid as a target user (e.g., hax0red2 for target2), this shell will be logged in as that user. Write an exploit for each target #1-8. Each exploit, when run on the lab server, should terminate with a shell that is logged in as user hax0red[i] shell (/bin/sh). To confirm this is working, run the command whoami in the shell, and you should see the hax0red[i] user.
Example (begins logged in as your group account):
$ whoami
awesomegroupname
$ ./sploit2
$ whoami
hax0red2
Since these exploits are challenging and complex, I will scaffold this lab by asking you to submit checkpoints along the way. Each week, you'll submit another piece of the lab. In order by week, the parts you'll submit are:
Post a study sheet (described below) to Piazza & form groups
Complete working exploits 1 and 2 & revise your study sheets based on your classmates versions (described below)
Complete working exploits 3 and 5 (note that 5 and 6 are the hardest, so they've been split up)
Complete working exploits 4 and 6
Complete working exploit 7
Complete working exploit 8
Submit individual reflection write-ups (described below)
Submit revisions/retakes of individual reflection write-ups (described below)
Details on this assignment can be found in this Google Doc:
https://docs.google.com/document/d/1UtRvJVZXKStkdIJP_ihBga_anxySZwdkE0OgFhkw7Yw/edit?usp=sharing
tl;dr: By Friday of the first week, you must create a reference sheet/study guide of at most 2 pages summarizing the knowledge needed to achieve the goals listed in the Google Doc under "Students should be able to...".
In the second week, you'll create a new reference/study sheet by reading everyone else's and borrowing (with citations!) ideas you liked and incorporating into yours. Then, for the rest of the term, you can use your study sheet (and those of your group mates, and those of everyone else!) when working on the exploits. Post it to Piazza by the end of the second week .
Since the remainder of this assignment is group work, I ask each of you to write individual explanations of each exploit. These should be pretty straightforward to write if you fully understand the vulnerability and exploit for each target. Finding these challenging means you have more learning to do, which is normal! For each of the 8 targets, write:
(1-2 sentences) What is the vulnerability? What did the programmer do wrong?
(2-3 sentences) What is the conceptual approach of the exploit? What does the attacker do to win here?
(Bulleted list of steps) What steps would you follow to implement the exploit again?
As a guideline, a peer starting out in CS342 who was given your reflection and an account on the lab server should be able to follow your steps to implement each exploit in, let's say, under an hour. For your reference, I provide here an example of a mastery-level response to this question for Exploit 0
After you submit your individual reflections, I will grade each of the three parts of each exploit on this scale:
Needs Improvement
Satisfactory
Mastery
You will then have the opportunity to redo this individual portion to learn more and improve your grade. You may redo any subset on which you did not receive an evaluation of "Mastery", and you have two choices of how to do this: you can resubmit a new written document with updated answers, or you may schedule a time to visit me in my office and explain your new answer in an interactive oral exam. For any portion on which you do better on the redo, your grade for that portion becomes the redone grade. With my permission, you may redo a portion multiple times until the deadline, and you are welcome to visit my office hours so that I can help you learn to understand the exploit before your redo.
A Linux account for your team, on cs342.wellesley.edu
The source code of each of the targets, for your analysis
Skeletons for exploits (hereafter, “sploits”) for each of the targets
Shellcode, from Aleph One
A Makefile which builds the exploits you’ve created
cgdb (to debug the targets and find relevant addresses, behaviors, etc.)
Your goal is to write eight exploit programs (sploit1.c, ..., sploit8.c). Program sploit[i] will execute program /bin/target[i], giving it carefully crafted input that should result in a shell run with the same permissions as user hax0red[i]. (Note: If target[i] had setuid root then sploit[i] would result in a root shell! We don't do that here, for what are hopefully obvious security reasons, so instead you get the permissions of the hax0red[i] user. However, in general, the most valuable applications to exploit are often the ones that are setuid root.)
The skeletons for sploits 1 through 8 are provided in the ~/sploits/ directory. Note that the exploit programs are very short. There is no need to write a lot of code here -- most of the work in this assignment is figuring out a particular malicious input that will own that target.
Sploit 8 is mysterious. The source code looks the same as sploit1... so it should be easy, right? Don't be surprised when it doesn't work. You'll need to execute a return-to-libc attack here.
Executing the targets with malicious input from the command line would work too. Why do we execute them via C programs instead? It’s easier. Your malicious inputs are going to involve manipulating and arranging various arbitrary byte values, op codes, and addresses. Having the power of C to manipulate those values makes it easier.
You will test your exploits on cs342.wellesley.edu, a remote machine running Ubuntu Linux. For this assignment, certain security features have been turned off, such as Address Space Layout Randomization (ASLR). This means that each time you run one of the targets, the address layout of the target’s memory space will be exactly the same. Attacks are possible even against systems protected by ASLR, but they’re simpler this way, and so for learning purposes we have it off.
The targets are stored in /bin and their corresponding sources in ~/sources/. Study the source code of each target, in addition to debugging it. Don’t modify or recompile the targets -- your attacks must work against the versions installed in /bin. Your exploits should assume that the compiled target programs are installed in /bin. Do not move the targets.
$ ls -l /bin/target
-r-sr-xr-x 1 hax0red0 hax0red0 9740 Jan 3 20:56 /bin/target0
-r-sr-xr-x 1 hax0red1 hax0red1 9728 Jan 3 20:56 /bin/target1
-r-sr-xr-x 1 hax0red2 hax0red2 9984 Jan 3 20:56 /bin/target2
-r-sr-xr-x 1 hax0red3 hax0red3 10912 Jan 3 20:56 /bin/target3
-r-sr-xr-x 1 hax0red4 hax0red4 9856 Jan 3 20:56 /bin/target4
-r-sr-xr-x 1 hax0red5 hax0red5 11440 Jan 3 20:56 /bin/target5
-r-sr-xr-x 1 hax0red6 hax0red6 9748 Jan 3 20:56 /bin/target6
-r-sr-xr-x 1 hax0red7 hax0red7 10036 Jan 3 20:56 /bin/target7
-r-sr-xr-x 1 hax0red8 hax0red8 9732 Jan 3 20:56 /bin/target8
Each target[i] is setuid hax0red[i], which means that each target will execute with the privileges of as hax0red[i], regardless of which user runs it. The one exception is when they're run under a debugger. Allowing users to debug a setuid executable is a security flaw, so setuid programs temporarily lose their setuid-ness under a debugger. This means that you can only get a hax0red[i] shell when your sploits are ran outside of gdb. However, if you get a user shell as yourself when executing your sploit inside gdb, you should get a hax0red[i] shell outside of gdb.
Linux/Mac:
To generate the key-pair run the following:
ssh-keygen -t ed25519 -f <fileWhereYouWantKeyStored>
To use ssh (after we have created your account):
ssh -i <path_to_private_key> <groupAccountName>@cs342.wellesley.edu
Windows:
To generate the key-pair use PuTTYgen. It comes installed with PuTTY.
1) Open PuTTYgen
2) Select the type of key as SSH-2 RSA
3) Click Generate and move the mouse around to generate entropy
4) (Optional but recommended) Enter a Passphrase + Confirmation of Passphrase
5) Click save the private key
6) Copy the text of the public key to post/email from the box at the top
To ssh (with PuTTY):
On the left side, select Connection->SSH->Auth. In this pane, browse to your private key, and then login as usual. You may want to save the session for a quicker login next time. (Note, if you generated your ssh key pairs using Linux and you want to use it in windows, you will need to use PuTTYgen to convert it from .pem to .ppk before using it)
When you submit your signup form, please double check that your answers are free of typos to minimize any delays. Also, do NOT send the private key! For reference, here is an example of a public key -- the key you paste into the form should look something like this, but with different values.
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHR74yVPL/vafhUrcKRNXy8e42wYqgMFLhkGx0gIPtgP user@localhost
I suggest that you keep the private key on your cs.wellesley.edu server account. That way, you can always access the assignment server by sshing to your Wellesley CS server account, and then from there, sshing again to the assignment server. You can also add new public keys for your other group members, by pasting them into the ~/.ssh/authorized_keys file in your group's cs342.wellesley.edu account.
Some resources, many classic, which you may want to peruse. See if they’re helpful to you, and use them if they are. If you don't find them helpful, don't use them!
Buffer overflows: Aleph One's "Smashing the Stack for Fun and Profit."
Format strings: Read scut's "format strings" paper. You may also wish to read http://seclists.org/bugtraq/2000/Sep/214.
Double-free/malloc attacks: http://phrack.org/issues/57/9.html
You may also want to check out Chien and Szor's "Blended Attacks" paper. These readings will help you have a good understanding of what happens to the stack, program counter, and relevant registers before and after a function call, but you may wish to experiment as well. It will be helpful to have a solid understanding of the basic buffer overflow exploits before working on or reading about the more advanced exploits.
I find this blog post very useful: https://eli.thegreenplace.net/2011/02/04/where-the-top-of-the-stack-is-on-x86/
I recommend using cgdb instead of plain old gdb to debug your exploits. cgdb allows you to see the source code of the programming you’re debugging.
cgdb should become your friend in this assignment -- you will use it to figure out what's going on and to determine the addresses you need to use in your exploit. Check out http://csapp.cs.cmu.edu/2e/docs/gdbnotes-x86-64.pdf for a cheatsheet of commands. Some commands you may find particularly useful include...
run
x
print &buf
info register
info frame
break target0.c:main
catch exec
step, stepi
Make sure that your exploits work within the remote environment provided.
Start early! Theoretical knowledge of exploits does not readily translate into the ability to write working exploits. Target1 is relatively simple and the other problems are quite a bit more complicated.
Aleph One's "Smashing the Stack" piece gives code that calculates addresses on the target's stack based on addresses on the exploit's stack. Addresses on the exploit's stack can change based on how the exploit is executed (working directory, arguments, environment, etc.); in our testing, I do not guarantee to execute your exploits as bash does. You must therefore hard-code target stack locations in your exploits. You should not use a function such as get_sp() in the exploits you hand in.
Your study sheets should be posted to Piazza.
Your exploits should just live in the sploits/ directory. You don't need to do anything to submit them, because I have root on the server we're using, so I can read them from my account.
Your individual reflections should be submitted as a single PDF to the CS342 Dropbox here: https://forms.gle/wREajXYhdNyGznwT8
This project was originally designed for Dan Boneh and John Mitchell's CS155 course at Stanford, and was then also extended by Hovav Shacham at UCSD. It has been used for a number of years, with variations, in CSE 484 by Yoshi Kohno and Franzi Roesner at the University of Washington, and now is used with further enhancement here in CS342. Thanks Dan, John, Hovav, Yoshi, and Franzi!