Wasp Attack

There are few better ways to learn about offensive security than by using intentionally vulnerable applications. One such application that has stood out in a crowd for many years and has seen some notable version upgrades over the last few months is Mutillidae II [1], now available to practice ethical hacking.

Provided by the OWASP Foundation  [2], the Open Worldwide Application Security Project is a cornerstone of cybersecurity on today's Internet, providing an established community with educational training materials, along with an eye-watering set of tools to improve security knowledge.

In existence for almost two decades, offered free of charge, and open source, OWASP Mutillidae II is quite a sight to the uninitiated. Built for Linux and Windows, it contains a staggering number of vulnerabilities against which to practice, along with extremely helpful tips for varying levels of experience to assist with walking you through some of the security challenges. The GitHub README describes Mutillidae II as an: "easy-to-use web hacking environment designed for labs, security enthusiasts, classrooms, CTF [capture the flag], and vulnerability assessment tool targets."

In this article, I'll show you how to install Mutillidae II on an AWS instance, look at some of its genuinely impressive features to get you started, and try to take an exploit through to completion.

I'm sure at this point you are wondering about the origin of the name (and how to pronounce it). The Wikipedia [3] page does a great job of joining the dots with the link to wasps: "The Mutillidae are a family of more than 7,000 species of wasps whose wingless females resemble large, hairy ants." They're also known as velvet ants because of their dense hair.

AmIContained

The Mutillidae II GitHub repository offers links to video tutorials on YouTube, and if you have a LAMP (Linux, Apache, MySQL, PHP) server readily available on which to install Mutillidae II, there is a specific link [4] for immediate installation of the application. Also, a comprehensive guide of YouTube videos [5] can help you get things working just as you like; you can even find guides for running the application on Google Kubernetes Engine (GKE), which merits a look, too.

In this article, I demonstrate the containerized approach, which the GitHub repository says will spin up five containers, so you can run Apache/PHP, MySQL, OpenLDAP, phpMyAdmin, and phpLDAPadmin containers as your testing laboratory. You can run the containers locally on a laptop, remotely in AWS, or on another server.

Before creating the containers, take a look at the features you can look forward to seeing, again from the GitHub README:

• Mutillidae II boasts 40+ vulnerabilities and challenges.
• Each of the highly regarded OWASP Top 10 security threats are covered (all the threats are included from the 2007, 2010, 2013, and 2017 Top 10 reports).
• Updates are promised frequently, ensuring the application's stability and potentially offering new features or improvements.
• A single button click can reset all of the application components to their defaults to start again if you succeed or, of course, crash the application to try another challenge.

On Your Marks

The excellent Docker Engine facilitates the Mutillidae II container install from the OWASP GitHub repository [6]. I have a vanilla Debian Linux instance in AWS, so I start by installing Docker Engine:

$ apt install docker.io

The new packages in Table 1 are installed. Once the process is finished, the docker ps command proves it was successful, with no running containers displayed under the each column head.

Next, you need to install Docker Compose, which helps codify a multicontainer build:

$ apt install docker-compose

The additional packages required are listed in Table 1. Now that you have Docker Compose installed, you can pull the Mutillidae code down from GitHub and enter the directory once it has been cloned:

$ git clone https://github.com/webpwnized/mutillidae-docker.git
$ cd mutillidae-docker

If you run ls in that directory, the usual suspects appear along with a docker-compose.yml file. Inspection reveals that it contains a number of sections (database, database_admin, www, directory, directory_admin, volumes, and networks), all of which fire up containers to run the respective services. To do just that, use the command:

$ docker-compose up -d

Incidentally, the -d runs the containers in the background, or daemonizes them. Listing 1 shows the first part of the installation process for Docker Compose.

root@ip-10-78-35-6:~/mutillidae-docker# docker-compose up -d
Creating network "mutillidae-docker_datanet" with the default driver
Creating network "mutillidae-docker_ldapnet" with the default driver
Creating volume "mutillidae-docker_ldap_data" with default driver
Creating volume "mutillidae-docker_ldap_config" with default driver
Building database
Step 1/3 : FROM mysql:debian
debian: Pulling from library/mysql
9e3ea8720c6d: Pull complete
6654d9c12503: Pull complete
[...snip...]

The install process is relatively lengthy, at least with the specification of my cheap AWS instance, but after a few minutes and lots of terminal output, the installation completes. You can expect this text at the end, denoting success:

Creating database        ... done
Creating directory       ... done
Creating database_admin  ... done
Creating www             ... done
Creating directory_admin ... done

To make sure it works, run the docker ps command again; and, if you are running on AWS, now is the time to make sure you are ready to adjust AWS Security Groups settings so that you can access the Mutillidae II web server port too. The docker ps command would usually show any errors from a container perspective; however, you will note that in Figure 1 only four containers are running, not the expected five. I will come back to the missing container in a moment. First though, you need to connect to the AWS instance from your browser. Notice that the containers are running on the AWS instance's localhost IP address, so the services can't be seen from the Internet. Luckily, a time-honored SSH trick gets around that problem.

Figure 1: The output is a little difficult to read, but multiple containers are running.

Getting Tricksy

I decided to add a line to my laptop's /etc/hosts file for the name target.local and point the AWS instance's IP address at it for ease of reference. Now I use SSH port forwarding to tell my laptop to redirect any traffic requested on 127.0.0.1 through TCP ports 8000 and 8001 to TCP ports 80 and 81 of my AWS instance, respectively,

$ ssh -L 8000:127.0.0.1:80 chris@target.local -p2222 # Main Mutillidae web server
$ ssh -L 8001:127.0.0.1:81 chris@target.local -p2222 4# phpMyAdmin web server

where -p2222 refers to the SSH server port running on the AWS instance.

You will need two separate terminal sessions to open each of these port forwarding sessions with these examples. I only use one terminal to open the main Mutillidae web server port up, because that's all I need for the vulnerabilities in this article. See the README on GitHub for other port numbers that may be of interest.