CSG254: Network Security

NOTE: Read this entire document before beginning the lab assignment.

Lab Assignment

1. Cross-site Scripting (XSS)

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

   2. The application you will test on is at the URL: http://strawman-fedora.nslab.ccs.neu.edu/blog/
      It can only be accessed from within the security lab (or over an 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.

   3. Now, develop a proof-of-concept (PoC) exploit for this bug which embeds an image tag (eg. <img src="..." />) into the page. The image URL should point to some image on the CCIS main website. 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 later.)

   4. 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. (No need to save a screenshot or the full HTML source.)

2. 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.

   1. 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.

   2. 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.

   3. 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.)

3. Directory Traversal

   1. 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.

   2. 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. (You will submit these files later, so hang onto them. Also, record the URL/parameters you used to obtain /etc/passwd.)

4. 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.

   1. 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.

   2. 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.

Questions

1. Based on this reference, what class of XSS vulnerabilities does each of the two holes you found fall into?
   
   
2. 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.)
   
   
3. 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.
   
   
4. 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?
   
   
5. 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.

Submission Notes

• You need to submit one short report for your team, which includes all answers to questions in the "Questions" section above, and the items listed below. The report must indicate what each team member did. (While the work for this lab can be split up amongst your team members, at least two team members must participate in each main section of the lab, and all team members must understand the answers given for the questions.)
  
  
• Don't forget to submit the proof of concept exploits for all for sections (see steps 1.3, 1.4, 2.2, 2.3, 3.2, and 4.2). Also, be sure to include the additional evidence of your exploits requested in steps 1.3, 2.3 and 3.2. If you did the bonus part of step 2.4, be sure to include the credentials you were able to steal.
  
  
• You will likely need to search the web for answers to many questions in this lab. This is permitted, but be sure to record EVERY reference you use and include them in your final report. You may quote short portions of text from these references, but don't just copy-and-paste complete answers. You must provide explanations in your own words.
  
  
• Submit all items in one email to prabhu@ccs.neu.edu and CC noubir@ccs.neu.edu. Be sure to send all files in one .tar.gz or .zip file. Acceptable report formats are text, RTF, PostScript, and PDF.