CS 4740/6740 - Network Security

Application Exploits

In this lab you will explore common vulnerabilities in applications. Your experiments on a web-based application will try to exploit vulnerabilities that are commonly found on these types of programs.

Late submissions will result in a 10% penalty per day (e.g., 2.5 days late result in 25% penalty)

Cross-site Scripting (XSS)

Cross-site scripting vulnerabilities are common in web applications. These flaws allow you to expose the interaction between users and a website. Read more about the different forms of XSS and how they are typically exploited.

1. The application you will test on is at the URL: http://strawman.nslab/blog/. You should access this web site from either your Windows machine or over a SSH tunnel.

   Locate the login page for this application, and fuzz the form fields with HTML special characters to locate a cross-site scripting bug.

2. Now, develop a proof-of-concept (PoC) exploit for this bug which embeds an image tag (eg. <img src="..." />) into the page. Use the following image URL: http://www.ccs.neu.edu/home/noubir/Home_files/shapeimage_1.png. Your injected HTML characters must present a final page to the browser which is HTML compliant.

   Once you have developed a working PoC exploit, take a screen shot of the page in your browser. In addition, save the HTML source of the resulting, exploited page. You will submit both of these in your report.

3. Find one additional XSS vulnerability on a page other than the login page. This second vulnerability should be accessible without having to log in. Write a short PoC exploit for this second bug and record just the string you inject. You do not need to save a screenshot or the full HTML source.

SQL Injection

WARNING: In this section you will be manipulating the backend database of this application. There is a small chance that your attacks will break or disable the web application. Please think carefully about the attacks before you perform them, as other students need to use the same system. If you do break something, report it to the lab TA immediately so it can be fixed.

SQL injection vulnerabilities are very serious flaws which open applications up to a whole host of database attacks. These vulnerabilities affect more than just web based applications and often allow the circumvention of authentication/access controls for information stored in a database. Also, SQL injection flaws can sometimes be the stepping stone used by attackers to fully compromise a database server. Read more about SQL injection through the provided references. You may also want to search the web for more information on the topic.

1. Return to the login page of the weblog application. At least one SQL injection vulnerability exists in this form. Develop an exploit for this form which allows one to log in to the application without knowing a valid username or password. Hints: Imagine the SQL query a programmer might write to check a user's credentials. The backend database is MySQL. Also, the string "--" is the SQL comment and behaves much the same as "//" does in C++. Record the resulting injection string you used to log in.

2. Locate one other SQL injection vulnerability in some other page of the application. Develop a simple PoC exploit which demonstrates how you can manipulate the results of the query. For bonus points: Write an SQL injection exploit which steals a username and password from this application's database.

Directory Traversal

Directory traversal attacks are another, somewhat less common, class of application vulnerability which typically occur because programmers trust some portion of a filename or filesystem path to be provided by users, without validation or sanitization. These flaws often result in unauthorized file retrieval and sometimes even facilitate remote execution attacks. Read more about directory traversal attacks and how they are typically exploited.

1. Explore the weblog application and search for a user supplied parameter that might allow a directory traversal attack. Once you locate one, use it to download the system's /etc/passwd file. Also, pull down other files until you find positive evidence of what OS and version is hosting the website. Save these files for your report. Also, record the URL/parameters you used to obtain /etc/passwd.

Shell Command Injection

WARNING: In this section you will be running commands on the server hosting this application. There is a small chance that your attacks will break or disable the web server or application. Please think carefully about the attacks before you perform them, as other students need to use the same system. If you do break something, report it to the lab TA immediately so it can be fixed.

Shell command injection, while somewhat rare, can be devastating to an application's security because these kinds of flaws generally allow remote execution of code and are usually easy to exploit.

The problem usually lies in an application's use of external commands to accomplish certain tasks. Often, for the convenience of it, programmers will run external commands via the system shell or some equivalent interface. However, if user input is included in such commands (for instance, as command line parameters), then it is very difficult to prevent shell metacharacter injection. Read more about these attacks and how they can be prevented (accessible only through your Windows VM.)

1. Review the pages available in the weblog application and think about what pages are most likely to use an external command. Now, find and exploit one command injection vulnerability. To prove you can run commands on the server, write a file to /tmp named team-T.hack (where T is your team number) which contains the email addresses of all of your team members. This file may contain other garbage as well, but it should have your team members' email addresses somewhere in it. To test whether you were successful, you can read the file back in again with the directory traversal vulnerability you found earlier.

   Hint: You may use the directory traversal vulnerability to swipe the source code for many PHP scripts. Reviewing the sources will allow you to find such a hole very quickly.

Report

For this lab, your team must submit a report with the following information:

1. The screenshot and HTML source showing the proof-of-concept XSS exploit for the login page.

2. The string you used for your second XSS exploit along with the name of page and the name of the form element you attacked.

3. The SQL exploit you used in the SQL injection attack on the login page.

4. The second SQL exploit you used in the SQL injection attack. If you completed the bonus, also include the username and password you stoled.

5. The /etc/passwd file and the URL/parameters you used to retrieve it. Also include the files you used to determine the OS and version.

6. Based on this reference, what class of XSS vulnerabilities does each of the two holes you found fall into?

7. Suppose a programmer needs to run an SQL query such as:

      SELECT * FROM mytable WHERE a='foo' AND b='bar'
   		

   In his application, users can completely control the data in strings foo and bar. To protect his application against SQL injection the programmer decides to insert a backslash (\) in front of all single quote characters provided by users in these strings. This is an acceptable form of escaping/encoding in his database system. For example, if a user provided a string "Let's drive to the beach!", it would be encoded in the SQL query as "Let\'s drive to the beach!". Therefore, inserting single quote characters would not allow attackers to break out of the explicit single quotes in the query. Describe why this protection alone would not prevent an SQL injection attack for this particulary query, and give a sample set of strings which demonstrate the problem. (Hint: Recall that the attacker can control both strings in this query.)

8. Suppose a programmer accepts a filename through a URL request parameter, in a script named safefromtraversal.php. In this script, the programmer removes all occurrences of the string '../' from the filename provided by clients. (In other words, the request parameter is searched for any occurrences of this string. Any found are replaced with the 0 length string, and later the parameter is used as a filename.) With this protection alone, would the script be secure against directory traversal attacks? If not, describe an attack to bypass this protection.

9. Consider the functions execl and system from the standard C library. Explain why using execl is safer than system. Why would a programmer be tempted to use system?

10. Consider the following snippet of C code:

       snprintf(cmd, 1024, "whois %s >> /tmp/whois.log", ip);
       system(cmd);
       

    Suppose an attacker could completely control the content of the variable ip, and that this variable isn't checked for special characters. Name three different metacharacters or operators which could allow an attacker to "break out" of ip's current position in the string to run an arbitrary command.

Grading

Your grade for this lab will be composed of:

• 75%: Recorded results from the lab experiments.

• 25%: Answers to the rest of the questions.