The Great Reveal

To check that the web server for phpMyAdmin is working properly, I connect to http://localhost:8001 from my browser. However, disaster strikes, as shown by the nasty error in red (Figure 2).

Figure 2: All is not well in the land of phpMyAdmin.

The errors relate to database issues and could be the missing container mentioned before that didn't show up in Figure 1. Visiting http://localhost:8000 for the main Mutillidae web server doesn't offer much hope, judging by the errors shown at the top of Figure 3.

Figure 3: All is also not well in the land of Mutillidae.

According to the blue text, I can Click here , apparently to set up the database. Sadly, that fails with lots of errors; however, I'll use that link again in a second.

In the terminal I used to run Docker Compose, I scroll up through the logging output and spot the error: RAM: database exited with code 137 . A very quick bit of googling revealed the issue (unrelated to Mutillidae). I was using an AWS instance without enough RAM for Mutillidae to run all of its services, and the MySQL database container was failing to start up.

I quickly destroyed the existing instance and created a new one with an upgraded specification to offer 4GB of RAM and two virtual (v)CPU cores [7]. In my case, that was from the t2 family and classed as a t2.medium in the North Virginia region.

I then cloned the correct repository again, having logged in to the AWS instance with an SSH port forwarding command; ran the docker-compose command; adjusted the target.local reference; and went back to my browser (http://localhost:8000 ). Unfortunately, Figure 4 shows another worrying error about the database being offline.

Figure 4: Oh no! A new database error.

Thankfully clicking the Click here link at the top of the page offers a different result this time and it starts configuring MySQL so it will accept the correct details for Mutillidae. Figure 5 is the pop-up dialog box on which I click OK to proceed.

Figure 5: Click OK to proceed.

The next step produces some interesting output about inserting tables into the database, and Figure 6 shows Mutillidae II in its full glory (after clicking Continue ).

Figure 6: A working Mutillidae II web server and database.

Becoming an 3l33t Haxx0r

A fully operational database-driven Mutillidae II application is now ready, against which you can practice your ethical hacking skills.

Before going a little deeper and getting your hands dirty, you should come to grips with some of the basics of the user interface (UI), which is absolutely brimming with features, including the main navigation menu. Figure 7 shows the depth of functionality for just one option.

Figure 7: Just one navigation option in the Mutillidae UI offers numerous choices.

As you can see, you have access to a massive number of tools and vulnerabilities for testing and learning. Each menu item offers a variety of challenges or useful tools to try.

The top navigation bar is also worthy of your attention. Note the Reset DB link for starting again from scratch. You will probably need to use it at some point. A quick look in the Toggle Security link reveals that Mutillidae II comes with three main security levels (although online references mention others, which confused me a little). The levels in Table 2 apply to the level of effort you're likely to need to beat Mutillidae's defences. Toggle through these security levels to test your 3l33t (elite in leetspeak) skills.

A Hatful of Tricks

For the rest of the article, I'll focus on a few clues to get you started with Mutillidae and then take one vulnerability all the way through to its conclusion at the end. I'll also just look at the more obvious routes to exploitation (security level 0) to leave the good stuff for you to try later.

The first vulnerability is called directory traversal, which can be run from any page. Here you exploit a vulnerability that allows users to read files to which they shouldn't have access. If you were also able to execute that file on the target system, it would be called local file inclusion instead. I'll demonstrate the URL I used to read the /etc/passwd file on the target system (with a slightly tidied URL for clarity):

http://localhost:8000/index.php?page=../../../etc/passwd

I guessed the web root's directory was three directory levels from the uppermost directory level (hence the three iterations of ../ in the URL), having spotted the page= variable that might be open to abuse. The /etc/passwd file is then revealed in the Mutillidae UI. I would recommend practicing with other files to whet your appetite.