COMP4108 — Fall 2012

Computer Systems Security

Please e-mail the TA a message with the subject line: COMP4108 A4 and a zip file containing the following attached:
  1. A PDF of your assignment report, including a cover page with your name and the assignment details on the front.
  2. Any code you wrote.
  3. Any scripts you wrote.
  4. Any screenshots you reference (if not in report).
  5. Any separate output files referenced by the PDF report
If you chose to work in a pair please have both members of the team submit your team's assignment.

Hint:
Instructions on how to copy files to and from your local machine and your VM have recently been added to the bottom of the VM page. You may find this useful for submitting code/scripts/log files
When SSHing into your VM for this assignment you will be warned that the host key for your VM has changed. This is because since the last time you've connected your VM has been replaced with a new one at the same port/ip. You are safe to remove the old hostkey and trust the new one. For Linux/OSX users, edit ~/.ssh/known_hosts. On Windows with Putty I believe you just have to accept the new key when prompted.

Lab Setup

For this assignment you will be attacking web applications hosted on your assigned VM using your local machine (i.e. the one you connect to the VM with). Two vulnerable web applications and an attack toolkit called BeEF have been preinstalled and configured to run on your VM.

For security purposes your virtual machine only exposes port 22 (for SSH) to the outside internet (and your local machine). In order to access the Apache web server (on port 80) and the BeEF toolkit (on port 3000) you must use the tunneling functionality of SSH to forward ports on your local machine through the SSH tunnel to the VM. This is a common practice that is used to reduce the attack surface of a network by forcing remote users to authenticate and tunnel their traffic to a service over an encrypted channel in order to be provided access.

Important:
When prompted for a username/password (to log into BeEF or the vulnerable services) you should use username comp4108 and the same password you use to access the VM Assignments page

Normally an attacker wouldn't run their instance of BeEF on the same machine they exploited to embed the hook code (See Section C, Question 1) as it would require having a shell account on the web server. To simplify this assignment BeEF has been installed on your VM alongside the vulnerable web applications. You'll have to use your imagination and pretend you were hosting BeEF locally. It's important to remember that an attacker doesn't need to install any of the BeEF toolkit onto a server to attack websites it hosts, just a script block loading the hook code. The hook code and the BeEF toolkit can be hosted anywhere.

SSH tunnels

As mentioned, your VM only exposes port 22 to the internet and you need to access ports 80 and 3000 on the VM from your local machine. The best way to do this is by using what OpenSSH calls a "local port forward". This a type of tunnel that does exactly what it sounds like it would: forwards a local port to the remote machine over an SSH tunnel.

The best place to learn about this type of forward is the SSH man page. Specifically you will want to read the section on the -L parameter (that is, dash capital L).

Using Linux or OSX you can create a local port forward using the -L parameter mentioned above with the command line ssh tool. On Windows, you will have to suffer the GUI approach offered by PuTTY. There are tutorials available for setting up a local port forward using PuTTY on Windows.

Hint:
Remember! You are trying to forward a port from your client machine to a localhost port of your VM

Hint:
The port number you SSH to, as well as the username and host remain the same as you've been using for your vm assignment this whole course.

Web Sec Fundamentals & Intercepting Proxies

The first rule of web application security is to never trust user input!. One of the fascinating things about web application security is just how malleable the input you provide to the server is. HTTP is an easy to learn protocol with a representation that lends itself to modification by humans. By providing malicious input that is handled improperly by the web application we can turn its own code and users against it.

To get a feel for how often untrusted input is the cause of a vulnerability class look at the OWASP Top Ten Application Security Risks 2010. Each of the 10 vulnerabilities has a fantastic summary page

OWASP also hosts detailed pages for each of the types of attacks you will be using in this assignment. The OWASP wiki pages have detailed explanations, sample exploits, as well as advice on finding and fixing the various attack types. You definitely want to read the pages for Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF), Command Injection and Path Traversal Attacks. Knowing some Javascript, HTML and the Document Object Model (DOM) would be useful but you should be able to succeed without deep knowledge. You are not asked to do any complex programming. The free W3Schools HTML tutorials and javascript tutorials might be helpful.

Burp

One of the most powerful ways to perform security testing (and even general testing in some cases!) of a web application is to configure your local machine's browser to use an intercepting proxy. Once configured to forward requests to a proxy you can use the browser to interact with a web application in normal fashion. Each request your browser makes is given to the proxy where (when enabled) the proxy will hold the request pending interaction from you. For each request you choose whether it should be dropped (never sent to the web app at all), or forwarded (to the web app). Before making the decision to forward the request you can easily edit any data before it is sent on. Editing data outside of the browser allows us to bypass ineffective (and annoying) limitations like javascript validation code and input field length limits. It also allows us to edit otherwise immutable headers automatically inserted by the browser.

For this assignment we will be using one of the most popular intercepting proxies Burp Suite. Burp is a commercial product offering a myriad of features useful for a professional penetration tester. Since we are just using the intercepting proxy feature of Burp Suite we can easily get by with the free version. The Burp suite intercepting proxy help pages detail the configuration options and basic usage.

BeEF

Often when demonstrating XSS vulnerabilities a researcher will show an alert popup created by their successful exploitation. Unfortunately this often leaves a casual observer wondering what the harm is in XSS. Even demonstrations showing cookie theft for session hijacking underplay the potential harm from an unpatched XSS vulnerability. Thanks to advances in modern browser technology (asynchronous javascript, web sockets, browser plugins, etc.) an attacker able to run javascript in your web browser from the context of an exploited website is quite powerful.

The Browser Exploitation Framework Project (BeEF) is a potent demonstration of this. BeEF is a modern attack tool built for penetration testers to leverage XSS vulnerabilities in order to create a network of browser bots. By including a hook script file that the BeEF tool provides over the network into the context of a victim page (usually by means of an XSS attack) the penetration tester is able to recruit the browsers that visit the victim page and execute the hook script. Once hooked, the browser communicates back to the BeEF command server and control panel where the penetration tester (or worse, a real attacker) can leverage plugins for interrogating the hooked browser, stealing cookies, and executing complex client-side code delivered on the fly.

BeEF even allows for transparently proxying data from the Penetration tester's machine through the hooked victim browsers. This can often allow an attacker to bypass firewall restrictions since the client will be behind the firewall and within the target network. BeEF also integrates nicely with the metasploit project, allowing for powerful client-side browser exploits. These would typically be used to break out of the limited javascript browser sandbox in order to execute native code and gain local root access.

In the last part of this assignment you will use an XSS vulnerability in one of the web applications to embed the BeEF hook script. By deliberately hooking your own browser you will get the chance to see what sorts of commands BeEF offers, and the dynamically updating interface it uses.

Before you can start attacking the vulnerable web applications hosted on your VM you first need to make the VM's services accessible to your local machine. This involves creating SSH tunnels for both Apache (port 80) and BeEF (port 3000). This assignment also calls for using a proxy (Burp Suite) specifically built for allowing skilled users to mangle their web traffic for testing the security of web applications. Please perform the verification steps as they are key to solving the rest of the assignment! Do not proceed until you are confident you have set your machine up correctly.

  1. 1 Mark Set up a SSH tunnel to forward port 80 on your VM to port 9999 on your local machine (i.e. the one you are connecting to the VM from). Submit the command you run to accomplish this (if using Linux/OSX) or a screenshot of your PuTTY configuration (if using Windows).
  2. Verify that you can browse (from your local machine's browser) to http://localhost:9999 and see an Apache served webpage with two directories.
  3. 1 Mark Set up a SSH tunnel to forward port 3000 on your VM to port 3000 on your local machine. Submit the command you run to accomplish this (if using Linux/OSX) or a screenshot of your PuTTY configuration (if using Windows).
  4. Verify that you can browse to http://localhost:3000/ui/panel on your local machine and see the BeEF panel login page.
  5. 1 Mark Add an entry to your local machine's hosts file such that comp4108.ca is resolved to 127.0.0.1. Submit the path of the file you edited and the line you added.

    Hint:
    Wikipedia has an extremely comprehensive table with the os-dependent location for the hosts file.

    Adding the hosts file entry allows you to fake a domain name for your VM. This is important as the Burp Proxy does not seem to intercept requests for localhost. In order to intercept requests in later steps you will need to use the comp4108.ca hostname.
  6. Verify that you can now browse to http://comp4108.ca:9999 and http://comp4108.ca:3000/ui/panel on your local machine.
  7. Download the free version of the Burp Suite to your local machine. Burp is java-based and runs on Linux, OSX, and Windows. The readme file accompanying burp will instruct you on how to run burp on your platform of choice. Once you have Burp running navigate to the proxy tab and turn intercept to on.
  8. 1 Mark Configure Firefox on your local machine to use burp as a HTTP Proxy. To do so, open the Firefox Preferences pane, and select the Advanced tab. Under Network click the Settings button. Set up a Manual proxy configuration that uses a HTTP Proxy on Port 8080 (the default Burp port) for all protocols. Submit a screenshot of your Firefox Network Preferences screen after you have configured the proxy.
  9. 1 Mark Verify when you use Firefox to visit http://comp4108.ca:9999 that the request is caught under the Burp Suite intercept tab. Try forwarding or dropping the request. Submit a screenshot of your captured request from the Burp intercept tab.

For each of the following questions you will exploit a vulnerability in the Damn Vulnerable Web Application (DVWA). It was written specifically to be used as a training tool to teach common web app vulnerabilities. DVWA has a configurable security level that allows you to simulate both textbook manifestations of a vulnerability class as well as commonly encountered mitigations. Poorly crafted vulnerability mitigations (e.g. incomplete blacklisting, improper input escaping, etc.) are often a roadbump that an attacker must work around.

For this assignment you should answer each question in both LOW and MEDIUM security. Start in low security so that there are fewer challenges to address in finding a solution. Once you have the low security solution working switch the security setting to medium and adapt your exploit so that it works reliably under the higher security setting.

In low security mode DVWA attempts no exploit mitigation strategies. You should stay in this security mode until you get your exploit working. Once you understand how to exploit the vulnerability consistently, change the security setting to medium. In this setting DVWA will attempt to block the most straight forward attack vectors and you will have to work around the protections.

Hint:
Some students have encountered a bug where the Security level will not change. If you encounter this bug, clear the cookies in your local browser. The current DVWA security level is stored client-side in the cookie. Another option is to use Burp suite to intercept your requests to edit the cookie value such that only the correct security level is present. Either approach should work!
  1. Exploit the DVWA Command Execution vulnerability to read the contents of the file /var/www/secret_a.txt. You must get the contents of this file through the DVWA application by crafting a suitable command injection for the vulnerable page. Provide a description of the vulnerability (referencing lines in the DVWA source code), the contents of secret_a.txt and your exploit. For the medium security solution, describe how you had to adapt your low security solution to bypass any protections.
    2 Marks for Low Security Solution
    3 Marks for Medium Security Solution

    Hint:
    You can view the PHP source code of the vulnerable page you are on using the View Source button at the bottom right of the page Important: the code changes when the security level changes. When you are trying to adapt your low security solution for the medium security level be sure to focus on how the code is different on each security level.
    Hint:
    Think about bash shell fundamentals. How can you run two commands at once? What about combining the output of one command as the input to another? Have you seen any syntax tricks in previous assignments in bash scripts/solutions that might be helpful? Maybe some OWASP documentation will inspire you.
  2. On your local machine create a bare bones HTML file that exploits the DVWA Cross Site Request Forgery vulnerability. Whenever a user who has previously signed into DVWA opens your HTML file it should change their password to something of your choosing. The exploitation should happen automatically, and without user action/choice when your HTML page is loaded. Test your exploit by:
    1. Signing into DVWA using your local machine web browser (if you haven't already). This will get you a session cookie for DVWA so that you can pretend to be a victim of the CSRF exploit you wrote.
    2. Closing the DVWA tab/window (not necessary, but helps demonstrate the attack happens regardless of whether the victim has the vulnerable page open).
    3. Loading your exploit HTML file in your local browser. Remember, no input allowed!
    4. Returning to DVWA, logging out, and trying to log back in using the new password
    If your exploit works successfully then you were able to log back into the account using the NEW password that your exploit was programmed to use. Now imagine that you found a similar vulnerability in a more popular website and lured users of that website to your exploit page. CSRF is a powerful attack vector!

    In your submission, provide a description of the vulnerability (referencing lines in the DVWA source code), a description of the exploitation process, and your exploit. For the medium security solution, describe how you had to adapt your low security solution to bypass any protections.
    2 Marks for Low Security Solution
    3 Marks for Medium Security Solution

    Hint:
    Remember that once your attack succeeds you won't be able to log back in using the comp4108 user and the old password! You will have to use your new password or change it back to the default after you demonstrate your attack.
  3. Exploit the DVWA File Inclusion vulnerablity to include the contents of the file /var/www/secret_b.php. Provide a description of the vulnerability (referencing lines in the DVWA source code), a description of the exploitation process, and your exploit. For the medium security solution, describe how you had to adapt your low security solution to bypass any protections.
    2 Marks for Low Security Solution
    3 Marks for Medium Security Solution
  4. Solve each of the 6 XSS challenges on http://comp4108.ca:9999/XSS/challenges.htm. For each of the 6 challenges provide: a description of the vulnerability, a description of the exploitation process, and your exploit. Highlight any protections you were forced to work around, and how you did so.
    12 Marks. 2 per challenge

In this section of the assignment you will be exploiting a persistent XSS vulnerability in DVWA to embed the BeEF hook script such that browsers that visit the vulnerable page are recruited into your BeEF botnet. This will require flipping between two separate browsers, one playing the part of the BeEF herder and one playing the beef being herded. Using BeEF you will have the herder machine attack the beef machine using a variety of the BeEF browser commands.


Hint:
There is often a delay of 2-10 seconds between executing a command in the BeEF control panel and receiving a result. Be patient!
  1. Using one browser (hereafter called the attack browser) exploit the DVWA Stored Cross Site Scripting vulnerability such that you are able to load the BeEF hook code at http://comp4108.ca:3000/hook.js into the context of the vulnerable page. Remember this is a persistent XSS vulnerability and you are exploiting a guestbook that maintains state across visits. You can exploit DVWA in low security mode only for this question, you do not need to get your exploit working in medium security mode. Provide a description of the exploitation process, and your exploit.
    2 marks
  2. On your local machine open another (Chrome, IE, Safari, etc.) web browser (hereafter called the victim browser) and visit the DVWA Stored Cross Site Scripting page that you exploited. The victim browser should now be hooked by BeEF due to the persistent XSS attack you embedded from Part C Question 1. You should use an entirely separate second browser as the victim browser and not a second tab/window in your first browser. BeEF is more fun with more hooked clients and each browser can only be hooked once. Remember to keep the tab/window with the vulnerable DVWA page open in your victim browser.
  3. In your attack browser load the BeEF control panel and verify that you see your hooked victim browser from Part C Question 2.
  4. Use BeEF to steal the DVWA cookie from your victim browser. Submit a description of which BeEF command(s) and features you used to accomplish the task, as well as the results generated.
    2 marks

    Stealing the cookie associated with a domain is an attractive target for an attacker. HTTP Cookies are often used for session management. If an attacker can steal your cookie for a given domain then they gain they often gain the ability to impersonate you to that domain for the duration of your established session.
  5. Use BeEF to fingerprint the victim browser. Submit a description of which BeEF command(s) and features you used to accomplish the task, as well as the results generated. Aim to collect as much information about the victim browser as you can.
    2 marks
  6. Use BeEF to perform a fake flash update social engineering attack. Submit a description of which BeEF command(s) and features you used to accomplish the task, as well as the results generated. You must also submit a screenshot of the flash update attack as seen from the victim browser.
    2 marks
  7. Use BeEF to perform a clippy social engineering attack. Submit a description of which BeEF command(s) and features you used to accomplish the task, as well as the results generated. You must also submit a screenshot of the clippy attack as seen from the victim browser.
    2 marks
  8. Use BeEF to perform a pretty theft attack using the Facebook dialogue type. Submit a description of which BeEF command(s) and features you used to accomplish the task, as well as the results generated. You must also submit a screenshot of the pretty theft attack as seen from the victim browser.
    2 marks
Hint:
You can find the pretty theft, clippy and fake flash update attacks under the BeEF command menu for a hooked browser.