Computer Systems Security: Winter 2018 Experiences

From Soma-notes
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

You are expected to complete nine experiences throughout the semester. Below is a list of suggested experiences; note that you are welcome to do others, so long as the material is related to class. Your experiences should take 2-4 hours to complete, and you should spend 15-30 minutes writing up your experience. Note that you should do at most 4 experiences in purely offensive technologies (e.g., playing with exploits).

All experiences should be submitted by the last day of classes (April 11th) via cuLearn. If you require more time, please email Prof. Somayaji (anil.somayaji at carleton.ca) to ask for an extension. When you do, please outline what experiences you plan to do and your schedule for completing them.

The list below is simply a list of suggestions. Please feel free to propose other experiences on Slack. Remember that success in not a requirement for any experience. Do your best in 2-4 hours, and if you don't succeed in your chosen task/don't understand completely what you read, explain the challenges you faced in your write-up.

You may expand any experience into two experiences if you end up putting more than 4 hours of work into it. If you do so, then please submit two separate write-ups, with each discussing a different part of your work. If you can't figure out how to split up your writing, you probably should just submit one experience.


Thinking

Common Tools

List computer security tools/mechanisms that you use on a regular basis. For each item, indicate with a * if you believe you have a poor understanding of how it works or what its true purpose is. (If you think you understand it reasonably well, just list it without a *.)

Doing

Replacement passwd program

Try to write a replacement for passwd that is standard on most UNIX-like systems (such as most Linux distributions). Your program can be written in any language; if you write it in a scripting language, however, you may have to use a C wrapper in order to make it work as setuid root.

Creating a properly hashed password may be tricky; as a stepping stone towards passwd, try writing chsh (change shell) or chfn (change finger information).

You only need to provide basic functionality. The only command line argument your program must take is an optional username. Note that your passwd program should only allow root to change an arbitrary user's password; otherwise, it should only allow changing of the password for the current user.

Optionally, try to drop all unnecessary privileges. You may need to install libcap (libcap-dev on Debian/Ubuntu systems) so you can use cap_get_proc() and cap_set_proc().

Setuid root binaries and capabilities

Choose at least four setuid root binaries, each of which requires a distinct set of Linux capabilities. Below is a sample list: 

passwd
mount
ping
sudo

You can look at alternatives, e.g., su instead of sudo, but don't look at both as they require similar capabilities.

For each binary, determine what capabilities it requires to function properly. How can you figure this out without reading the source?

Try removing the setuid bit from the file and replacing it with file-based capabilities using setcap. Can you get it to work as before?

Can you create a program that, given one capability, is able to get other capabilities that it wasn't explicitly given? Which capabilities are useful for getting other capabilities?

Restricting network access

It is possible to restrict network access using application-specific configurations, generalized userspace restrictions (e.g., TCP wrappers), host (kernel) level firewalls, and network firewalls.

For a specific application or protocol, implement rules to restrict access at the application, host, and network levels. Verify that your rules are working properly, i.e., that the protocol is being blocked where you think it is being blocked.

Once you've implemented a complete block, implement a partial block (e.g., allow some hosts and restrict other hosts).

Note that while you can do this exercise in a virtual environment, it is probably easier to do it on a regular network you control (e.g., a home network).

Network Monitoring

Use a network monitoring tool such as Wireshark and capture traffic from a computer that you use over one hour, while you are actively using it. (Please only capture traffic from your own system, as you can compromise the privacy of others with this experience.) In this traffic, try to identify the protocols and purposes of the traffic. How much information is being sent in the clear? How much is encrypted? How much is surveillance, and how much is directly related to what you were using the computer for? It may help to compare this traffic with a separate capture from a time when the computer is not being used.

(If you get too much traffic in an hour, feel free to instead analyze multiple shorter periods of time, e.g. 3 5-minute sessions.)

Web Security

Demonstrate a web security vulnerability (such as cross-site scripting, cross-site request forgery, SQL injection, or others) in a web application that you control and are authorized to modify and administer. In general, this means it should be a web application that you've installed on one of your own boxes for this experience. You can either use a known-vulnerable application (e.g., a web application that is designed to teach web security), you can modify an application to be vulnerable (e.g., write or modify a simple web app so that it has a vulnerability), or you can try to find one in an existing application. Once you have demonstrated the vulnerability, show how it can be fixed.

Code Injection

Perform a code injection attack against a program. You can follow aleph one's original instructions (for 32-bit x86), or you can use a newer one. You will likely have to disable your OS's built-in protections to get it to work.

Intrusion Detection

Setup and run an intrusion detection program on a host or network you administer. Bro and Snort are good choices, but other systems are also allowed (even commercial ones). Setup and run the system for at least a few days. How did you configure it? Do you get any alarms? Did you find any interesting problems with your network, security or otherwise?

Secure DNS

Configure a system to use secure DNS of some variety. How can you tell if it is working? How is the performance? Optional: Can you see a difference in network traffic with a network capture tool such as Wireshark?

Reading

For reading experiences, plan to spend more time on your writeup. Please discuss what you got out of the readings, e.g., what you learned, what you found surprising, what was hard to understand. Please DO NOT summarize the readings; report on your experience instead!

You may propose to read groups of papers on other topics. For most, however, you should probably split your efforts between reading and implementation (e.g., read about a technology and then play with it).

Foundational Security Papers 1

Foundational Security Papers 2

Choose your own papers

Choose between 2 and 4 papers from major security venues that are related to each other. A good set of papers would be a series of attack and defense papers, e.g., paper 1 describes an attack, paper 2 describes a defense against the attack, and paper 3 shows a way to bypass the defense. An easy way to find such papers is to pick one paper published in a major security venues over the past 5 years (IEEE Symposium on Security and Privacy, ACM CCS, NDSS, USENIX Security) and then read 2-4 papers that it cites that are closely related to the paper.

Retrieved from "https://homeostasis.scs.carleton.ca/wiki/index.php?title=Computer_Systems_Security:_Winter_2018_Experiences&oldid=21627"