Tr0ll

COMPLETE 01 Dec 2015 VulnHub

I’ve decided that 2016 is the year I really jump into security and begin to hone my knowledge by taking on vulnerable virtual machines (vm’s), security certificates, and offensive programming. I’m starting off the year by taking on my first boot2root: tr0ll. Having played around with various security tools in the past (nmap, metasploit, etc…) I felt tr0ll would be a great test on what I already know, as well as what I still need to learn and practice.

When booting up tr0ll in VMware Fusion 7, I was presented with a login prompt shown below.

Nothing I can really do here, so I decided to boot up Kali and use arp-scan to find out the ip address of tr0ll. IMPORTANT: Make sure the network adapter is set to NAT on tr0ll so it is allocated an ip addresss through the router’s dhcp configuration.

In this case, tr0ll was given the ip of 192.168.116.150 (Kali is using 192.168.116.254). From here, I decided to run a scan with nmap to see what services tr0ll was running. Using the command: nmap -sS -A 192.168.116.150 I ran a TCP scan (-sS) on what services were running on the machine, as well as OS detection, version detection, script scanning, and traceroute (-A). Results of the scan can be noticed below.

FTP, SSH, and HTTP were the only 3 services running on the machine. At first glance, two things immediately caught my attention. The first was that anonymous ftp was allowed and the other was a directory on port 80 called /secret. I decided to begin my search on port 80 (http) by browsing to the ip address of the target and seeing what came up.

Alright, so doesn’t look like anything is here. Lets see what happens when we append /secret to the url.

Port 80 isn’t looking too good, so I decided to see what I could get from ftp (port 21). Using the command: ftp 192.168.116.150 I was asked for a username: anonymous and a password: guest (could have put any password here as anonymous ftp doesn’t validate credentials).

I was prompted “Login Successful” and used the ls command to see what was in the directory. The only file that came up was one called lol.pcap.This file extension (.pcap) is commonly used for a packet capture file, commonly used by Wireshark. I grabbed the file and booted it up in Wireshark to see what I could find.

Following the TCP Stream of the first packet, I was able to quickly recognize that a file called secret_stuff.txt was exchanged.  In order to see what was contained inside of  secret_stuff.txt, I filtered out the pcap file using ftp-data in order to rebuild the text file before the exchange.

The first and last packet was the opening and closing of the ftp connection, so I focused my attention on the middle packet to see what was actually transferred.

Following the TCP Stream of the packet, I found that secret_stuff.txt contained the following text.

Obviously sup3rs3cr3tdirlol stood out right away. Since I was finished with ftp, that meant that it was either going to be used for SSH or possibly HTTP. I decided to try appending sup3rs3cr3tdirlol to the url 192.168.116.150/secret

Not what I was looking for, so I decided to remove the /secret from the url to see if sup3rs3cr3tdirlol was it’s own parent directory.

Interesting… I grabbed the file to what information I could get from it. A quick file of roflmao told me it was a 32-bit executable. Let’s see what results we can get from using the strings command on the executable.

“Find address 0x0856BF to proceed” Perhaps another directory on port 80?

This directory had two folders, one called good_luck and another called this_folder_contains_the_password. The folder good_luck contained a text file named which_one_lol.txt. The text file contained 10 items.

The folder this_folder_contains_the_password had one text file called Pass.text. This text file only contained 1 item.

At this point, it became pretty clear that this must be credentials for SSH as that was the only service I had yet to look at on the machine. I grabbed both text files (using wget) and decided that I’d use hydra to brute force the SSH connection. I’d use which_one_lol.txt as a username list and “Good_job_:)” as the password.

Looks like something is preventing us from brute forcing the connection. I looked around online and I think Fail2Ban may be the culprit here. I tried the various combinations using the usernames and password but nothing worked. I looked back at the directories again and this_folder_contains_the_password caught my eye again. The file it held was Pass.txt so maybe the directory was supposed to be taken literally and Pass.txt was the password. I tried the combinations of usernames but this time used Pass.txt as the password.

Success! I pulled up a low privileged bash shell and starting looking around. I found an interesting file in /opt called lmao.py but didn’t have the proper permissions to cat the file. However, after a few minutes the connection dropped and I was presented with the following message:

I started looking around in various directories and found a fail2ban log in /var/log which confirmed my suspicions that fail2ban was preventing brute forcing of the SSH connection.

I reconnected and took a look at the root directory and noticed that the /tmp directory had full root access. I knew from past boot2root’s that this was not normal and that this configuration was left purposely.

At this point I knew three things:

1. I had a directory /tmp with full root access

2. I had a file lmao.py which was definitely important as there’s no other reason it would be in the /opt directory.

3. Finally there was some event causing my SSH connection to drop.

I looked at /var/log and decided to look at the cronlog. Cron is a time based scheduler in Unix which can run scripts daily, monthly, etc… and it could be explaining why my SSH connection was dropping after so many minutes. If we look at the cron table below, we can see that cleaner.py is running every 2 minutes.

So I needed to find out where this file was so I could examine it. I ran the find command and searched for cleaner.py using the terminal’s search function. Using the command find -name cleaner.py I found the file in the directory /lib/log/cleaner.py.

After going to the directory, I noticed that I had permissions to read and write the file.

After using cat on the file, itc looked like every two minutes, everything in the /tmp was being deleted. However, I quickly saw how I could take advantage of this. Since this file had root privileges, I could rewrite the script to copy a shell to the tmp folder.

Finally, I waited for the cron job to drop the shell into the /tmp directory. I ran the shell script and then used the command whoami and saw that I finally had root.

A quick cat of /root/proof.txt gave me the proof I needed and my first boot2root was finally completed.

Thank you Maleus for this boot2root. I enjoyed working on it.