CS 231: Computer Security

Final assignment

Due 5:00PM Monday, November 24, 2014. Submit your answers via Moodle as a zip file containing PDF with your answers, plus any source code or data files you used to obtain your answers.

As noted in class on Monday, November 17, this is no longer an exam. Instead, it is an assignment on which you are free to consult with your classmates, Jeff, and so on. Each of you, however, should write your own code and do your own write-up of the problems. If you take a substantial idea from another person, cite them at the bottom of your PDF.

You may not use a password-cracking utility written by somebody else. Note that this isn't a big hardship, since problem #1's grade will depend more on your answers to the analysis questions than on the "list the passwords" question.

On the password-cracking, please take note of the passlib library described below. This will enable you to restrict your CPU-hogging to the computer you're sitting in front of. I'd rather not be the mastermind of a DDOS attack on thacker.

I have designed this assignment to be interesting (I hope), but also easy to grade. Many of the questions call for simple numerical or short-answer responses. I'm still often interested in "why," of course, but keep your explanations brief and to the point. For example, the password section includes two questions beginning "By what factor...." You'll want to tell me the factors, but also tell me where the factors came from. In both cases, a good explanation should be manageable in a single short sentence.

Given my recent history, the likelihood of errors in this assignment is moderately high. Let me know if you see trouble, and I'll communicate any issues to the rest of the class via email.

Have fun!

  1. Passwords (15 points)

    I have created for you a fictional copy of the /etc/shadow file stored on the mathcs.carleton.edu file system. (Here's the previous copy of shadow from earlier in the weekend. Not that you need it.) Because this file contains a list of actual user names on the mathcs network, I have stored that file in directory only accessible from on-campus IP addresses. The password hashes in this file were made up by me or my handy random number generator plus this dictionary file of English words. (Note that my dictionary file doesn't contain proper nouns. If there are any passwords based on proper nouns, they came from my head.)

    For the present purposes, we will assume that we are working on a Linux system (but see the note at the end of this exercise) that stores its account and password information in /etc/passwd and /etc/shadow, as described here, here, and here.

    So, let's pretend that you got a copy of the /etc/shadow file, one way or another, and now you want to discover as many passwords as possible. Your job is to create a Python program to help you do that, and to report on your results and answer a few questions about the process. I want you to write your code in Python for a couple reasons. First, so I don't have to learn more than Python's hashing library. But also, so your timing results will be reasonably comparable between students. (Note, by the way, that Python is slow, but SHA12-based crypt is intentionally very slow as an algorithm regardless of language, so as to thwart just the sort of cracking you are trying to do.)

    Answer the following:

    1. List all the username/password pairs you were able to discover.
    2. Briefly list the techniques you used to try to find passwords.
    3. On average, how long does it take your program to compute one hash of a candidate password + salt, and compare the result to the corresponding line in /etc/shadow?
    4. In your previous answer, how much of that time was hashing, and how much was comparing?
    5. Suppose our /etc/shadow had used the same string for the salt in every line. By what factor would this speed up your search for passwords?
    6. Pretend you became a professional password cracker, and you decided to develop a high-speed database containing triples (password, salt, hash), searchable by (salt, hash). Suppose you then obtained a giant /etc/shadow file (e.g. from a site with enormous numbers of users, like Facebook), and discovered that they had used the same salt for everyone. By what factor could you reduce the size of your database?

    Call your program "cracker.py", and include it in the zip file you submit.

    Some assistance for you:

    • The username "jondich" has password "m00s3". You can use this information to help you make sure you are doing your hashing correctly.

    • The Python library function crypt.crypt (i.e. import crypt, then call crypt.crypt) will serve you well. This should help.
    • Note that on MacOS, Python's crypt.crypt uses a DES-based MAC that's also weirdly independent of salt instead of one that takes salt into account and is based on SHA-1 or SHA-2. Further, MacOS doesn't use /etc/passwd and /etc/shadow. Thus, to make this exercise make any sense at all, you need to do it on Linux. Not all of you have easy access to Linux systems, so I have asked Mike Tie to get you access as soon as he can. So in short: use a Linux version of Python to execute crypt.crypt for this exercise. Note that thacker.mathcs.carleton.edu runs Linux, so if you have an account there (e.g. for CS 257 in the past couple years), you're already set.
    • But wait, there's more! If you want to work on your own machine instead of thacker, you can download and decompress the passlib library. Put it in your working directory, and then use this code:
      import sys sys.path.append('passlib-1.6.2') from passlib.hash import sha512_crypt h = sha512_crypt.encrypt('m00s3', salt='VLVeCJJ8', rounds=5000) print h
      That should give you the hash string from the shadow file for the jondich username. You can take it from there.
    • These fictional passwords? Some may involve Carleton-related stuff.
  2. Cross-site scripting (15 points)

    1. Go to InsecureLand (hosted at thacker.mathcs.carleton.edu) and create an account. Use a stupid password that you wouldn't ever use in any other context. You don't want to share a good password with InsecureLand, after all.
    2. Look at your browser's cookies from thacker.mathcs.carleton.edu. What do you see?
    3. Change your password (to some other bad password) at InsecureLand and re-examine your cookies. Now what do you see?
    4. While logged in on InsecureLand, search for "moose". What results to you see?
    5. Search for "octopus". What results?
    6. Search for "<span style="color:red">octopus</span>". What do you see?
    7. Open Safari on a Mac, login at InsecureLand, and search for: "goat<script>alert('Hello')</script>" (without those quotation marks). You should be told that InsecureLand can't find goat. Now, right-click on the page and select "Inspect Element". Once you do this, you should see a red exclamation point icon showing (at least) 1 error. Select that error. What does the element inspector tell you about the error?
    8. Disable the XSS Auditor by executing the command
      defaults write com.apple.Safari "com.apple.Safari.ContentPageGroupIdentifier.WebKit2XSSAuditorEnabled" -bool FALSE
      Relaunch Safari and try the goat/Hello search again. Now what happens?
    9. How does the XSS Auditor tell that the alert('Hello') should not be executed.
    10. Don't forget to execute
      defaults write com.apple.Safari "com.apple.Safari.ContentPageGroupIdentifier.WebKit2XSSAuditorEnabled" -bool TRUE
      before you quit. The XSS Auditor is something you want to keep on.
    11. Come up with a search that would email your InsecureLand cookie to you. (You may want to investigate how to send email via Javascript, or how to make an HTTP query via Javascript, which would enable you to invoke a web service that could in turn email the cookie to you.)
    12. Emailing your password to yourself is not very interesting. But explain how you could use the search + Javascript technique above to obtain somebody else's password.
    13. Finally, take a look at the InsecureLand server-side source code, conveniently linked on the InsecureLand page. What could its author do to close up the XSS security hole?
  3. Spying on Jeff (15 points)

    For this exercise, assume that this Wireshark file was obtained at a coffee shop, focusing on the activities of one particular person (let's call him "Jeff"). Your job is to summarize in as much detail as you can what Jeff was up to during this short period of time. In particular:

    1. Identify as many computers as possible (by one or more of IP address, MAC address, DNS name, etc.) that were involved with Jeff's activities.
    2. List the actions Jeff took during the time we have information for.
    3. List any usernames or passwords you can find in the record.
    4. What specific software did Jeff use for his activities?
    5. What non-Jeff-centered activities, if any, are captured in this file?
    6. If you discovered anything else interesting, include it (concisely) here.