Hi class, This e-mail contains a tutorial for fuzzing the toe daemon as well as the requirements for the homework. If you're just interested in the requirements, scroll to the bottom section of the e-mail. FUZZING TUTORIAL After you've used VirtualBox to boot your shiny new VM, you will see that several command prompts have opened. Three of them correspond to software that you will need to run while fuzzing. You can tell which is which by reading the title bars. 1. Target - the program in which you are searching for vulnerabilities 2. Process Monitor - logs crashes when the target crashes and restarts the target when necessary 3. Fuzzer - sends malformed data to the target in hope of crashing the it As an example, we are going to fuzz the toe daemon as demoed in class. We used the fuzzing framework Sulley to help us write the fuzzer. There are two Python files that we created for fuzzing: 1. requests\toe.py - This describes the protocol that the toe daemon speaks. While fuzzing, Sulley will use this description to send valid and invalid data to the toe daemon. 2. fuzz_toed.py - This is the driver for our fuzzer. It tells Sulley that our target is toed.exe, that toed.exe knows how to speak the requests described in requests\toe.py, and that we want to use a process monitor for this fuzz session. To begin fuzzing, here's what you should do in each of the command prompts: Target This prompt is open to the parent directory of Sulley. Start toed.exe running on port 1337: - toed.exe Process Monitor This prompt is open to the Sulley directory. Have the process monitor log all crashes to audits\toed.crashbin and monitor the process toed.exe: - python process_monitor.py -c audits\toed.crashbin -p toe.exe Fuzzer Start sending malformed data to the target. - python fuzz_toed.py To monitor the fuzz session you can open the installed web browser, Browsar, and it should direct you to its homepage at http://127.0.0.1:26000. This provides a nice web display of the status of the fuzzer. Note that the fuzzer keeps track of where it is in the fuzz process so you can kill all of the fuzzing tools and reopen them and they'll resume where they left off. When you've stopped the fuzzing tools or they have finished their job, you can investigate the crashes. The following commands assume you are at a prompt that is within the Sulley directory. To get a listing of all of the crashes and which test cases caused them type: - python utils\crashbin_explorer.py audits\toed.crashbin To get more specific details about a specific crash, you must supply crashbin explorer with a specific test case number. The following will show you detailed information about the crash related to test case 48: - python utils\crashbin_explorer.py audits\toed.crashbin -t 48 There is a mistake in fuzz_toed.py. Line 51 reads as follows: do_single("TOE", int(sys.argv[1])) Replace "TOE" with the request you are interested in (ex: "TOE both", "TOE USERNAME", "TOE REALNAME"). HOMEWORK REQUIREMENTS For the homework, you will be fuzzing the Initech Employee Management System. The binary is located in the same directory as toed.exe. Its only command line argument is the port on which to listen. You can get a description of the protocol from the course webpage (http://www.cs.rpi.edu/academics/courses/spring10/csci4971/fuzzing/protocol.txt). For the assignment, you'll need to write your fuzzer in two Python files. These will correspond to the ones I wrote for the toe daemon (fuzz_toe.py and requests\toe.py). You can use those as a guide. For the assignment, we'd like you to complete the following tasks: - Write a fuzzer (as I did for the toe daemon) for the Initech Employee Management System - Run the fuzzer - Use crashbin_explorer.py to identify the test cases that caused crashes. - Investigate the crashes. For three test cases that crashed the target, find out what data they sent to it. Does this test case by itself crash the target or do you need to send some earlier test cases to put the target into a vulnerable state (do_single() in fuzz_toed.py will be helpful here)? Why do you think this test case is causing the target to crash (it looks like a [buffer overflow, format string bug, etc.] because ...)? To submit the assignment send us your: - fuzzer - crashbin file - analysis of 3 test cases The homework deadline has been extended by one class. It's due on Thursday April 8. It'll be useful to have a list of employees currently in the Initech Employee Management System; Bill Lumbergh Milton Waddams Peter Gibbons Michael Bolton Samir Nagheenanajar Tom Smykowski Nina Hint: If you're having trouble with the SHA-1 fields in HIRE and FIRE, check out encoders, another one of Sulley's Block Helpers. Links: Slides from our Lecture: http://www.cs.rpi.edu/academics/courses/spring10/csci4971/fuzzing.pdf Sulley Reference: http://fuzzing.org/wp-content/SulleyEpyDoc/ Sulley Manual: http://fuzzing.org/wp-content/SulleyManual.pdf As always, e-mail us or stop by office hours if you have any questions. Good luck! ---- Adam Comella