Ch4inrulz 1.0.1: CTF walkthrough, part 1
In this article, we will solve a Capture the Flag (CTF) challenge that was posted on VulnHub by an author named Askar. The description given by the author is as follows: “Frank has a small website and he is a smart developer with a normal security background. He always loves to follow a pattern. This machine was made for Jordan’s Top Hackers 2018 CTF. The difficulty level is Intermediate and the target of the CTF is to capture the Flag.”
I have provided a downloadable URL for this CTF, and you can download the machine and run it on VirtualBox. The torrent downloadable URL is also available for this VM; it has been added in the reference section of this article.
VulnHub is a well-known website for security researchers which aims to provide users with a way to learn and 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. There are a lot of other challenging CTF exercises available on vulnhub.com and I highly suggest attempting them, as it is a good way to sharpen your skills and also learn new techniques in a safe environment.
Please Note: For all of these machines, I have used Oracle Virtual Box 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.
Summary of the steps
The summary of the steps for solving this CTF:
- Identifying the target host by using the Netdiscover utility
- Port scanning with Nmap
- Logging in with FTP default credentials and trying to exploit the FTP older version with Metasploit
- Enumerating Web application with Dirb
- Enumerating port 8011 with Dirb, which was running another Web application
- Exploiting the local file inclusion (LFI) vulnerability
The first step to start any CTF is to identify the target machine IP address; since we are running a virtual machine in the same network, we can identify the target machine IP address by running the netdiscover command. The output of the command can be seen in the following screenshot.
Command Used: <<netdiscover >>
In the highlighted area above, we can see the target machine IP address. The target machine IP address is 192.168.1.113 and my Kali machine IP address is 192.168.1.104. We will be using 192.168.1.104 as the attacker machine IP address.
Note: Since the IP addresses are being assigned by the DHCP, they may be different in your case, depending on the network configuration.
The next step is port scanning, which will list the open port details. Through this scan, we can explore these ports for identifying vulnerabilities in the target system.
For port scanning, I launched an Nmap full-port scan, which is used to check all the 65,531 ports. The command and the results of the Nmap scan can be seen in the screenshot given below.
Command Used: << nmap 192.168.1.113 -A >>
You can see that this time, we used the –A option with Nmap, it is the most common Nmap switch. It will do most of the things by itself. In the above screenshot, we can see a large output after completion of the Nmap scan. The summary of the scan is given below.
- Port 21, which is the default port for FTP, was open and running version 2.3.5 of the VSFTP software. Nmap was able to log into the target system with FTP as both the username and password.
- Port 22 was also found open. It’s running SSH service and seems to be running an updated version of the software
- Port 80 and 8011 were also found as open ports, running an HTTP service. The Apache version is 2.2.22
As Nmap tells us, the FTP service is using the default username and password. Let’s start exploitation with the FTP service.
So, from the last step, we got to know that default credentials are being used. Let’s try to log into the target machine with FTP as a username and password.
Command Used: <<ftp 192.168.1.113>>
Username and Password: ftp
After logging into the target system, I tried to look for available files and directories but could not find any. After that, I tried to upload files into the target system, but it seems that the FTP user does not have the permission to upload files.
During the analysis, I observed that FTP was running the vsFTPd 2.3.5 version, which is an outdated version of vsFTPd. I searched an exploit and luckily, I found a Metasploit module which can be used to exploit the vsFTPd 2.3.5. It can be seen in the following screenshot.
A simple Google search of vsFTPd provided this exploit URL, in which we can see a Metasploit module name in the highlighted area above. I set up this module and run the exploit.
- << use exploit/unix/ftp/vsftpd_234_backdoor >>
- << show options >>
- << set RHOSTS 192.168.1.113 >>
- << show options >>
- << exploit >>
As can be seen in the above screenshot, we have run the exploit, but the exploit did not provide the shell access on the target machine. I tried to debug this, but it was no use. So, I decided to leave this here and move on to the next open port.
Since port 80 was found open, let’s put the target machine IP address into the browser. It opened with a very nice website, which can be seen in the following screenshot.
I manually checked all the available webpages as well as the HTML content of the pages for further clues, but nothing interesting was found. So, I decided to run some automated tools to identify other entry points into the application. One of the most common tools for website enumeration is dirb, so let’s start this tool.
Command Used: << dirb http://192.168.1.113>>
In the highlighted area of the above screenshot, we can see the command we used to run the tool. The output of the command can also be seen in the same screenshot which identified some directories on the target machine. Among those, there is an interesting directory called development. When I opened this directory on the browser, a popup was displayed asking for username and password.
In the above screenshot, we can see an “authentication required” popup in the highlighted area of the above screenshot. I tried some common username and password combinations to get into the directory, but no luck. I also tried to do brute-force, but it did not help in getting into the system.
As we could not find any way forward here, I noted this in my notepad and started working on the other identified open port which was also running an HTTP server. We’ll check this port in the next step.
From Step 2, we know that port 8011 is also open and running the HTTP service. Let’s open it up on the browser. It can be seen in the following screenshot.
As you can see, it just showed a Development Server page. So, let’s run the dirb tool again to identify the further entry points. The output of the dirb can be seen in the following screenshot.
Command Used << dirb http://192.168.1.113:8011/ >>
We can see the API directory in the output of the dirb tool. So, let’s open it up on the browser to see the contents of the directory.
In the above screenshot, we can see some PHP file names. It states that these are the APIs used to communicate with Frank’s server and it is still under development. When I checked these files one by one, I found that file_api.php was showing some error, which can be seen in the following screenshot.
The above error reveals that there is a file parameter which needs to be used to fetch the content from the server. At first, I tried to add this parameter with the GET request. But it gave me a “WRONG INPUT” error which can be seen in the following given screenshot.
I thought it might be possible that this parameter could be used in the POST request, so I used Burp Suite for this and sent this parameter as a POST request. It did not give any output, which means now we are using it in the correct way. It can be seen in the following screenshot.
In the next step, we will try to identify vulnerabilities in this parameter.
As this is a file parameter which is generally used to read and write files on the server, I first tried the Local File Inclusion (LFI) vulnerability and it was very easy — on the first try, I got the /etc/passwd file of the target system, which confirms that it is vulnerable for LFI.
We’ve found LFI on the target system, so I tried to use it to know more about the target system. But none of the information was useful.
So far, we have tried exploring the HTTP and FTP ports on the target machine but could not find any way to get into the target system. We still have a few more possible vulnerabilities to be identified on the target application, which we will cover in the next part of this article. Keep trying and let me know your strategies in the comments!