Sandia Project Part 2

Introduction

The Sandia project has 4 goals for each part. The goals, in brief, are:

1.	Locate, identify, and characterize all of the computers in the network (by reporting their IP addresses, type, and 
any other characteristics).. 

2.	Deny services in a controlled and repeatable manner to the user box or DNS server.

3.	Gain access to the user box so that you can cause desired changes on it.

4.	Same as 3 except for the secure DNS and the protected server(s).

The project description handout gave more details.

What is Due

You must:

1.	Submit a list of the IP addresses and operating system types of the Sandia machines you have found (other than 
the login server). Justify your claim about the operating system; why do you think that system a.b.c.d is running 
MonsterOS 3.7?

	How to submit: Put this information into a file (text, Postscript, or PDF), named appropriately, and use the han-
din program to submit it under sandia2.

2.	Submit at least 4 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 through test4, and use the han-
din program to submit it under sandia2.

Due Date

This is due on Friday, February 15, at 9AM.

Notebook Entry Format

Each entry consists of 3parts. 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 4 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.

Note

Please do not reuse the data from part 1. The network and systems have probably changed, so simply begin anew. You 
may of course use the knowledge, tools, and techniques you have gained from the first part -