You are on page 1of 10

Metasploitable Exploits and Hardening

Guide
Updated On: 07/06/2018
Introduction

As I began working with the Metasploitable virtual machine and testing out different
exploits, I grew curious on how to protect against them. Unfortunately, I have not seen a
guide like this anywhere on the Internet, which is why I decided to create one. The source
code for this site is available on GitHub here so feel free to clone the repository and add on
your own findings as well.

I'm structuring the guide so you see the exploit first, and then how to patch it afterwards; I
also have screenshots included for your reference. Let's begin!

Network Scan

Depending on your experience or comfort with Kali Linux, you can start with either
Zenmap or use an nmap command directly on the command line to scan the Metasploitable
machine for any open ports. I started off with Zenmap because of the GUI, but nmap is
more robust and I would recommend getting into the habit of using that instead. After a
port scan of the Metasploitables IP, the first glaring open port is 23 for Telnet. There are a
couple exploits utilizing Telnet so I will outline how to do those below before disabling
Telnet on the Metasploitable machine.
Zenmap Output

Ports 23 and 25 - Telnet and SMTP

With Telnet, we can start with something simple; power up Wireshark on your Kali
machine. You need to pick a network that you want to capture the network traffic on so
pick the one that the Metasploitable machine is running. With Wireshark running, Telnet to
the Metasploitable machine from your Kali root command line. I linked the YouTube
tutorial I used for your reference.

The next exploit that uses Telnet involves port 25 for SMTP. I linked the tutorial I used for
that here.

There is a reason why no one uses Telnet anymore and the exploits above are just a few
examples why - the best way to mitigate this is to disable Telnet on the Metasploitable
machine (if it was a real server, just use SSH instead). This will be done by going into
/etc/inetd.conf and commenting out the Telnet line, and then restarting the machine.
/etc/inetd.conf with Telnet commented out

Side note: While running through this entire guide, I've gotten into the habit of restarting
the machine and running another scan to confirm that the port is closed or run the exploit
again and ensure that it failed. Obviously this isn't required, but it is a good habit to get into
when you're working on something like this.

Zenmap scan with no Telnet

Port 21 - FTP

This exploit is pretty simple; you go into the metasploitable framework, choose the
vsftpd_234 backdoor exploit, set the target IP, and run the exploit. This backdoor gives us
root access to the Metasploitable machine. Here is the YouTube tutorial I used for this.
Besides the fact that vsftpd is on version 3.0.3 now and the obvious patch would be to
update it, I wanted to know how to patch it just for the version we had because in real life,
the patches won't always be this simple. For this patch, you need to go into the vsftpd
config file located in /etc/vsftpd.conf and disable anonymous upload for the FTP service.

/etc/vsftpd.conf with anonymous upload removed

This alone is not enough for the exploit to not work; the reason being is that if you read the
write up on the backdoor here, you notice that the attacker is able to log in as ":)" for the
username and listen on port 6200. A hardening technique for this particular case is to set up
iptables to drop listening on unused ports. For the sake of this, I only did it for port 6200
since that's what the backdoor uses to get in.

iptables commands to drop traffic at port 6200

what happens when you try the exploit after using iptables

Ports 139 and 145 - Samba

This is another Metasploitable exploit so you just use exploit/multi/samba/usermap_script


and run it to gain access to the victims machine. Samba released a patch here, but another
alternative is to comment out the userman script line in the samba config file. This can be
found in /etc/samba/smb.conf on the Metasploitable machine.
Commented out the userman script

What happens with the exploit after you comment out the userman script

Port 1524 - Ingreslock Backdoor

Port 1524 has the xinetd super server daemon running on it. This exploit is as simple as
using a netcat command to get root access of the machine.

Netcat exploit

This works due to the Ingreslock backdoor placed on the machine. If you go to
/etc/inetd.conf, you can see the last line has this.

Ingreslock backdoor code


All that needs to be done here is delete that entire line, and then reboot the machine. Note
that if you did find a line like this in your config in the wild, you would have to do some
more digging to make sure the backdoor didn't spread elsewhere.

Exploit attempt post removal

Port 2049 - NFS

Note that for this exploit, you need to first install nfs-common with apt-get-install nfs-
common on your Kali Linux machine. Here is the tutorial for the exploit. There are many
steps you can take to harden the NFS service, however for this particular machine I just
added iptables commands to block the Kali machines IP from attempting to mount the
Metasploitable machine. The article I referenced is linked here.

IP tables commands

Failed mount

Now when you try to mount the Metasploitable machine, the root terminal gets frozen and
stuck.

Port 5432 - PostGresSQL


This is another easy Metasploit exploit that allows the attacker direct access into the
meterpreter shell.

PostGres Exploit

This worked because PostGres is set up to write to the default directory which means that
the fix is to change the directory from the default so that the payload won't work. The
config file can be found in /etc/postgresql/8.3/main/postgresql.conf. The default directory
is /var/lib/postgresql/8.3/main so you can change it to whatever you like. Just know that
you actually need to go out and create the new directory because writing it in the config file
alone is not enough. Also, make sure you reboot the Metasploitable machine after changing
this.

changed to new directory called datadir


exploit attempt after directory change

What Can't Be Patched


I also wanted to note the exploits that have no "patches"; I put this in quotes because there
are other ways to mitigate these vulnerabilities.

Port 22 - SSH

Good old SSH, Telnet's updated replacement. The biggest issue (and an issue with the
Metasploitable machine) is the use of passwords (or lack thereof). Obviously, this was set
up for testing purposes, but if you are actually using SSH, it would be way smarter to
utilize public/private key pairs for authentication instead of passwords. This is because if
we have the victim's SSH login credentials, we can easily log into their machines. They key
pairs make for a much more secure connection and here is a YouTube tutorial for how to
set that up.

Port 3306 - MySQL

This can be exploited by using auxiliary modules on Metasploit to scan and find usernames
and passwords. The YouTube tutorial here outlines how to do so. This was another exploit
that demonstrated how passwords are not a strong protection mechanism against attackers. I
linked a tutorial on how to create RSA keys on MySQL here as a mitigation technique.

Port 5900 - VNC

This also uses an auxiliary module exploit on Metasploit. Here is the YouTube tutorial on
how to do so. For this particular case, since the password was "password", it would be wise
to change that to something stronger or even better, use public/private keys for this as well.
Instructions are linked here.
Port 6667 - UnrealIRCd

Hooray for another backdoor! Here is the YouTube tutorial I used to test this out. This one
actually can't be patched from the Metasploitable machines side (as far as I know). I'm only
saying this because after I read this statement released by Unreal, I understood that there
was nothing else I can do except the steps outlined in the screenshot below.

Screenshot solution from Unreal

Port 8180 - Apache Tomcat

This is yet another auxiliary module exploit where the attacker can find the victim's login
credentials. Here is the tutorial I used to do so. Similar to VNC, the user had weak
credentials so the best mitigation would be to have stronger passwords or as I've reiterated
multiple times througout this guide, use public/private key pairs instead. Here is a tutorial
on how to do so on Apache Tomcat 9.0.

Port 2121 - vsftpd

This exploit also involves weak passwords (shocker, I know). Details on the exploit are
here. After some research, I learned that FTP isn't considered secure anymore and that it
would be beneficial to switch to SFTP; details on that are here.

The Two Problem Children


I categorized these separately because these two were unique (and frustrating) to me due to
the fact that I couldn't make heads or tails of how to patch this without waiting for the
developers of the service to release a patch on their own. This knowledge from the dev side
would be a strong addition to the guide, especially since I can't bring myself to look at PHP
or Ruby code anymore.
Port 80 - Apache

This vulnerability is PHP based (hence my earlier comment). I would post an actual video
of how to do this, but I imagine at this point you've figured out how to read through the
exploits on rapid7 anyways. Here's the rapid7 link for the php injection exploit.The furthest
I got was looking into this webpage detailing how the exploit works codewise.

Port 1099 - Java RMI Registry

The final exploits tutorial is here for your reference. This payload was written in Ruby,
which I unfortunately am unfamiliar with. Here is the source code for the exploit; the only
thing that stood out to me was that this doesn't work against JMX ports since they do not
support class loading so that could be a possibility. I did some research on JMX and how to
set it up, but couldn't make much sense of it.

Conclusion

This concludes the guide, sorry that it ended on a defeated note, it would sadden you if I
told you how long I spent looking at those last two ports in particular. I hope that this was
all useful information and is helpful to whoever reads it; please feel free to add on to it
(especially for those last two that stumped me).

Check out my other pen testing walkthroughs here

You might also like