You should submit the following TWO files:
For each question, include the following (where applicable or otherwise unspecified):
Note that, depending on the question, some of the above requirements will not necessarily exist. Also, #1 and #2 from above can often be combined into a single screencap. Also note that some questions may explicitly state what to submit. This is to ensure you submit the correct information we're looking for, and the other requirements are expected as well (see list above).
These requirements may seem tedious and unnecessary; however, they are useful for markers to see that you completed each question, explained that you understood the question, and provided proof that the task was successfully completed.
When in doubt, explain as much as you can. I need to see that you understand the answer and the process you used to get the answer. Not including an explanation or providing too little explanation may result in lost marks.
For this assignment you will be attacking web applications hosted on your VM. 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 network. Although OpenStack also opens up the HTTP port 80 and HTTPS port 443, the VM for this assignment is configured with iptables rules that block incoming connections to all but the SSH port - this has been done to prevent others from abusing your VM. Therefore, to access the web server (on port 80) and the BeEF toolkit (on port 3000), you must use SSH local port forwarding. This allows you to access services on your VM that are externally inaccessible, essentially bypassing the firewall by tunneling multiple connections through your existing secure SSH connection. To better understand this, you can think of the SSH server running on your VM as a "proxy" (exempt from all firewall rules) that can access any service on your VM, and then forward all traffic back to the SSH client running on your machine. SSH port forwarding is a common practice that is used to reduce the attack surface of a network by forcing remote users to authenticate themselves and establish an encrypted SSH tunnel through which they can access other services.
comp4108 and the password found here. The password to access this page with the DVWA password is the same as the one used for Assignment 2 and was posted on Brightspace in the Assignment 2 announcement.
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.
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 will enable you to map a local port on your machine to a remote port on any host that is accessible by your VM (in this exercise, the remote ports that we need to access are on the VM itself, i.e., localhost from the perspective of your VM, but generally speaking you can tunnel traffic to any IP and port combination that your VM can access).
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 can also use the command line (e.g., the Windows command-line now has an SSH client built-in, MobaXTerm, etc.), or use a GUI interface offered by, e.g., PuTTY or MobaXTerm. There are many tutorials online for configuring the GUI, such as this one, but the command-line option is recommended.
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.
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.
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.
sudo bash ~/fix_beef.sh sudo shutdown -r nowIf BeEF still does not work after running the above commands (again, this can be checked by running ps aux | grep beef, or via the web interface in quesion #4 below), please e-mail a TA.
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).
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).
comp4108.ca is resolved to 127.0.0.1. Ensure you submit the path of the file you edited and the line you added, along with any other requirements.proxy tab and turn intercept to on.
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.
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.
comp4108 and the password found here. The password to access this page with the DVWA password is the same as the one used for Assignment 2 and was posted on Brightspace in the Assignment 2 announcement. Note: You need the password from Brightspace to access the DVWA password at the link in the preceding sentences.
/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.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.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.
/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.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.
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.