Computer Systems Security
COMP4108 A4
and a zip file containing the following attached:
~/.ssh/known_hosts
. On Windows with Putty I believe you just have to accept the new key when prompted.
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.
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.
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.
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.
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
. Submit the path of the file you edited and the line you added.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.
Submit a screenshot of your Firefox Network Preferences screen after you have configured the proxy.
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.
/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.