Hack the Box - Starting Point: Oopsie

Welcome to part II of the "Starting Point" module on Hack the Box! If you haven't already, be sure to check out my first write-up on "Archetype" to catch up! Here is the link:

Without further ado, let's get to the hacking!

Enumeration

To begin, let's start our connection to HTB. Next, let's scan our target:

nmap --script vulners -sV 10.10.10.28

Again, there are a few different ways/tools you can use to get a good idea of your target's vulnerabilities. Instead of running the above nmap command, we could also run the following:

sudo nmap -sS -sV 10.10.10.28

Personally, I believe the first command syntax is far better since it generates a list of any known vulnerabilities that could be exploited. The command is even nice enough to give links to each vulnerability allowing one to further research how to attack their target.

So far we can see that ports 22 (ssh) & 80 (HTTP) are open. Let's open a web browser and try to connect to this IPv4 address.

We are taken to a globally renowned (sort of) electric vehicle manufacture's webpage.

Whenever I'm pentesting a website, I always start with using dirbuster to find any hidden directories that could lead to something interesting.

dirbuster -l /usr/share/wordlists/rockyou.txt -u https://10.10.10.28/

Dirbuster is a java application that was developed by OWASP for allowing users to map directories within web servers. Dirbuster works by taking a common wordlist (often rockyou.txt will do just fine) & using the wordlist as a source of possible values to brute force a website in order to find some common directory or file names.

By sending repeated HTTP-GET requests to the webpage, Dirbuster is able to give us a better idea of the structure of the website. This in turn allows us to further our attack.

As seen in the output above & below, we see some new possible paths to add to the end of our current URL (https://10.10.10.28). It's interesting to note that certain paths (such as /cdn-cgi/) have a 403 response code indicating that area is off-limits to us...for now. In contrast, we can see a few 200 response codes that indicate that we can successfully traverse to those files or directories.

Note, though the "Time to Finish" says 14 days, we can see from the Terminal window a list of paths that were found right away (unfortunately I don't have a GPU - if I did then the time would be drastically reduced). Of the listed options, the one of most interest here is the path "https://10.10.10.28/cdn-cgi/login". Let's input that into our URL search bar and see what happens.

We could've also found this path by looking at the source code for "https://10.10.10.28/". To inspect a webpage's HTML code simply right-click and click "View Page Source".

Whenever you see a login in page on a site, you can often try using another software tool called Hydra to try to brute force the password. However, in this case, we already have the password from the previous HTB challenge! This is why note-taking coupled with constant research is so critical to one's success!

So let's try putting our past credentials for "administrator" which was "MEGACORP_4dm1n!!". Note, this doesn't work so let's just try "admin" as the username instead. Just like that, we are in.

Now, I'm going to start by examining the source code. Again simply right-click on the page and click "View Page Source".

From viewing the HTML code we can verify the tabs that we can already view: "Account", "Branding", "Clients", "Uploads". This didn't give us any new information but it's worth a shot to see if there was anything else. Notice, we are currently logged in as "admin"

Next, let's click through each tab to see if perhaps the source code on any of these other pages gives us something interesting. You will notice when you click on "Uploads" we get the following displayed:

Viewing the source code we can verify that we indeed need "super admin" rights to access this.

It's worth pointing out that often upload pages can be abused by attackers seeking to upload certain malware in order to carry out their goals. Let's see if we can do the same. However, we are currently stuck as a logged-in user without the proper permission to access this page. To get around this let's use a software tool that every cybersecurity specialist should be aware of, Burp Suite. This software tool allows us to set up our own proxy in order to analyze/manipulate web traffic between our machine & web traffic. Open up Burp Suite, it should already be installed on your Kali VM. If not, go here:

On another side note, I highly recommend you do the FREE online training provided by the makers of Burp Suite. Extremely helpful when it comes to exploiting web vulnerabilities. Here's the link:

Many bug hunters use Burp Suite in order to claim bounties, which can often be lucrative if you know the discipline.

For us, we are going to use Burp Suite to make the web page think we are indeed the super admin.

There are two ways you can tell Burp Suite to gather your web information. One is by installing FoxyProxy in addition to Burp Suite's certificate & manually setting up the service or you can use the new chromium-based browser to get right to work! I'm going to use the browser since one could make a whole other article detailing how to set up Burp Suite with FoxyProxy.

When Burp Suite starts click to create a Temporary Project. Once inside, then click on either Open Browser buttons.

Once the new browser opens just copy & paste the current URL we are trying to exploit: https://10.10.10.28/cdn-cgi/login/admin.php?content=uploads. You'll need to provide the login credentials from earlier in order to gain access again. At this point, your Burp Browser & Burp Suite should look similar to mine (be sure to view the HTTP history tab - also turn off Intercept within the Intercept tab, otherwise this will cause your webpage to hang, freeze.

Examing our Request window, we see the webpage assigns users an id parameter associated with their account. We also can see towards the bottom that the website keeps track of users, like most websites, via cookies. Perhaps if we could change our id parameter we can fool the webpage to think we are a different user with super admin rights...Bingo.

Right-click on this capture HTTP history (#24 in my case) and click Send to Intruder. Click on the Positions tab and then click Clear. Next, highlight the parameter being passed into id & click Add.

Click on the Payloads tab next followed by selecting Numbers as the Payload type. Under Payload Options let's tell our attack to start at number 1 & go to 100. Set the step count, our iterator, to 1. We are hoping within this range we will get back a response that will give us the id for the user with super-admin rights. Click Start Attack.

After the attack has finished, let's organize our output by the Length tab. From here we can see, id=30 at the top of our list among unique values. There are other unique values, these are just other users on the website.

Going back to our initial HTTP history capture, let's send off the request to the Repeater. Again simply right-click on the captured web traffic and click on Send to Repeater. From here modify the Request window so that the parameter id is equal to 30. You can also try inputting other found unique values for some more practice.

As per the output above, we have discovered that the user cookie associated with the super admin account is equal to 86575. Now let's click on the Upload tab within the web browser so we can capture the web traffic through our proxy set up by Burp Suite. Now simply send this new capture to the Repeater & substitute the current user cookie for the super admin cookie value, 86575.

Click on Send followed by right-clicking & choosing the option Show response in browser. Your output should show that you can now successfully access the Uploads tab.

Foothold

Now let's focus on establishing a foothold onto the target. To start, notice how in the URL we can see this website interacts with PHP scripting language. Let's use that to our advantage by using a PHP reverse shell payload that's already installed on our Kali VM.

First copy /usr/share/php/php-reverse-shell.php to your current working directory. Next, change the IPv4 address to point back to your attacking machine. You don't necessarily need to change the port, just remember the port number when setting up the Netcat listener.

Before setting up the listener, please make sure to add a firewall rule to allow the target machine to communicate back to us over our specified port:

sudo ufw allow from 10.10.10.28 proto tcp to any port 1234

Now, set up the Netcat listener next:

nc -lvnp 1234

Now upload this file to the Uploads webpage. You'll need to once again send this request through Burp Repeater in order to use the cookie associated with super admin, 86575, to successfully complete this step. If you need help, reread the above steps. It also helps to watch youtube tutorials/walkthroughs!

Great! We've now uploaded the file to create our reverse shell with the target. The problem though is we don't know exactly where this file went. For that, we will use another software tool called Dirsearch. This tool is a more advanced web scanner that can aid us in further discovering the directory setup of a target system.

git clone https://github.com/maurosoria/dirsearch.git
cd dirsearch
python3 dirsearch.py -u https://10.10.10.28 -e php

First, download the tool from the above Github link. Next, cd into the dirsearch directory. From there run the last snippet of code to have Dirsearch scan the webserver to determine where uploaded files are stored. Here's my output, notice the very bottom:

This is telling us that uploads to this webserver are being stored at the following path: https://10.10.10.28/uploads. Run the following curl command in order to gain a reverse-shell to the target:

curl https://10.10.10.28/uploads/reverse-shell-php.php

*I had to re-upload my file twice due to getting 404 errors. If at first, you also get 404 errors just try to upload the file again.

Once the Netcat listener activates run the following command to get a better-functioning shell:

SHELL=/bin/bash script -q /dev/null

Now that that's done, let's go to the home directory to see if there are any users/flags to investigate.

Heading into the user Robert's directory we are able to capture the flag of the user!

*you might need to use vim in order to see the flag

Lateral Movement

Since we are on a web server, let's head over to /var/www/html/ to see if there is anything interesting. Off the bat, I notice there's a directory for cdn-cgi which leads to another interesting directory called login. From here there is a db.php file that stores Robert's credentials.

Make sure to take note! Now that we have these credentials let's switch users, thus laterally moving across the system.

su robert

Privilege Escalation

Once we have successfully logged in as the user Robert, run the id command to see if this user belongs to any interesting groups. We invoke this step to see if we can use the group's permissions to escalate privileges. Sure enough, this user is a part of the bugtracker group. Let's run a find command to see what sort of files/access this group has on the system.

find / -type f -group bugtracker 2>/dev/null

Next, let's see what sort of permissions this binary has:

ls -la /usr/bin/bugtracker

Interestingly, there is a binary (an executable) that this group can run with root permissions thanks to the setuid. Do research on setuid bits. Often this can allow for privilege escalation since whoever has permission to run the file (for instance a user within a group of which this group has permissions) is able to run the file as the owner, which in this case so happens to be root!

Running /usr/bin/bugtracker we can see that this binary generates output based on a certain input. In this case, I just used 1 as my input.

To get an idea of how this is happening we will use the strings command. This command will look through non-text files to find characters to allow the user to get some readable information on the content of the non-text file.

strings bugtracker

As per our output, we see that the cat command is using a relative path versus an absolute path. This can be abused. Truthfully, I struggled to understand these last couple of steps & the concepts they involved. To expand my knowledge I did some Googling which led me to this article I found that was very helpful in understanding why a relative path & setuids can be used for privilege escalation.

Now let's create a temporary binary called cat that well allow us to spawn a shell as root. Run the following commands in sequence:

export PATH=/tmp:$PATH
cd /tmp/
echo '/bin/sh' > cat
chmod +x cat

Don't worry if you get an error after the last command saying "Operation not permitted". Again, to summarize, we just created binary within the path of the /tmp/ directory whose contents should allow us to spawn a shell as root.

Now head back over to /usr/bin/bugtracker. Run the bugtracker binary, input 1, and voila we should now be root! Now start searching for the root flag!

*remember to use vim to see the flag

Post Exploitation

Had I not watched & follow some other walkthroughs I would've missed this step. With this whole StartingPoint module in HTB, as in real life, it's wise to continue searching throughout the system to see if there are any more credentials that can hopefully be used to further exploit.

As you can see above, if you run the command ls -la a couple of times from root's folder, you will eventually find a .XML file containing another user's credentials. Save these!

Again thank you for reading another one of my writeups! I truly hope this helps! I would appreciate any & all feedback, comments, or reshares! Happy ETHICAL hacking!