CozyHosting
CozyHosting writeup by Thamizhiniyan C S
Last updated
CozyHosting writeup by Thamizhiniyan C S
Last updated
Hello everyone, In this writeup we are going to solve CozyHosting from HackTheBox.
Link for the machine : https://app.hackthebox.com/machines/CozyHosting
Lets Start 🙌
Connect to the HTB server by using the OpenVpn configuration file that’s generated by HTB.
[ Click Here to learn more about how to connect to vpn and access the boxes. ]
After connecting to the vpn service, click on Join Machine to access the machine’s ip.
After joining the machine you can see the IP Address of the target machine.
First I started by scanning for open ports on the target machine.
From the results of rustscan, we can see that 2 ports are open.
| Ports | Services |
|---|---|
22 | SSH |
80 | HTTP |
First I checked the HTTP service, by trying to visit the website that is hosted on port 80.
We can see that the website redirects to a domain cozyhosting.htb. We have to add this domain referring to the target IP address in our /etc/hosts file, to view this website.
Now visit the website.
The website, has a login page. Nothing else interesting. So next I started directory enumeration using gobuster.
New directories found:
| Directory | Status | Size |
|---|---|---|
/admin | 401 | 97 |
/error | 500 | 73 |
From the results of the gobuster, we have found two routes, /admin and /error. I first checked the /admin route. The /admin route redirects to /login route, which means we have to first login to view the admin page.
So next I visited the /error route.
The error page displayed the message “Whitelabel Error Page”. I googled about this and found that this is a spring boot error page.
Now we know that the website is built with Spring Boot. So I started looking out for common spring boot vulnerabilities. I found this:
So I started to take a look at the documentation of spring boot for these actuator endpoints
and checked all the endpoints.
Out of all the endpoints, /actuator/env, /actuator/sessions, and /actuator/mappings endpoints worked.
From the /actuator/sessions endpoint, found the following session tokens.
I tried to login with these session tokens. I used the cookie editor to replace the current session ID with the token we found.
Now refresh the page.
And we have successfully got access to the admin page.
In the admin page, you can see a form, which on submit will try to establish a connection via ssh using the given hostname and username.
First I tried some random host name and captured the request with burpsuite and sent that to the repeater tab. While I was testing with random credentials, when supplying an empty username, resulted in the following error.
From this error we can devise that this API is vulnerable to command injection. So I tried some basic command to test it.
From the response, we can see the response of the id command and now its proved that the application is vulnerable to command injection. Now its time to use this vulnerability to gain access to the machine.
We know that, we can execute commands on the target machine with this vulnerability, so we can download a reverse shell on the target machine by sending command. For that first we need a reverse shell on our local machine. Create a file named revshell.sh and paste following code in that file. Don’t forget to replace the IP address.
Now start a simple HTTP server with python using the command python3 -m http.server.
Now its time to download this reverse shell on the target machine. You can use this below command to download the reverse shell on the target machine by supplying this as the value to the username field.
I have used a variable IFS in the above command. To know about it, check this out:
From the response we can see that there is no error thrown. We can verify that the reverse shell is downloaded on the target machine by checking the terminal where we hosted the simple HTTP server using python. You will be able to see a GET request to /revshell.sh, which shows that the file is downloaded successfully.
Next we have to provide executable permission to the reverse shell file to execute it. You can do this by supplying the following command.
No error from the response and thus we have successfully updated the file permissions. Now its time to execute the reverse shell. But before that we have to start a netcat listener on our local machine on port 9001.
Finally, its time to execute the reverse shell, supply the following command to do so.
No error and no response, check the netcat listener. We have successfully got the reverse shell back.
When I listed the contents of the directory on the target machine, found a jar file.
I downloaded the file to the local machine by starting a http server using python on the target machine.
After downloading, I used the jadx-gui tool to decompile and view the contents of the jar file.
While surfing the contents of the jar file, found the credentials for postgres database from the application.properties file.
Let’s try to see the contents of the database from the target machine using the found credentials.
Before doing that let’s upgrade our shell that we got back from our reverse shell to a more stable shell using the command: python3 -c 'import pty; pty.spawn("/bin/bash")'
After upgrading our shell run the following command to connect to postgres database. Check here to know more about postsgresql commands:
After surfing the database for sometime, found these password hashes
| Username | Hash | Role |
|---|---|---|
kanderson | $2a$10$E/Vcd9ecflmPudWeLSEIv.cvK6QjxjWlWXpij1NVNV3Mm6eH58zim | User |
admin | $2a$10$SpKYdHLB0FOaT7n3x72wtuS0yR8uqqbNNpIPjUb2MZib3H9kVO8dm | Admin |
First let’s try to crack the admin password. First create a file named hash.txt and store the admin hash to the hash.txt file. Next use the hashid tool to identify the hash type.
Now we have found the hash type and hashcat mode. It’s time to crack the password.
I wasn’t able crack the hash of the user kanderson. So I decided to move on.
I checked the /etc/passwd file for other users on the target machine using the netcat session that we got back from our reverse shell.
Found another user named josh. I tried to switch user as josh using the credential that we found. I was able to switch user and as well as I found the user flag.
Now it’s time to escalate our privileges. Since we know the password for josh, I exited the session that we got from reverse shell and logged in via SSH.
I was looking out for some common privilege escalation vectors. I checked for sudo -l.
From the output of the sudo -l command, we can see that the user josh can run the command ssh as sudo. I checked gtfobins for this and found this:
Using the above command, I got escalated my privileges as root and found the root flag successfully.
