Adventures in Metasploitable

I recently decided I wanted to dive back into cyber security. I bought a new laptop dedicated for this — a Dell 14 Plus that was on sale at Best Buy — and installed Fedora 43 on it. Fedora is now much more user-friendly and I was pleasantly surprised by how easy it was to configure. The image plays nicely with my new laptop and there are even quality-of-life software such as Fedora’s media writer. After updating my machine, here is what it looked like:

Time to build a lab and sandbox. I downloaded lib-vert for a native QEMU/KVM native virtual machine. Kali was an easy set up and worked out of the box. I was a bit sad to learn that the default user/password for Kali changed from root:toor to kali:kali. Other than that, Kali felt similar to the earlier versions I’ve used before (as well as Backtrack 5).

Unfortunately, Metasploitable 2 was a ton of headache because of the image’s age. It was stuck at boot initialization so I thought it may be due to the disk type. My VM defaulted to a VirtIO storage but it caused problems because Metasploitable could not locate the boot loader. After manually changing it to SATA, it finally booted up.

I was able to log in but the next issue came with the network. Running `ifconfig` revealed that my machine’s network was on a local loopback only, which implied that the network configuration was not working. After digging around on a few forums, I found my answer: the network card type e1000e was not supported. There was no option to change it in the settings so I had to manually edit the XML file to force e1000. Doing a bit of research reveals that both the e1000 and the e1000e adapters emulate intel NICs, but the e1000e only supports newer OS’s.

Now onto the fun part: hacking the VM.

Scope: Metasploitable 2 VM

Goal: exploit vsFTPd backdoor

Tools: NMAP, Metasploit

I started by running an NMAP scan to reveal open ports and versions. Obviously, the Metasploitable VM contains numerous vulnerabilities but I decided to go with the vsFTPd 2.3.4 vulnerability. Looking at the source code for version 2.3.4, we find the culprit behind the backdoor. A rouge else if statement that checks for two characters — 0x3a and 0x29, which are ":" and ")". If the conditional finds the smiley face, it runs vsf_sysutil_extra(); which will set up a TCP socket listening on port 6200. Connecting to this port will spawn a shell.

To exploit, I ran:

msfconsole
use exploit/unix/ftp/vsftpd_234_backdoor
set RHOST <IP>
run

This was all it took to breach the VM. We got root access pretty much instantly. PWNED!

I added a text file via the shell I opened inside of my Kali terminal just to prove to myself that I really had access. Sure enough, the file I created appeared in my Metasploitable VM.

It felt great completing this with minimal help, looks like I still got it! That said, I still learned a few things today. I successfully booted the VM with configurations of NIC drivers, refreshed my NMAP enumeration knowledge used to reveal services and vulnerabilities, and exploited a specific vulnerability via Metasploit.