Mango

Overview

This HackTheBox machine was one of the first attempts that fully relied on a web application and no CMS involved. Personally, webapp security is a realm I’ve felt to be my weakest so it was definitely a challenge for me to try it and gain access to the host. Unfortunately, not much of resources I can share as reference other than the ones below.

Just like my other walkthroughs, I hope this one is as enjoyable.

References

  1. Nosql injection username and password enumeration script

  2. GTFOBins/jjs

Let’s begin!

Initial Enumeration: Footprinting and Scanning

First of, we need to identify how to reach the system. In other words, we need to identify what are the services available from this machine.

Let's start by adding this machine's IP address to the hosts file and create an alias:

My go-to tools in this phase, which are typically used by many to start enumerating, are:

  • masscan: very nice port scanning tool that allows finding open ports quickly. To me this is a tool to narrow down the scope of the enumeration so we can focus on open ports only when using nmap.

Here, I am designating the interface to use when communicating to the HTB machine (-e) which will be the HTB VPN interface, along with -p to designate the port range to target but I will target ALL TCP and UDP Ports, and the transmission rate of packets per second (--rate). Similar to this, you could also run something like this:

  • nmap: I think most people in the information technology and security space know what nmap does. It is a very versatile Port scanning tool which also allows you to use scripts to further target the services found. Just like anything, it can be a useful tool while it can also be damaging if the user is not careful.

What I typically start with when using nmap is:

MASSCAN

As you can see, we only found some basic ports; basically two of them are for HTTP/HTTPS traffic and SSH. Let’s Inspect them further with nmap.

From the port scan, we found HTTP is available but we get a HTTP 403 status code which means we are forbidden from accessing http://mango.htb. At the same time, HTTPS service gives us the certificate information showing a different CN from just mango.htb, that being staging-order.mango.htb. We now need to enumerate both mango.htb, and also add staging-order.mango.htb into the hosts file to then enumerate it as well.

Using curl on http://mango.htb gives us the same HTTP 403 status code we got through nmap which confirms at the moment going to HTTPS is the way to go. But before we move forward it’s worth elaborating on the fact that both HTTP and HTTPS services in this host support the following HTTP method:

With -X GET, we can specify the type of HTTP Request and the extra verbosity always comes in handy. Note to self: as curl tell us, using -X with GET is inferred, but defining the actual HTTP method I want to use is something I always like to show for my own reference.

Now let's sample what's in HTTPS. We need to use -k to access the site insecurely, or ignoring the certificate verification as we cannot validate the signer, and simply focus on what the verbose and what the HTTP HEAD method gives us.

Similar to using -X GET, we could use -I when using curl with the HTTP HEAD method but like I said, I like showing the method I’m using for my own reference.

Adding staging-order did not reveal anything but going to the /analytics.php page from mango.htb shows a system interface where it is possible to upload a payload. Even though it looked like it would allow uploads using the file formats json, js, and xml, this route also did not work and is more of a rabbithole, so for the sake of this write-up I will simply skip this.

If we look back at what was found in our port scanning phase, we can see HTTP is open flagged as a 403 Forbidden when used with mango.htb only as http://mango.htb. We also see that staging-order exists, based on the information found in the certificate, why don't we try accessing http://staging-order.mango.htb/?

AND that worked!! We got an admin login page, but on a HTTP site?!

After attempting some basic SQLi to bypass authentication which ended up as a waste of time, I had to seek further clues from other members in the HTB Forum and someone brought up the possibility of the name of the site Is a clue itself and nothing specific to mangoes. This made me think if ”Mango” and ”Mongo” from mongoDB could be related.

Exploitation and Gaining Access

As we only have two inputs to interact with the site, SQL injection seems to be The most logical approach, and from the name guessing mentioned earlier I had some reading to do.

Something I had not realized which I found from my research is the fact that MongoDB is based on NoSQL, and this research led me to find a way to do a 'nosql injection' as MongoDB is a nosql database.

This basically pointed me to a nosqli exploit that can dump usernames and passwords which we can try; a link was provided in the overview section as reference.

NOSQL USER-PASS ENUM SCRIPT

AND we got me some usernames. Now let's try the same but using -ep password switch:

This worked just as good as with -ep username, and now we have both credential sets:

Now, one thing left to do is to attempt through HTTP and if successful, we can SSH as either one of the users.

After trying both users in the login page and successfully accessing an 'Under Plantation' internal page and also the same as admin, let's try with mango first through SSH:

We are in the system as mango, but we don't find much other than two user home directories for both mango and admin users. Let's attempt and switch user to admin after seeing there is a user admin home directory:

And we are also in as admin. Let's keep going:

AND we found the user.txt flag file; time to attempt Privilege Escalation!

Privilege Escalation

Now, let's try and see what is accessible by the user admin, like any globally executable binaries. As nothing else was outstanding on this host in terms of vulnerabilities to exploit, we must rely on enumeration.

Nothing stands out to be special other than /usr/lib/jvm/java-11-openjdk-amd64/bin/jjs. As we look into GTFOBins, there is a way to run this as an interpreter just like python. Also, there is a way to do file reads, so we can also go this way and try to read any files owned by root and see if we are successful.

Keep in mind, the user admin does not have sudo rights to anything, so anything we do, we have to run it as a normal user.

As we try the file read approach with /etc/shadow, which only root and sudo users can read.

Successful Test

This basically means we can use jjs to read stuff owned by root. There is also a way to get a reverse shell by using the following sample:

Let's try this as a one-liner.

Failed Attempt

But running it and expecting a reverse shell lead us nowhere as we ended in a reverse shell owned as admin and no privilege escalation happened:

Per our test to the shadow file, let's try now the file-read, but this time directly to the root flag in a bash script and see what we get. Let’s remember one thing about HTB machines; typically the root flag files are found in the root user home directory /root.

Script

Execution

AND WE GOT THE ROOT FLAG!!!!!!

This basically means we can read files owned by root through jjs, but we cannot get a reverse shell as root.

PreviousTraverxecNextOpenAdmin

Last updated

Was this helpful?