Project 6: Introduction to Cybersecurity

CMSC 330, Fall 2017 (Due December 11, 2017)

Ground Rules

This is NOT a pair project. You must work on this project alone.

Introduction

Congratulations! Youve just been hired by EPSILON a social media startup that looks suspiciously like Twitter. Through some miracle, the founders have managed dupe investors into funding the company. You werent hired as a penetration tester, but it becomes abundantly clear that there are massive security issues with the site. Since this is a startup, of course they cant afford to hire a security specialist to fix these issues. Youre a novice when it comes to security, but its your job now!

Running the Project

Locally

We highly recommend running the application locally. Resort to Grace only if you cant get it running locally. Setup early so you can go to office hours in case you get stuck. Dont wait until the last minute to install.

• Run bundle install in the project root directory. If you get a permissions error run with sudo .
• Run ruby main.rb .
• Open http://localhost:8080/ (or to your workspace-specific URL on Cloud9). You should see the site.

Remember to restart main.rb after changing controller.rb . Depending on your local configuration you may have to do some of the following:

• If you dont have bundler, use gem install bundler (on Bash for Windows 10 you need to specify the full path when you call bundle which can be found with gem which bundler ).
• If you dont have SQLite3, use sudo apt-get install sqlite3 .
• If youre getting an issue where Ruby headers cannot be found run sudo apt-get install ruby-dev .
• If youre getting an issue where sqlite.h is missing run sudo apt-get install libsqlite3-dev .
• If bundler cant continue when installing SQLite3 and youre using macOS, upgrade your version of Ruby (we recommend using RVM ).
• If bundler cant continue when installing SQLite3 and youre using Linux, try sudo apt-get install build-essential patch followed by sudo apt-get install ruby-dev zlib1g-dev liblzma-dev .
• If youre running on Cloud9, run ruby main.rb -o $IP instead of just ruby main.rb .

Grace

N.B. If youre using macOS, run the project locally. Grace wont work. If Grace is having issues, we recommend using the Linux VM .

• Log into Grace using ssh -Y <username>@grace.umd.edu .
• Run bundle install --path ~/.gem in the project root directory.
• Run chrome & . You will be able to access the site from this browser window.
• To run the web server, run ruby main.rb . Youll notice in the output that Sinatra has taken stage on PORT_NUMBER_HERE.
• Take that port number and direct your browser to http://localhost:PORT_NUMBER_HERE/ .

Remember to restart main.rb after changing controller.rb .

Files

There is only one source code file that you will ever need to look at, fathom, and make changes to: controller.rb . This file contains the core back-end logic, and it is also where the web apps vulnerabilities may be found and fixed. You will also be required to interact with and modify the database (which is stored in data.db ), but you will do this through the databases top-level sqlite3 .

• Ruby file (you should edit)
  • controller.rb : All your modifications should be made to this file.
• Database file (you will edit with SQLite top-level)
  • data.db : The database is housed in this file.
• Provided files (no need to edit, changes will be overwritten!)
  • public/ : This directory contains all the resources the front-end needs to run.
  • views/ : This directory contains all the HTML files.
  • main.rb : This is the driver file that runs the web server.
  • Gemfile : This file contains a list of project dependencies (the server, the database, etc.). These all happen to be Ruby gems, and bundling them into a Gemfile allows us to install them all at once by simply running the command bundle install in the same directory.
• Submission Scripts and Other Files
  • submit.rb : Execute this script to submit your project to the submit server.
  • submit.jar and .submit : Dont worry about these files, but make sure you have them.
  • pack_submission.sh : Execute this script to zip your project for web submission.

Part 0: Preliminaries

The application is separated into three components:

• The front-end which consists of all the HTML and CSS required for rendering the page. You wont have to worry about this at all.
• The back-end which handles all HTTP requests. You will mainly be working on this component.
• The database which persistently stores information. You will also makes some modifications to this.

When a user requests a page (HTTP GET), main.rb will display the appropriate page and request all necessary data from controller.rb . When a user submits a form (HTTP POST), once again methods in controller.rb will be invoked to modify the database.

This projects back-end (written in Ruby in the file controller.rb ) is vulnerable to exploitation. Your job is to identify and fix as many of the vulnerabilities as possible. Identifying these issues will require recalling some of the vulnerabilities discussed in class, as well as using your own common sense. This will require playing with the site, thinking like an attacker, and trying as hard as possible to break things. Of course, youre also expected to fix the issues once youve found them.

The only code you will be modifying is in controller.rb . If youre interested in how the application works, you may check out main.rb , but this is not necessary. You will also be modifying data.db through the sqlite3 top-level.

Part 1: Patching Exploits

In the real world, no one will tell you what vulnerabilities are present in your application. So neither will we. However, here is some advice:

1. Play with the site. Spend a good bit of time just interacting with it and understanding the pages and how it works.
2. Walk through the code. Since weve written most of the application you need to understand whats already there. Make sure you understand all the methods in controller.rb and how they fit within the site. The inline documentation should help with this.
3. Try breaking things. Wreak havoc! Be destructive! You will find some rather obvious issues, but also some more subtle ones. Remember the types of exploits discussed in class and discussion. Make note of your findings. Your knowledge of controller.rb should be helpful in finding possible exploits.
4. Start fixing. Enough said.

Here is an index of the vulnerabilities weve learned about. This is not meant to be exhaustive, nor does it mean that all of these exploits are relevant to this project. Its just to refresh your memory.

• Buffer Overflow
• Shell Injection
• Path Traversal
• SQL Injection
• XSS
• CSRF

Part 2: Password Hashing

Keeping passwords safe is critical for any application. Unfortunately, our application stores passwords in plaintext. You must rectify this.

1. Use the sqlite3 top-level to augment the Users table in data.db with a column named Salt.
2. Modify the application to utilize hashing and salting. You must store the hash in the password column, use the Digest::SHA256.hexdigest hash function, and compute your hashes by concatenating the plaintext password and salt together (in that order).
3. Migrate your existing users so their passwords are secure too.

Below are some useful SQL commands. You can see this SQL cheatsheet for more commands.

• SELECT * FROM table;
  • Description: Returns all records in a table.
  • Example: SELECT * FROM Users;
• ALTER TABLE table ADD COLUMN column type options;
  • Description: Adds a column to a table.
  • Example: ALTER TABLE Students ADD COLUMN Hometown varchar(20);
• UPDATE table SET column1 = value1, column2 = value2, ... columnk = valuek [WHERE condition(s)];
  • Description: Updates data in a table.
  • Example: UPDATE Students SET LastName = 'Jones' WHERE StudentID = 987654321;

Project Submission and Grading

This project will be graded out of 100 points.

• Semi-public Tests (20 points). You can submit as many times as you want, but are not provided with the test cases.
• Release tests (80 points). Dont worry though! Instead of the usual 3, you will be given 5 tokens which regenerate every 12 hours.

Be sure to follow the project description exactly! Your solution will be graded automatically, so any deviation from the specification will result in lost points.

You can submit your project in two ways:

• Submit your files directly to the submit serveras a zip file by clicking on the submit link in the column web submission. Then, use the submit dialog to submit your zip file containing all of your source files directly. Select your file using the Browse button, then press the Submit project! button. You will need to put it in a zip file since there are several component files. We provide a script pack_submission.sh which you can run to make a zip file containing all of the necessary files.
• Submit directly by executing a the submission script on a computer with Java and network access. Included in this project are the submission scripts and related files listed under Project Files . These files should be in the directory containing your project. From there you can either execute submit.rb or run the command java -jar submit.jar directly (this is all submit.rb does).

No matter how you choose to submit your project, make sure that your submission is received by checking the submit server after submitting.

Academic Integrity

Please carefully read the academic honesty section of the course syllabus. Any evidence of impermissible cooperation on projects, use of disallowed materials or resources, or unauthorized use of computer accounts, will be submitted to the Student Honor Council, which could result in an XF for the course, or suspension or expulsion from the University. Be sure you understand what you are and what you are not permitted to do in regards to academic integrity when it comes to project assignments. These policies apply to all students, and the Student Honor Council does not consider lack of knowledge of the policies to be a defense for violating them. Full information is found in the course syllabus, which you should review before starting.