One of the goals of this class is to teach how to analyze the security of systems. The penetration test is a powerful a posteriori testing technique that examines not only the design and implementation of a system but also its maintenance and operation--the latter two often being overlooked in a priori evaluations (because the system is not yet fully operational, or is not yet in its production environment).
A proper penetration test devises specific goals that the testers are to achieve. Examples of such goals are to acquire root access on a UNIX system, to read a specific file, to create or delete a specific file, or to block access to the system for some period of time. The goals vary depending upon the security policy of the site and upon the reasons for the test.
We will use the Flaw Hypothesis Methodology for this study. The project grade does not depend upon achieving the stated goals It depends upon the correct implementation of the Flaw Hypothesis Methodology. You are required to keep a notebook to demonstrate that you are using the methodology. If the notes show what you thought of, tried (and how it was tried), the results, and any ideas that spring from the test, you will get a good grade. If the notes do not show this, you will receive a bad grade even if some of the goals of the test are met. In other words, your grade depends upon your use of the methodology.
This class section will analyze a set of systems implementing a controller designed to provide service even when intrusions occur. Although breaking into the systems is of interest, so is merely inhibiting their response. So this should be a fun exercise!
You are required to follow certain rules. If you break the rules, we can (and will) take appropriate action, up to and including removing your access to the Teknowledge systems and filing a complaint with the SJA. For whatever it is worth, we have never had to do this before, and I'd like to keep this class' good record intact. So, your classmates, the teaching assistants, the researchers at Teknowledge and the UC Davis Computer Security Laboratory, and I would appreciate your cooperation.
You are being granted access to a portion of the Teknowledge network at Teknowledge Corporation for the purposes of this course. You will be given an IP address, a user ID, and a password. Use there as your exclusive means to access the systems.
You will only be able to reach the Teknowledge systems by using SSH to enter a secure login server (more on this below). Please do not proxy back X11--use this SSH connection only for terminal sessions and securely copying files. This is necessary because 70 students proxying back X11 will make the connection to UCD collapse.
Think of access to the login server as insider access to the network under attack, obtained from an insider who has loaned you her computer so you can break in. The login server is not to be attacked in any way by your teams because it is a shared resource for your classmates.
The exercises for this class are part of an experiment that Teknowledge and the UC Davis Computer Security Laboratory are running. Your actions on Teknowledge systems will be monitored, and the researchers may use those actions and the results of those actions in their work. Your names will not be used for any purpose except to grant you access to the computers, or to take action if you break the rules.
The goal of the HACQIT project is to "provide four hours of intrusion tolerance with no more than 25% degradation of aggregate user performance."1 The project divides servers into two classes: critical and non-critical. HACQIT is concerned only with the critical servers.
The figure below shows the arrangement of the HACQIT network. You will connect to the Teknowledge network from one of the CSIF systems. This puts you onto a login server ("staging computer" in the diagram above). The targets will be the HACQIT cluster and the paths between that cluster and the critical users. The HACQIT web server connected to the enclave LAN will be used to monitor the attacks and provide mechanisms for you to ask questions of the HACQIT administrators. Do not attack that server! You get no credit for doing so, and will cause everyone in the class problems and make them very unhappy. So please be courteous!
The HACQIT cluster is illustrated in the figure below. The firewall (FW) controls access to the LAN. It implements a virtual private network (really, an encrypted tunnel) between the critical user and the HACQIT cluster. The primary and backup servers provide the desired services. The monitor and adapter control the servers, and have an out-of-bands communication channel so the services (and defenses) can be reconfigured dynamically as needed. The sandbox contains a duplicate of the primary and backup servers, and is used to determine whether failures are transient or the result of an attack, and whether a request will cause an error.
The cluster will be shutdown for daily maintenance each morning and, if needed, at other times. Information on LAN and cluster status will be posted on the HACQIT web server on the test enclave LAN, which (again) is not to be attacked.
Finally, the HACQIT system is still under development. It's very far along, and we do not expect problems. But, unexpected problems may occur. If that happens, please notify the HACQIT team at email@example.com, and bear with them as they fix it.
We will discuss the Flaw Hypothesis Methodology in class. It is also covered in the textbook (see section 19.2.4), Your notebook must document your use of this methodology. It should consist of four types of entries.
These entries document things you have learned about the system. For example, if you establish that the server is an SCO system, you would create an entry saying that and explaining how you know it is an SCO system. Your observations may either be used to reach one of the goals, or to provide background information of other entries.
These entries document suspected vulnerabilities in the system. In addition to the hypothesized vulnerability, you must say why you think the vulnerability might exist (for example, the system is a Linux Red Hat 6.2 system, and the vulnerability is known to exist for that system). You also have to say what the consequence of the vulnerability would be (for example, if this buffer overflow in the setuid to root program succeeds, you can execute an arbitrary program and thereby get access to root). Indicate which goal (or goals) the hypothesized vulnerability would help you achieve.
Choose at least 10 hypothesized vulnerabilities and design tests that will tell you if the vulnerability exists and is exploitable. You do not need to exploit the vulnerability for the test (although many times that is the only way to test). You must be able to carry out the test. For example, you cannot say, "the system administrators should check the contents of the protected file /etc/errors, and if the contents of that file begins with `abracAdabra' the system is vulnerable." If you can't read the file, you'll have to devise some way of testing whether the file contains what you think. One way is to try to exploit the vulnerability ... you get the idea.
Document each test in detail. We will need to be able to repeat it. For each test, document the relevant parts of the system and environment settings, the arguments to the program, the input, and the output, and any relevant side effects (like creating s setuid-to- root shell).
Some of the tests you documented in the previous entries will succeed. Others will fail. From this, you may get ideas for other vulnerabilities, or be able to generalize to find new vulnerabilities. For example, if a buffer overflow allows you to obtain root privileges, and the bug is in a library call, check other programs for use of that library call. They are also vulnerable, in all probability. Document any generalizations, and hypothesize new vulnerabilities based upon them.
The penetration exercise will proceed in stages, each stage being approximately two weeks. Initially, the system will be fairly open. Successive stages will tighten security. This way, you will be able to become familiar with the system as you proceed through the stages. You will be required to submit your notes at the end of each stage.
In this stage, you will have full access through the firewall from the login servers on the enclave LAN. For this stage, you should not try to penetrate anything. However, you can gather information for future use.
If you notice that the login server(s) for the class is (are) overloaded, crash, or have other problems, please notify the HACQIT team test administrator at firstname.lastname@example.org.
This stage allows attacks against a relatively open system. The HACQIT system, enclave LAN, and critical user workstations will have no significant change from stage1. The HACQIT cluster firewall will only allow traffic through the VPN, and the personal firewalls on both critical user workstations will be left open.
This stage allows attacks against a less open system. In this stage, student user accounts on the firewall for the VPN will be removed, thereby removing your access to the VPN. But the critical user workstation firewalls remain open.
This stage has the HACQIT cluster fully operational. The critical user workstation firewalls will be configured to the settings for a fully operational system. During this stage, additional systems may be added and the configuration changed. Notices of these changes will be posted to the HACQIT web site.
For this project, you will need to work in teams of 2. You must pick someone in your own section to work with (the other section is doing a different penetration study). Once you have selected your team, please email the team member names and email addresses to email@example.com. Members of a team may exchange information freely; the project is their joint work. However, different teams may not communicate. Each team works independently of all other teams. This is necessary for two reasons. First, if two teams independently come up with the same vulnerability, they can both use it; were the teams communicating, there would be questions of priority that we want to avoid handling. Secondly, your efforts will be monitored for research purposes, and a copy of your notes will be sent to the researchers. Collaboration across teams will bias the results and limit the effectiveness of the research.
Information about logging into the Teknowledge login server is available on the class web page. Please go to http://my.ucdavis.edu, sign in, go to the class web page, and from there to projects/hacqit/ids.html.
HACQIT test administrators' email address: firstname.lastname@example.org.
ECS 153, Introduction to Computer Security|
Winter Quarter 2002