Sandia Project Part 3 Introduction The previous two parts of the project had you trying to analyze Sandia's network and systems in the face of deception. Now we will give you a chance to attack a system without deception. Dr. Cohen said that he has installed a system with out-of-the-box software on the Sandia network. Your job: try to get root privileges. What is Due You must: 1. Find the IP address of the newly installed system. Explain why you think it is the system in question. How to submit: Put your result, and justification, into a file (text, Postscript, or PDF), named systemid and use the handin program to submit it under sandia3. 2. Submit at least 2 entries from your notebook. An entry is described below. Please identify each part distinctly. How to submit: Put your entries into files (text, Postscript, or PDF), named test1, etc. and use the handin pro- gram to submit it under sandia3. Due Date This is due on Friday, March 15, at 11:59PM. Notebook Entry Format Each entry consists of 3 parts. They are: 1. Hypothesis. What vulnerability are you testing for, and why do you believe it exists in the target? Your hypothesis may be based upon specific characteristics of the target (such as running a particular server), upon knowledge of the operating system (such as it being MonsterOS 3.8, and MonsterOS 3.8 is known to have this vulnerability in its TCP/IP stack), or upon knowledge of the system (such as looking at the source to SDNS, and seeing a vulner- ability in it). Please state clearly what you suspect the vulnerability is, and why. Provide any general information about the target that helped you decide that this particular vulnerability might exist. 2. Testing. State how you will test for the vulnerability, and carry out the test. You can use soneone else's code for the test, but you must make sure it runs, and explain why the program/routine you are using does in fact test the vulnerability. (You have to be specific about your test. You cannot say that "I found Tony's attack tool for this vulnerability at attacks-r-us.com." You need to show how the tool works, and why it will establish whether the vulnerability exists.) 3. Generalization. If your test fails, why did it fail? Are similar tests likely to fail also? Should you look for other types of vulnerabilities? If your test succeeds, what other vulnerabilities similar to this one might exist? Why do you think so? It is perfectly fair for you to turn in 2 related vulnerabilities. For example, one vulnerability may lead you to a gener- alization that suggests other vulnerabilities. If this happens, please document your thinking in part 3, and name the files containing the suggested entries.