Introduction:

Hi all! In this article I’m going to be tackling Awkward, a medium difficulty Linux machine on hackthebox.com. Happy hacking!

Information Gathering:

Let’s get started with an nmap scan. You know the drill:

We can see in the scan output that we have two ports open, port 22 and port 80 which is running an HTTP server. Let’s check out the IP address in our web browser to see if it takes us anywhere. Doing so changes the URL to “hat-valley.htb”. Add this to your /etc/hosts file so you can access the site.

Taking a look at hat-valley.htb, we can see that it is the website for a company that sells hats, with a note on the page saying that an online shop is coming soon:

Let’s now enumerate directories. I‘m using the tool dirsearch as you can see in the output below:

We found some interesting directories that may reveal vulnerable information. Let’s dig a little deeper and enumerate the /js directory:

The scan returns /js/app, /js/app.js and /js/custom.js.

Looking over the page hat-valley.htb/js/app.js, we find the directory /hr, which appears to be a login page. We also uncover a few api routes, including /api/all-leave, /api/submit-leave, /api/login, /api/staff-details, and /api/store-status. Just going off it’s name, /staff-details sounds promising, but we can’t access it yet.

Now that we have an idea of the website’s directories, let’s enumerate for subdomains. I’m using the tool wfuzz, as you can see below:

Our scan returns the subdomain store.hat-valley.htb. Add this to your /etc/hosts/ file. Attempting to navigate to the page, it appears we will need credentials first:

Now that we have an idea of directories and subdomains, let’s examine what’s happening behind the scenes when we interact with the site. Open up Burp Suite and navigate to hat-valley.htb in the proxy browser. Taking a look at the request being sent to the server when we first access the page, we can pretty quickly spot something interesting:

Do you see the cookie token value? I wonder what will happen if we change the guest value to admin. You can either manually change the value of the cookie token or automate the process using Burp Suite’s Match and Replace feature.

With our new cookie, we can try to view the hat-valley.htb/staff-details page. Unfortunately, we have no such luck.

Hmm. Well what if we delete the value of the cookie all together? Go back to Match and Replace in Burp Suite and edit your entry to have an empty cookie token value. Return to hat-valley.htb/staff-details:

Voila! It looks like we have usernames and password hashes, as well as full names, emails, and phone numbers of Hat Valley staff members. This is information that should never be accessible to an attacker. Note that “Bean Hill” is listed as the system administrator.

We’re going to want to see if we can crack these hashes, but first we need to find out what type of hashing algorithm they are using. With the help of the hash identifier tool at hashes.com/tools/hash_identifier, we learn that the passwords are hashed with SHA256.

Time to get cracking! Let’s save the hashes in a text file on our machine, and then use the tool Hashcat to see what we can get. The wordlist I’m using is rockyou.txt, but you can use your preffered wordlist of choice:

Looks like we have a hit! Hashcat uncovered the password chris123 for the user christopher.jones. Now that we have user credentials, let’s see if we can log into hat-valley.htb/hr:

We’re in, folks!

Foothold:

Taking a look around, we can see that the dashboard page includes staff details, website metrics, an online store status refresh button, and a form field that can be used to request time off.

Clicking on the refresh button doesn’t appear to do anything. Intercepting the request in Burp Suite however shows us that clicking it triggers a GET request which points to a URL:

Let’s highlight the URL and send it to Burp Suite’s decoder so it’s easier to read:

As you can see, the request points to store.hat-valley.htb, the same subdomain we found earlier in our enumeration. I have a feeling this subdomain is going to be important to us later on.

I wonder if we can use this request to learn anything else about the server. Let’s see if we can use it to enumerate for open ports via server-side request forgery (SSRF). To do this I am using wfuzz and a wordlist of numbers from 1–65,535 (65,535 being the highest possible port number). As you can see in the scan output below, we uncovered port 80, port 3002, and port 8080:

We can see what’s on port 3002 by navigating to the follow link:

http://hat-valley.htb/api/store-status?url=%22http://localhost:3002%22

The link takes us to a page that contains API documentation for the Hat Valley Website:

Lateral Movement:

The documentation for /api/all-leave reveals that requesting it executes a vulnerable awk command, which must be where this box gets its name from:

The awk command passes the user variable. We can take advantage of this by manipulating the user variable to include what we want, such as local files. Therefore, if we change the user variable to /etc/passwd, we should gain access to that folder.

The value of the user variable is the JWT token username. In order for this to work, we will need to know the JWT token secret, which is found in the cookie. Let’s once again log into hat-valley.htb/dashboard in Burp Suite and intercept traffic:

We can see our jwt token in the request, which is as follows:

Cookie: token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImNocmlzdG9waGVyLmpvbmVzIiwiaWF0IjoxNjY5MjYyOTg4fQ.mPvd5Oei9kuiUWZKJd-AZdK266XBZTsbxB-6JU2MrUY

We can crack the jwt token with the tools jwt2john.py and John, as I have below:

Now that we have the secret, we are able to craft our own JWT token to include what we want, in this case the /etc/passwd file. To do this I’m using the site jwt.io:

Our custom cookie token is:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6Ii8nIC9ldGMvcGFzc3dkICciLCJpYXQiOjE2NjY4OTc2NTJ9.GecJ1WIjoxgr5v4KmFV8xnx5QGKZnQMnjCQsGfWXlVA

Back in Burp Suite, let’s create a request calling for /api/all-leave, and replacing the cookie token with ours:

Send the request, and the server should respond with the /etc/passwd folder:

Now we’re getting somewhere! The user bean looks promising because if you remember, we saw that Bean Hill is the system asministrator for the Hat Valley website. Let’s see if we can read bean’s .bashrc file. Back in jwt.io I edited /etc/passwd to /home/bean/.bashrc, as you can see below:

In Burp Suite, again edit the token in a GET /api/all-leave request and send it off. The server should respond with the file. In the file, we find an alias called backup_home that contains a bash script:

Let’s take a look:

We see a .tar.gz file here that is interesting. Let’s download it using the curl command:

Unzip the file and take a look around. In the file /.config/xpad/content-DS1ZS1 we find a username and password:

Username: bean.hill

password: 014mrbeanrules!#P

At the bottom of the document it says, in bold, MAKE SURE TO USE THIS EVERYWHERE. Hopefully this means that these credentials will work in more than one place. Let’s keep that in mind.

Let’s try to log into the SSH server using these credentials:

We’re in! Listing the contents of our directory shows us there’s a file called userflag.txt. That’s our first flag!

Privilege Escalation:

Remember the subdomain store.hat-valley.htb? Navigating to it in the Burp Suite proxy shows us that the authorization request is coming from an nginx server. Let’s take a look at the nginx configuration file in our shell:

We have the username admin as well as a hashed password.

Using a hash identifier tool, we learn that the hash is MD5. Let’s try to crack it with Hashcat:

Unfortunately this does not return any results.

Do you remember in the /content-DS1ZS1 file there was a note at the bottom saying to “use this everywhere”? Let’s see if we can login in using the user bean.hill’s credentials.

Logging in with username: bean.hill and password: 014mrbeanrules!#P does not work, however using the username: admin with the same password gets us in!

As you could have guessed, this is the online shop for Hat Valley. We can find the source files for the site inside our shell by navigating to /var/www/store. Taking a look at README.md, we learn that files are being stored offline in /product-details and /cart. Additionally, we learn that the header for products is used to verify products:

Checking the cart actions file, the following is especially interesting:

The sed command here is being used to delete data from the cart file. Maybe we can use this to achieve remote code execution.

We can see how this works by adding an item to the cart:

Back in the /var/www/store/cart directory we can see a new file has been created:

Now let’s create a reverse shell file and put it in the /tmp folder and giving it the permissions that we need:

In order for the shell to work, we need to modify the file that was created in /cart. Unfortunately, we don’t have the permissions to do this, so we will make a copy of the file and delete the original. Then we modify it so that sed executes the reverse shell for us:

Make sure your netcat listener is running, and navigate to your cart in the Burp Suite proxy browser. Intercept the request and edit the item_id value:

Send the request, and if all has gone well you should recieve the shell connection:

You should now be connected to the server as the user www-data. Looking around, we find an interesting file in the /var/www/private directory called leave_requests.csv.

We can exploit this by taking advantage of our shell file, and adding a line that executes it to leave_requests.csv.

Taking advantage of our shell file, we can add the following line that executes it to the mail file:

echo '" --exec="\!/tmp/rev.sh"' >> leave_requests.csv

Navigating to the root folder, we can find the flag:

Do a little happy dance, you just pwned Awkward!

---