Project Goal

The goal of your project is to either develop a safe library that prevents a vulnerability class that was studied in class or to develop an automated exploitation tool that will automatically exploit a vulnerability in a vulnerability class.

Personnel

Each project group will consist of either one or two people.

Project Ideas

Prevention

Size-aware overflow functions

Goal: Provide a security library that prevents buffer overflow attacks by augmenting malloc and traditional overflow functions to keep track of the size.

Languages: C

Interface: LD_PRELOAD

• malloc: To keep track of size of all pointers (I believe this is already done)

• strcpy and other overrun problem: Extract the size from the pointer (if it was done using malloc), check that size is appropriate

Stretch: How can this be implemented with stack-based buffers? Perhaps automatically translate from stack-based local variable to heap?

Format Strings

Goal: Provide a security layer that prevents format string vulnerabilities by hooking the printf family of functions to filter dangerous format strings.

Languages: C

Interface: LD_PRELOAD

• printf family of functions: Remove all possible combinations of %n characters from the format string

Stretch: How can this be extended to also prevent information leakage vulnerabilities from the format string?

This project is simpler implementation-wise, so this project will also need to deliver three distinct programs that contain a format string vulnerability, along with a reliable and repeatable exploit for the vulnerability.

XSS Prevention

Goal: Provide a security layer that prevents XSS vulnerabilities. Your solution should require minor modifications to a PHP program to implement.

Stretch: Extend this project to prevent context-sensitive XSS vulnerabilities.

SQL Injection Prevention

Goal: Provide a security layer that prevents SQL Injection vulnerabilities. Your solution should require minor modifications to a PHP program to implement.

Stretch: Extend this project to prevent second-order SQL Injection vulnerabilities.

Exploit

Automatic Buffer Overflow Exploitation

Goal: Develop a tool that will automatically exploit a given buffer overflow. Design a vulnerability description language (a way for a human to describe a vulnerability), then develop a tool that takes in this vulnerability description language along with the binary and automatically performs the exploitation.

Stretch: Extend your project to work on x86-64 bit applications.

Automatic Format String Exploitation

Goal: Develop a tool that will automatically exploit a format string vulnerability. The tool should accept a binary, a way to describe which input to the binary is vulnerable, and a way to describe the output of the format string. The tool should then automatically perform the format string exploitation with no user input.

Stretch: Extend the project to work on x86-64 bit binary applications.

Automatic and Precise XSS Payload

Goal: Develop a tool that will automatically generate a precise XSS payload. The tool should analyze if user input is used in the resulting HTML page, and, if so, using a model of the browser’s parsing engine, the tool will generate the input that will transition the browser’s parsing engine to a JavaScript execution context.

The input to the tool should be the user input and the resulting HTML page.

Stretch: Automatically integrate the tool with a crawler such as w3af.

Blind SQL injection

Goal: Develop a tool to automatically extract the database contents from a given blind SQL injection. This blind SQL injection will be the vulnerable URL, the vulnerable user input, the result of the URL on success and the result of the URL on failure.

Stretch: Augment your tool to take in an option to use the timing blind SQL technique.

Propose your own project

We are open to project suggestions. The project should fit the scope of the other projects.

Project Registration

Register your project by 4/9/16 on or before 11:59:59pm MST.

The link to register the project is already distributed through the class Google Group.

Project Evaluation

Projects have test cases that your project should pass. Most of the attack-based projects can use the test cases of the prevention projects, except for the precise XSS project.

The test cases are designed to guide you to think about your project. If your approach does not work on a test case, you should explain exactly why that is in your report, and furthermore you should explain on what classes of applications your approach will or will not work. This is an important part of the project: you should understand the tradeoffs in the approach that you took. If you develop additional test cases, please submit those with your project report.

Ideally, your project would require no changes (except for configuration changes for files locations and/or database credentials) to the applications for the developer to apply. You should document in your report the extent of the changes that a developer must make to use your security library (for the prevention projects) or the requirements for a security analyst to use your attack tool (requirements either due to type of vulnerability or input to your attack tool).

Your project should also not cause problems or alter the behavior of the application. If it does, you should document what classes/types of applications will be changed and how.

If your project is designed for another language/database, then you are expected to create your own test cases. Please submit these test cases along with your project.

In addition, each project must have (at least) 2 page PDF report (standard 1 inch margins, Times New Roman font, single column, double spaced) on:

Describe the problem that you are solving
Describe the approach you took to implementing the project
Describe what a developer or security expert must do to use your approach
Describe the limitations of your tool: What types of applications can it be applied to?
Describe the future work that you can see which would improve your tool.

Project reports, project code, test cases, and documentation on how to compile/run your tool (a text README file is best) are due 4/29/16 on or before 11:59:59pm MST.