Guide to Building Vulnerable VMs
I've had a few people ask me recently how I go about building vulnerable VMs, so I thought that I'd write up a little guide to help others who might be thinking of creating their own vulnerable CTF or boot2root.
I should point out that this is only my method - others will have their own - but this seems to work for me.
Planning
Having a plan or a guide keeps you on track with the entire process. I usually take a lot of notes, which will include details about the OS (usually Debian or Ubuntu) that I want to use, the method of gaining a foothold on the system (LFI, command injection, sql injection etc), whether there is a particular way that I want the vulnerability exploited (through a basic web app, or a Content Management System etc), the exploit itself, as well as the method (or methods) of privilege escalation to obtain root and the final (or only) flag.
I also tend to use a "script" (not a "scripting" script), about how things should work, specific exploits and the commands to use it, what someone is likely to do, any hints etc etc.
I also keep details of all the usernames and passwords that I use along the way, as well as any other important details.
I've found that no matter how clear the image is in my mind of what I want to achieve, at some point, something won't work as expected, and I may need to find other options.
This might be because something has been patched during the install process, or because I just can't get it to work.
OS
One of the hardest things about building vulnerable VMs, is that if you want to exploit a particular vulnerability, you need to have access to it.
This may mean that you have to go searching for it on the Internet, in which case, you have to hope that it's still available, or you start building a collection ahead of time.
Because I've been using Debian for quite a long time, I've kept a lot of the old ISO images.
Unfortunately, many of these are the "net-install" ISO images, and not the preferred CD or DVD ISO images.
The "net-install" ISO images are effectively an image with the bare minimum to get you booted up so that you can install whatever software you need, over the Internet.
The reason why this is a bad choice, is because you'll end up with the security updated versions of software, which means that the vulnerability that you wanted to use, may no longer be able to be exploited.
For this reason, I try to use the old CD or DVD ISO images, and I also disable updates (or prevent access to the Internet so that they can't install updated versions).
I have managed to find older CD and DVD ISO images on Official Debian and Ubuntu sites, but this can be hit and miss and not all are available (especially in the case of Debian).
If you are interested in using Debian, I recommend you read the Debian page for more information.
Once I've installed the OS (and any necessary software packages), I shut it down and take a backup copy of it, and name it to something relevant (i.e. DC-6-1-OS.rar).
Also, it pays to be aware of how certain recent changes in both Debian and Ubuntu can affect VMware.
I have seen cases of Predictable Network Interface Names causing problems when obtaining a DHCP address in VMware.
In VirtualBox, the interface is generally something like enp0s3 (this can be viewed by having a look at /etc/network/interfaces).
In VMware, I have seen the interface show up as ens33.
My understanding is that the network interface name is based on the MAC address, so when the MAC address changes (like when being imported into VMware, or vice versa), the network interface name will also change.
The workaround is to disable Predictable Network Interface Names and use eth0 (or something else) instead.
You might want to search for the solution to suit your Linux Distribution, but this worked for Debian.
Debian ISO Images
If you're looking at using Debian for a vulnerable VM, you'll likely need an ISO image.
This presents a bit of a problem, as Debian no longer have all their older ISOs available for download, as "there is not enough space on our servers to host them".
Instead, Debian have started using something called "jigdo", which you can read about here.
The short version is that using jigdo, you can download the individual files that are on the CD or DVD and create your own ISO.
I've yet to use this process, so unfortunately I can't offer any advice or information in relation to it.
If you're lucky, you can still find some ISOs available for download from here, but it is hit and miss.
As an example, I searched for an ISO under the entire Debian 8 branch, and only found a couple of AMD64 DVD and CD ISOs under the Debian 8.10.0 and 8.11.0 branch.
Just a word of warning on the jigdo versions.
It might be possible that the versions include patched or later versions of vulnerable software.
Update regarding recent versions of Ubuntu and Debian
From Ubuntu 17.10 onwards, Ubuntu have changed to using netplan (a command line network configuration tool) to configure network settings.
In short, Ubuntu no longer uses /etc/network/interfaces for network configuration, and instead uses /etc/netplan/*.yaml.
Why would they replace one text based configuration file with another for no logical reason? I have no idea - but I think it's stupid. Maybe they just wanted to jump on the yaml train.
You can read more about these changes with Ubuntu here.
Debian 10 still uses /etc/network/interfaces, but you'll need to add your own entries to this file (definitely for a static IP address, more than likely for a DHCP address as well).
You will still need to make changes in relation to Predictable Network Interface Names for both Ubuntu and Debian.
There is more information about Debian 10 here.
Finding Vulnerable Software
Finding vulnerable software, such as WordPress or Drupal versions is easy, as they are still available on their respective websites.
However, finding vulnerable WordPress plugins, can be hit and miss at times.
If I already know what WordPress plugin I'm looking for, I generally go to the WordPress plugin page and search for it.
Often, you'll find one of two things: The plugin is no longer available (but the plugin page still remains), or the plugin has been updated to a newer version.
Thankfully, this isn't always a problem, and by playing around with the download link and the version number of the software, you'd be surprised at how many times I've been able to download vulnerable WordPress plugins, even ones that were released many years ago.
This isn't always successful (such as when the plugin doesn't include the version number), but it works often enough that I get to use them (or save them as part of my vulnerable WordPress plugin collection).
WordPress
WordPress doesn't like to be changed between different IP addresses and/or different host names. This is because WordPress stores these settings in it's database.
This presents a small problem for a CTF/Boot2root creator.
You can either use a static IP address for the VM (which can be very annoying for end users), or you can add a couple of settings (constants) to the wp-config.php file.
I suggest adding the following two constants to the wp-config.php file and then saving it.
define('WP_HOME','http://dc-2');
define('WP_SITEURL','http://dc-2');
In the example above, I've used http://dc-2 but you will need to change this to match your own requirements.
You will also need to advise your end users that they will need to add a matching entry to their /etc/hosts file.
Another thing you may need to do with WordPress, is to disable automatic updates.
Add the following constant to wp-config.php and save it.
define( 'WP_AUTO_UPDATE_CORE', false );Neither Drupal nor Joomla require these kinds of changes.
Take Regular Backups
Always take regular backups by shutting the VM down and taking a compressed copy that you can restore if needed. This can be a lifesaver (and has, on many occasions).
If you make a config change or install something, make a backup.
I prefer not to take snapshots, as this may possibly cause problems later when exporting the image as an OVA file (no idea if it actually does, but my current solution works quite nicely, so...).
Completion
Once I think the VM is completed, I'll take another backup of the VM's folder, and name it something similar to "DC-6-x-final.zip" (where x is the copy number).
Export as an OVA
Once I've taken a final backup, I'll export it from VirtualBox - File > Export Appliance - and then follow any prompts.
Test in VMware
Once I have the exported OVA file, I then import it into VMware Player and start it up.
From my Kali install, I'll check using netdiscover to see whether it has picked up a DHCP address.
If it has, I then perform a walkthrough on it, just as if it was a blackbox pentest.
Testing - Perform a Walkthrough
I like to treat the VM as if I was doing a blackbox pentest. I do absolutely everything as I normally would, including obtaining root and the final flag.
This is quite possibly the most important step, as it makes sure that everything works smoothly.
It's better to discover problems before something gets released rather than find out after something has been released (which has happened to me).
Release
Once I'm happy with it, I upload a zipped version of the OVA file.
One question I've been asked is where is the best place to host it.
This is entirely up to you, but you need to take into account the size of the file, and depending on popularity, that there might be hundreds of GBs downloaded within a day or a few weeks.
You may have to pay for hosting, or use a free hosting service.
Recommendations
If you don't need a desktop on the VM, do NOT install a desktop on the VM.
The reasons why you shouldn't are really quite simple. It adds considerable size to the VM (from hundreds of MBs to one or two GBs) and it also chews up extra CPU and memory resources for no good reason.
If you do need a desktop on the VM, don't use a fancy screensaver.
A fancy screensaver might look good, but it can also chew up a lot of memory and CPU resources. Keep it simple, keep it blank, or better yet, disable the screensaver completely (and think carefully about power save options).