Mailroom

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 3000 10.129.58.204
Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-16 02:08 EDT
Nmap scan report for 10.129.58.204
Host is up (0.17s latency).
Not shown: 65512 closed tcp ports (conn-refused)
PORT      STATE    SERVICE
22/tcp    open     ssh
80/tcp    open     http

Another HTTP port exploit. We can add mailroom.htb to our /etc/hosts file for this.

MailRoom

Visiting port 80 reveals a basic corporate website:

Viewing the paces reveals that this is a PHP based website. Within the functions available on the page, we can find a Contact Us page that tells us an AI will read our query.

Interesting, perhaps we can send a request that is processed or something. However, there's not much we can go on.

The webpage itself doesn't have much, so I opted to do a ffuf scan on the subdomains and directories present. When fuzzing subdomains, I found git.mailroom.htb.

Let's add this to our hosts file and enumerate further.

Gitea Source Code

There was a Gitea instance on the new subdomain. I didn't manage to find any exploits pertaining to this version. Within the repos present, we can see a staffroom repo by the user matthew.

Interestingly, we could view this repo without logging in. Within the auth.php files, we can find a new subdomain.

We can add this to our hosts file, but we are not authorized to visit it for some reason. Since we have source code for this website given, we can attempt to do CSRF to steal pages, and I think that the Contact Us page might be vulnerable to XSS.

When looking at the inspect.php file on Gitea, there's this code snippet that looks vulnerable to RCE:

This uses shell_exec with an argument that is not sanitised. This is the RCE point! There's a weak check for the RCE, as it does not block `. So we have to somehow send requests to this page after logging in, as this check is present on all pages:

By checking auth.php, we can see that this uses Mongo to authenticate users:

Doing some source code reading reveals that there is a 2FA token created, and we need this token to login by accessing /auth.php?token=. The script takes an email and password parameter from a POST request, and passes the unsanitised input directly to a query:

So the exploit path is to somehow use NoSQL to retrieve the token, and then login. However, this seems to send the 2FA token to the user's email, so stealing it won't work. It seems that we need to somehow steal credentials from this.

Viewing the Gitea users, we can find two:

We might need to use these somehow. Also, the script seems to be vulnerable to blind NoSQL injection based on the error messages it sends. Based on the auth.php script, if get a true condition, we would get the Check inbox for 2FA token message. If not, we would get the Invalid email or password error.

XSS + CSRF

When we submit any queries, this is the response that we get:

If we enter a simple <script> tag and view the page, we can confirm that we have XSS.

This tells me that Javascript is being executed on the page, and we can attempt to steal page contents via CSRF.

I tried using some Javascript to load the index.php page from the staffroom repo to exploit it.

We just have to URL encode this entire thing and submit it as part of a POST request.

Then, we would receive a callback with the page contents:

We have successfully stole the page, and now we can exploit this by stealing the token via NoSQL injection as found earlier. Based on this, we can attempt to send requests to auth.php and possibly brute force the password for a user.

Since we can use XSS, we can make the webpage process Javascript that is hosted on our HTTP server. First, I created a quick script to send the XSS payload and retrieve the inquiries URL that we need to visit to trigger the payload.

Then, we need to craft a special JS script that would allow us to brute force the password, and exfiltrate it onto our web server. This can be done using regex Blind NoSQL injection.

While there is probably a way to automate this to retrieve the full password with one run, I was unable to make that work for whatever reason and could only brute force 1 character each time. Here's the Javascript code I used to brute force it:

With this, I was able to retrieve the password character by character:

After repeating this a load of times and resetting the machine even more times, I was able to retrieve 69trisRulez! as the full password. This password happens to be the password to SSH in as tristan as well.

Port Fowarding -> RCE

Now that we have access to the machine, we can do some port forwarding to make the website available for us. I used chisel:

Then, we can add staff-review-panel.mailroom.htb to our /etc/hosts file as 127.0.0.1. Afterwards, we can visit the website!

We already found a password, so we can login. This would cause the application to send a mail to tristan, which we can read in /var/mail/tristan.

Visiting the link would refer us to the dashboard.php:

Great! We have logged in. Earlier, we found an RCE in the inquiry_id parameter, so let's exploit that.

Great! Now we can simply download a shell and execute it.

Now we are in a docker container.

Git Credentials

Within the /var/www/staffroom directory, we can find a .git repository:

We could read the logs, but since Gitea is present, there probably isn't anything that I haven't already found. Instead, we can look at git config to see if there are passwords:

Great! We cannot directly SSH into matthew, so we can use su from tristan. The password would be HueLover83#.

Then, we can capture the user flag.

Privilege Escalation

KPCli Processes

When on matthew, I ran a pspy64 to enumerate the processes running and if we could exploit them. Here's the interesting output:

Interestingly, there are a lot of kpcli processes running, which are not normal. We can also use ps -aux to see this:

Within the user's home directory, there are also some kdbx files present:

Perhaps what's more interesting is that the PID keeps increasing, indicating that new processes keep spawning in. I used ltrace and strace to see what these processes were doing, and I found something rather interesting. When I first did it I huge list of responses, but there were a bunch of read instructions. As such, -e read was used to filter these out.

This was obviously retrieving the root password each time and quitting. I interecepted the response again and got something different:

The password was obviously being passed here. After trying a bit more, we can barely retrieve the password from this.

There was this \10 character present, and I didn't really know what it was. When we view the ASCII table, \10 is revealed to be a backspace character, meaning there's an intentional typo in the password. We can then use the password retrieved to access the .kdbx file we found.

Within this file was the root password.

Now we can su to root and finish the machine.

PreviousInjectNextMonitorsTwo

Last updated