Projects 4 and 5: Secure Gradebook

ENEE 457, Fall 2020

Project 4 (Build it) Released 11/1, Due 11/27 @11:59pm
Project 5 (Break it) Target Release date 11/29, Due 12/13 @11:59pm

Overview

A prof and 2 TAs all want to be able to modify a gradebook so they want to store it on a public cloud as opposed to locally. However they do not trust the security of the cloud. Therefore, each time they want to modify the gradebook, they will download it, modify it on their local computer and re-upload it (you may assume that they always download/modify/upload the gradebook one at a time). They will create a wrapper program that is run on their local computers. The wrapper program will have three components (1) setup which will initialize a new gradebook with a specified name and will generate a single key that allows access to the gradebook for authorized parties. Copies of the same key will be stored locally on the computers of the Prof and TAs. (2) gradebookadd, which will allow adding a new student or assignment, or entering a new grade for a student and assignment already contained in the gradebook (3) gradebookdisplay, which provides a few ways in which students' grades can be printed out. Before executing an add or display query, both gradebookadd and gradebookdisplay will check whether the gradebook has been modified by an unauthorized party who does not hold the key that is associated with the gradebook. If such ``tampering'' is detected, an error message will be printed out.

Your goal is to write a secure wrapper program that prevents an attacker, who does not have the key, from learning information about the contents of the gradebook (privacy) or from modifying the gradebook without being detected (integrity). The threat model assumes that the cloud is fully compromised, allowing an attacker to read or modify any files stored there.

Your program will be evaluated based on correctness tests we run on it, the design document you submit justifying your design choices, and whether other students successfully attack your code during the Break-It phase (In the Break-It phase, you will receive points for a successful attack on other students' implementations, but will not lose points for other students' attacks on your implementation. Extra credit may be assigned (based on the Instructors' discretion) for submissions that perform well during the Break-It phase). During Break-It, a successful attack launched in the above threat model (where only the cloud is compromised) will automatically receive points. Attacks that require access to the local computers of the Prof and/or TAs will be considered on a case-by-case basis. In particular, students need to explain why their attack is made possible by a vulnerability in the gradebook wrapper program itself (as opposed to an attack that is always possible, even when there is no vulnerability in the wrapper program, such as stealing the key). E.g if a malformed input to the wrapper program causes a buffer overflow that can be used to perform code injection, this would be a valid exploit.

You will build the most secure implementation you can; then you will have the opportunity to attack other students' implementations.

You will write your implementation in C. There is some basic starting code available. There are example makefiles available.

Programs

You will design a gradebook format and implement setup as well as both gradebookadd and gradebookdisplay to use it. Each program's description is linked below.

• The setup program generates a key and an empty gradebook with a specified name. The program returns the key to the user.
• The gradebookadd program receives as input the name of a gradebook and a key. The gradebookadd program adds data to a gradebook
• The gradebookdisplay program receives as input the name of a gradebook and a key. The gradebookdisplay program displays data from the log

Sample input/output sequences can be found here.

Please also see the FAQ page.

Security Model

The system as a whole must guarantee the privacy and integrity of the gradebook in the presence of an adversary that does not know the key (i.e. adversary who corrupts the server, but not the local computers of the Prof and TAs). Recall that the key is used by both the gradebookadd and gradebookdisplay tools, and is specified on the command line. Without knowledge of the key an attacker should not be able to:

• Query the gradebook via gradebookdisplay or otherwise learn facts about the names of students, assignments, or grades of individuals by inspecting the gradebook file itself
• Modify the gradebook via gradebookadd.
• Fool gradebookdisplay or gradebookadd into accepting a bogus gradebook file. In particular, modifications made to the gradebook by means other than correct use of gradebookadd should be detected by (su bsequent calls to) gradebookadd or gradebookdisplay when the correct key is supplied

Deliverables

Project 4: Build it

You should submit via Canvas:

• Your implementation, including all your code files and your makefile in a single .zip file will be submitted through Canvas.
• A design document (PDF) in which you:
  • Describe your overall system design in sufficient detail for a reader to understand your approach without reading the source code directly. This must include a description of the format of your gradebook.
  • List four specific attacks you have considered, and describe how your implementation counters these threats. (Please note the relevant lines of code for your defense.) If you were not able to completely (or at all) prevent a threat you identified, you may still mention it. In that case, describe any partial mitigation you implemented and explain anything you wanted to implement but were for whatever reason unable to. Please be clear about distinguishing what you have implemented vs. what you would have implemented.
• Name the .zip file as x-project4.zip and the design document as x-project4.pdf, where x is your first and last name. For example, if your name is "Jane Doe," you should be handing in two files named "JaneDoe-project4.zip" and "JaneDoe-project4.pdf."

Project 5: Break it

We will assign you three students' implementations to examine. You should submit via Canvas:

• A vulnerability analysis document (PDF). Choose one of your assigned implementations and describe:
  • Any attacks you found, including a high-level summary and enough detail for someone to replicate the attack
  • Any vulnerabilities you found but were unable to exploit for whatever reason.
  • If you did not find any attacks or vulnerabilities, describe how you looked for attacks.
• Also submit any code you wrote to implement your attack, included in a single .zip file. Make sure the vulnerability analysis explains how to use your code to launch the attack.
• Name the .zip file as x-project5.zip and the vulnerability analysis document as x-project5.pdf, where x is your first and last name. For example, if your name is "Jane Doe," you should be handing in two files named "JaneDoe-project5.zip" and "JaneDoe-project5.pdf."

If you demonstrate a working security break, then your vulnerability analysis document only needs to include your description of that one vulnerability, you don't need to go any further.

If one of your assigned implementations doesn't work well enough to analyze, please request an alternate implementation from an instructor.

Grading

Project 4 will be worth 100 points:

• 50 points for the automated correctness tests.
• 50 points for your design document:
  • 10 points for your description of your approach
  • 10 points for each of the four specific vulnerabilities you defend against. For maximum points, your defense should be correct, fully implemented, and well explained. Well explained attacks that are not fully implemented will receive partial credit.
  • Extra credit (non-refundable as always) will be permitted for one extra attack/countermeasure beyond the original four.

Project 5 will be worth 100 points:

• A successful attack with a well written vulnerability analysis will receieve full credit.
• If you do not have a successful attack, then you must write a complete vulnerability analysis for one of the three implementations you were assigned. This analysis must explain either why you could not implement the attack you identified, or provide a convincing argument that there were no exploitable vulnerabilities.