Due Monday, January 1st
Worth 85 points
Listed above are 3 port numbers. Those 3 port numbers are running services that you must exploit. The first is easy, the second is medium difficulty and the third is intended to be hard.
If you do not see those ports, please log in by clicking the "Login" at the top right of this page.
These services are running on
netsec-projects.cs.northwestern.edu. You can view the source code on any machine within the directory
netsec-projects is firewalled, and the ports are only accessible from
hamsa. In order to check if your code works, you should run your code from
We recommend consulting people working on the same vulnerability, but we expect that you will write the exploit yourself.
Points are broken down as follows:
- Exploit 1: 15 points
- Exploit 2: 30 points
- Exploit 3: 40 points
If you need to review the relevant Metasploit commands, check here: http://hamsa.cs.northwestern.edu/readings/metasploit-basics/
Metasploit is only available on hamsa (not on the VMs).
Useful gdb Command
set follow-fork-mode child: All of the services fork a new process after accepting a new TCP connection. This will allow you to debug the new process, which is what you want.
How to Start Debugging
(1) Copy all the necessary files to your own directory on netsec-playground
(1.5) Consider running
make clean, just in case.
(2) run ./configure and generate Makefile
(3) modify Makefile to add
-g option to
-DPORT in Makefile to avoid conflicts with other users
(5) Run make to build the program
set follow-fork-mode child to make sure that gdb will follow the child process
nc netsec-playground port_number (Or use metasploit, but make sure your breakpoint is after all input is handled or you will get a SIGPIPE)
(9) Debug until you can jump to an arbitrary memory address
(10) Run your metasploit module from hamsa on netsec-projects
Tips After Starting
The easy program should be a simple buffer overflow.
The medium program will involve some more complicated pointer manipulation and stack writing.
The hard program should be tricky. Once you get the trick, the overflow should be easy again.
If your module is not overwriting the return address correctly:
- Are you overflowing the buffer?
- Is your shellcode too big for the buffer and overwriting the return address?
- Is there a canary you need to preserve?
- Is the return address not aligned on the same four bytes as your overflow?
[-] Exploit failed: No encoders encoded the buffer successfully.means (in most cases) the selected payload cannot fit in the specified sized buffer. Adjust
If your module can jump to the right address but you can't get a shell:
- Are you running off the top of the stack?
- Is your step size bigger than your nop sled?
Did you delete the
handlerpart of the template?
If you can exploit netsec-playground and not netsec-projects:
- The return address may be further up the stack on the latter which may affect how you design your payload.
- Sometimes sock.get will affect the timing of your exploit. If you are ignoring all the output that is sent to you (i.e., never calling sock.get), consider adding this call anywhere you are waiting to here from the service.
It is possible that your shell is being closed before metasploit can recognize it. This varies by port number and by payload and is not intended. Try a few different payloads or submitting if you are convinced your code is correct. Another trick to verify an exploit is working: try using an exec payload with
ls. If your exploit works you will see
[*] Sending stage (38 bytes). If that is successful, try a different shell payload and one of them will work. Because of this, you may have to submit multiple times to get credit for your exploits.