Awkward

Enumeration

From Nmap There were just two open ports discovered, putting the IP address directly in the address bar redirects to hat-valley.htb so I had to add that address to my /etc/hosts file to access the domain.

I checked the website but there isn't much going on, no active link, decided to run FFUF to see if I could find subdirectories or Subdomain. No subdirectory was found but I did found a subdomain, store...

...The store subdomain requires login credential which I didn't have, at least not yet

I decided to take a closer look at the website. I notices it's running on vue.js which usually have an app.js file.

skimming through the file. I saw some reference to /hr subdirectory. apparently my wordlist didn't have this entry.

Checking the /hr webpage and it's another login page. looking at the packet through Burp and I noticed the cookie below...

Changing the token from guest to admin and I got access to the hr dashboard

while still on burpsuite I noticed traffic to an API endpoint /api/staff-detail, I visited the endpoint but I didn't get anything, just some error...

...then, I decided to remove the cookie entry all together and I got full credential disclosure

Hash-id identified the hashes as SHA 256 however I was able to crack only one single hash.

with the cracked credential, I was able to succesfully login to Chris's account

Looking at the request in Burpsuite, there were two things that caught my attention, a "url" parameter with possible SSRF and a JWT token for the currently logged in user.

Tackling the JWT token first, I used jwt2john to crack the token and retrieve the secret key, now with this key I can creat a legitimate JWT token that would be accepted by the server...

On to the second item, the url parameter. as seen above the request was poing to store.hat-valley.htb which is was the same subdomain I discovered earlier.

why not try an SSRF attack and point the parameter to internal services. I decided to use the parameter to scan for internally open ports by using the SecList number wordlist for port ranges... from the scan We can see on three port are listening, 80,3002,8080.

Port 80 as we already know is running the hat-valley.htb website. nothing is running on port 8080 but port 3002...

...port 3002 is show the documention of the API running on the website. reading through the Doc, I come accross the "api/all-leave" subdirectory, the code on this page contains an AWK command which parses the user variable into the leave request csv file. supplying a crafted string substituted for the "user" variable we can retrieve sensitive files from the server

User

Seen below is what the api/all-leave request is supposed to look like, the user name is what we would be replacing with our payload. However, we need to craft our token using jwt.io

Using the JWT website. I created a username payload and replaced the value with the etc/passwd file. This way, I can retrieve list of actual user accounts on the server.

To retrieve the file, I simply replace the token with the previous one. As seen below, there are user bean and christine on the device.

I tried using same method to retrieve both users' ssh id_rsa file but they don't exist. then I tried to retrieve the .bashrc file. The purpose of a .bashrc file is to provide a place where you can set up variables, functions and aliases, define your (PS1) prompt and define other settings that you want to use every time you open a new terminal window.

It works by being run each time you open up a new terminal, window or pane.

On bean's .bashrc, I found reference to a bash script called backup_home.sh, the content is

#!/bin/bash

mkdir /home/bean/Documents/backup_tmp

cd /home/bean

tar --exclude='.npm' --exclude='.cache' --exclude='.vscode' -czvf /home/bean/Documents/backup_tmp/bean_backup.tar.gz .

date > /home/bean/Documents/backup_tmp/time.txt

cd /home/bean/Documents/backup_tmp

tar -czvf /home/bean/Documents/backup/bean_backup_final.tar.gz .

rm -r /home/bean/Documents/backup_tmp

Now, I know the backed-up file is in /home/bean/Documents/backup/bean_backup_final.tar.gz and I need to retrieve it using same method I have been retrieving files, but rather than use Burp I'll be using curl since we are trying to get a zip file

Once downloaded, I extracted the content and started seaching for any juicy content. after a file I found a file called content-DS1ZS1 containing todo list and password for user bean.hill.

Using the newly found credential, I was able to login into the server using SSH and got access to the user flag

Privilege Escalalation

The file says MAKE SURE TO USE THIS EVERYWHERE, I was eager to see whether this credential would work on the store.hat-valley.htb subdomain...it didn't work using same credential however, using the username admin, I got access.

The README.md file contains some To Do items about the store website, the most important being the fact the site doesn't contain a database but storing items offline in files.

After several enumerations leading to dead ends (including linpeas.sh), I checked the cart_action.php file and found the interesting usage of sed in the item removal from cart.

Adding an item to cart from the store and as seen below, the file appeares on file with a random id 15f3-b370-d1b-a7f8.

To exploit this, I need to creat a reverse shell, it had to be created in the tmp folder though as it automatically gets deleted in the cart folder.

Reverse shell has been created and as for the payload sed has a payload on gtofbin.

Once the item has been added on the cart from web, it gets created in file, however, this file can't edited due to our privilege so we have to delete the file and create another one with same name and apply the sed payload as seen below.

Now to trigger the attack, it file has to be deleted from the webpage, while the traffic is being intercepted with Burp.

The reverseshell worked and I got access to the www-data account. I copied pspy to the device to have insight over running services. From Pspy I noticed inotifywait running and listening to changes made to /var/www/private/leave_requests.csv.

From man page: Inotifywait efficiently waits for changes to files using Linux's inotify(7) interface. It is suitable for waiting for changes to files from shell scripts. It can either exit once an event occurs, or continually execute and output events as they occur.

We can see from the UID running the script that it's the privileged root.

I can create a payload using SUID tag to grant me access to /bin/bash and append this code to the leave_requests.csv file.

Running /bin/bash with the -p which, I got root access and hence root flag.