Secure Programming Lab 3: Web app security School of Informatics, University of Edinburgh 2pm-5.30pm, 7th March 2014 For this lab we are going to explore web app security vulnerabilities. To do this we are going to use a vulnerable web app called Gruyere from Google’s Code University1. We are going to focus on a few specific vulnerabilities but the app contains more bugs than we can cover in this lab. If you are interested you should go try the full lab available from Google. The code is available from http://www.inf.ed.ac.uk/teaching/courses/sp/2013/labs/lab3/gruyere-code.zip. It can be downloaded and run on your own machine. Once downloaded, unzip it (unzip gruyere-code -d gruyere && cd gruyere) and run python ./gruyere.py in the folder to start the app. It will give you a URL to visit and a session id for the instance you have spun up. The URL will be of the form http://127.0.0.1:8008/1234/ where 1234 is your session id. Follow this URL to start Gruyere. Code for the web pages is written in the Gruyere Template Language. This is a template web programming language created by Google for the lab and the details of it can be found by reading the source code in gtl.py (though this isn’t really necessary for this lab). An overview of the other files is bellow gruyere.py is the main Gruyere web server. data.py stores the default data in the database. There is an administrator account and two default users. gtl.py is the Gruyere template language sanitize.py is the Gruyere module used for sanitizing HTML to protect the application from security holes. resources/... holds all template files, images, CSS; as well as any user uploads. Resetting Gruyere Gruyere is sand-boxed (somewhat) so it can’t be interfered with or consume all your resources; that said it is possible (and in fact encouraged) to put it in a state where you need to reset everything and start from scratch. If this occurs delete the folder containing Gruyere and replace it with a fresh copy from the zip file. 1https://google-gruyere.appspot.com 1 Question 1: Logging in Try signing up for a new account using the Sign up link in the top right. Look at how it passes the parameters for the new account. We will leverage this, with other vulnerabilities, to create a new administrator account. Checkpoint 1. Consider the case where an attacker is listening to network traffic. What is the danger with the account creation method? Checkpoint 2. Create another new account but this time do it without using the Sign up form. Once done login, and navigate to your Profile. This page allows you to edit your account’s settings but administrators have a few more controls open to them. The code used to generate the page can be found in resources/editprofile.gtl. Checkpoint 3. How does the code in editprofile.gtl distinguish between admin users and regular users? Can we use this information to either turn our unprivileged account into an admin one or create a new admin account? Checkpoint 4. To create our admin account we used information we got from the source code. In a real web app an attacker may not be able to do this. Is it likely that an attacker could figure this out how to do this without the source code? Checkpoint 5. Describe how this bug should be fixed. Question 2: Viewing and uploading Part 1: Viewing Log into an unprivileged account again. This time we’re going to try and read and then modify one of the source files: in particular we’re going to aim to read the secret.txt file in the source’s root directory. Relative to the other source files this lives at ../secret.txt. Try using the browser to navigate to http://localhost:8008/1234/../secret.txt (where 1234 is your session number). On most2 browsers this will cause gruyere.py to crash. The gruyere.py script used to start the lab displays the requests it receives as its output. Look at this and note the URL requested before the program crashed. Checkpoint 1. Why does the requested URL differ from the one you typed in? Who made the change? Checkpoint 2. Use netcat (nc) to explicitly craft a request for the file using the correct URL. It should work this time and you should be able to see the file’s contents. Why does it work now? (N.B. this could also be done using curl or even the w3m browser but if you’ve never hand-written a HTTP GET request it is a useful experience.) Checkpoint 3. Describe how this problem should be fixed. Part 2: Uploading Sign in as an unprivileged user again. This time click the Upload link. This allows a user to upload and host a file. We’re going to abuse this to allow us to overwrite the secret.txt file (and in fact any file we want). Try uploading a file now. 2Safari, Firefox, Google Chrome, Opera. 2 Checkpoint 1. Open the resources folder inside gruyere and have a look at where the file was uploaded to. Suppose a usertried to upload a file : where would it be placed? Checkpoint 2. Using what you know about the location of uploaded files overwrite the secret.txt file with something new. Verify your upload worked. Suppose that we can’t create new user accounts3. We can still exploit the upload dialog by uploading a file with an unusual name. You won’t be able to do this with a regular web browser but you can do this with the curl command: have a look at the man page for curl, specifically the options -d and -F. Checkpoint 3. Describe how to overwrite the secret.txt file just by uploading a file with an unusual name. Why won’t this attack work using a regular web browser? Checkpoint 4. Describe how this problem should be fixed. Question 3: Crashing and running In this section we’re going to show how anyone can stop the Gruyere app and also how we can change it to run whatever we want. This question will need you to use your solutions from both previous questions! This question is harder than previous questions and there is less guidance: make sure you have understood them before attempting. Part 1: Crashing Sign in as an administrator, and follow the Manage this server link. Examine what the Quit the server button does. Sign out and try and Quit the server as an unprivileged or unlogged in user. Checkpoint 1. Why can an unprivileged user quit the server like this? How should this be prevented? An alternative way to crash the server is to overload it to the point it becomes unresponsive. This is called a denial of service attack. To do this an attacker either floods the server with requests or causes it to do an excessive amount of processing. Checkpoint 2. Every page on the server includes the menubar.gtl file. Can you alter this file to cause a denial of service? After completing this checkpoint you will need to reset Gruyere! Part 2: Running The web app uses a Python script (gtl.py) to expand the variables and parameters in the *.gtl files. Checkpoint 1. Why does the gtl.py script make a more lucrative target than the webapp itself (which is stored in gruyere.py). Checkpoint 2. Gain arbitrary code execution by inserting a backdoor (for example a reverse shell) gtl.py. To do this you should assume you have access to the gtl.py file Checkpoint 3. Describe how this problem should be fixed. 3This is a hint for the first checkpoint. 3 Question 4: Tools In this final question we are going to move away from Gruyere and look at how tools can help find web security vulnerabilities before they are exploited. Web apps are a nice target for attackers because they are designed to be network accessible. Despite the very real security thread it is very easy to find people writing exploitable code. Checkpoint 1. Search Github for PHP code containing the words sudo, exec and $_GET. Pick one example and explain why it is dangerous. Why do you think this kind of vulnerability is so common? As we have seen in the other labs static analysis tools can be used to help find these vulnerabilities for you. We are going to return to the findbugs tool we have seen previously and look at the find-sec-bugs plugin which adds additional security checks to the tool. Download the standard distribution of the findbugs tool from http://findbugs.sourceforge.net/downloads.html, and the Find Security Bugs plugin from https://h3xstream.github.io/find-sec-bugs/. Once extracted you can start the findbugs GUI by running bin/findbugs. Install the plugin by going through Edit → Preferences → Plugins → Install new plugin and pointing it to the *.jar file you downloaded. We’re giving you two example bits of code (taken from find-sec-bugs testcases) to analyze with the tool: • GetRSAKey.java generates a new RSA key for a user. • XSSRequestWrapper.java is a J2EE servlet wrapper that aims to prevent cross-site scripting. Download the examples from http://www.inf.ed.ac.uk/teaching/courses/sp/2013/labs/lab3/examples.zip and run findbugs on them. Checkpoint 2. What is the problem with GetRSAKey.java? Why is this potentially dangerous? How should it be fixed? Checkpoint 3. Why does find-bugs complain about how you are trying to prevent cross-site-scripting? How should you fix this? Submission Instructions Download a copy of the text file checkpoints.md from http://www.inf.ed.ac.uk/teaching/courses/sp/2013/ labs/lab3/checkpoints.md and edit it to insert your answers. Submit it with the command: submit sp lab3 checkpoints.md We will give some feedback about the submissions on Piazza. Joseph Hallett and David Aspinall, March 2014. 4