Damn Vulnerable Web Application (DVWA)

DVWA is a web application which uses PHP and MySQL and implements a number of common web application vulnerabilities. For more information visit http://www.dvwa.co.uk/ and https://github.com/digininja/DVWA.

Installation - vagrant up

Using the Vagrantfile in the penetration testing lab directory in the git repo at https://github.com/kushfj/pentesting, spin up a DVWA VM in virtual box.

The virtual machines has two virtual network adapters, the first adapter is connected to the default NAT network. The NAT network is required during the initial setup to download and install updates and packages. The second adapter is connected the default intnet internal network. The intnet internal network is used for the penetration testing. Note, you must disable or disconnect the NAT interface as soon as the machine is ready.

Penetration Test Assessment

A penetration test assessment was a requirement of a short cource on Penetration Testing from the Charles Sturt University. As part of the assessment, students were provided an ova image of a virtual machine. The virtual machine was to be the target of a penetration test, and students were expected to obtain flags for submission. A walkthrough of the assessment is presented here.

For the benefit of other students, the names and values of the flags have been redacted, and replaced with the string REDACTED

For this walk-though I use the Metasploit framework to attempt to perform a penetration testing exercise on Metasploitable 2. I employ the following penetration testing phases: reconnaisance, threat modelling and vulnerability identification, and exploitation. Since this is a mock exercise, I leave out the pre-engagement, post-exploitation and risk analysis, and reporting phases.

Set-up

This metasploitable walk-through is performed in a virtual lab environment. Two virtual machines (VMs) are used. The first is a Kali VM and the second is the Metasploitable2 VM. Both VMs have their network interfaces connected to an internal Virtualbox network called vlabnet. There is a DHCP server on the virtual lab network to dynamically allocate IP addresses to hosts.

This post is about getting an Ansible control node configured on an Ubuntu VM within Virtualbox to be able to rapidly stand up and deploy other virtual machines within Virtualbox for a virtual lab environment, along with some examples. Since this is a lab environment, and we are running ansible off a guest virtual machine within virtualbox, the closing of machines is outside the scope of this post and assumes that the machines are already installed and provisioned to be on the management network.

Open visualisation format (OVF) is an open standard for packaging and distributing virtual appliances. Essentially this is meant to ensure portability of software and virtual machines across different hypervisors, such as vmware, virtualbox, etc. However, I got an error when importing an OVF file into virtualbox Version 5.0.12 r104815

“Host resource of type “Other Storage Device (20)” is supported with SATA AHCI controllers only, line 47.”

Error reading "XXXXXX.ovf": Host resource of type "Other Storage Device (20)" is supported with SATA AHCI controllers only, line 47.





Result Code: 

VBOX_E_FILE_ERROR (0x80BB0004)

Component: 

ApplianceWrap

Interface: 

IAppliance {XXXXXX}

Fixed it by following the instructions on the forum[1]

(This is an interim post and will be updated progressively. This note will be removed once done.)

This post extends the walk-though on the initial version of Metasploitable at http://nkush.blogspot.com.au/2011/09/metasploitable-walkthrough.html. It should be noted that some commands and output may have been truncated for the purposes of brevity.

Set-up The set-up included two machines in a virtual test environment using VirtualBox. The first was a Metasploitable virtual machine (VM) and the second a Kali 1.0 VM. The two hosts were configured to have a host-only network connection. The test environment was isolated to the 192.168.32.0/24 network. All commands were execute on the Kali VM.

Often times, I employ a CentOS VirtualBox virtual machine (VM) as a development, testing and staging environment, I love the flexibility of virtual environments for testing and development work before moving my work to production environments.

Recently I ran a yum update and yum upgrade on a CentOS 6.4 VM and subsequently rebooted it, only to be greeted by a blank screen following bootup. A quick search of virtual TTY terminals yielded a login prompt.