Hack The Box: Bucket (AWS)

What will you learn? The Hack The Box retired machine Bucket is a medium difficulty Linux box. It features “LocalStack” which simulates a local AWS environment. So this is a great introduction to cloud penetration testing against S3 buckets for cloud storage and DynamoDB for a cloud database. This box also features lateral movement with the artifacts obtained in the post-exploitation process to finally root the machine. This is one of a number of boxes featuring cloud components that I am exciting to cover. See LocalStack here: https://github.com/localstack/localstack

Let’s start enumerating the machine:

We see the following ports are open: SSH and HTTP (redirecting to bucket.htb, so we should add this to our hosts list). If we find credentials we will return to SSH, otherwise we will focus on the HTTP service.

Upon visiting the page we’re seeing some feed updates from users perhaps, a naming convention for emails (maybe support is a user), and some pages to visit. We should fully enumerate the web application for other virtual hosts, source code, robots.txt, sitemap.xml, stored cookies, requests going elsewhere, other directories etc.

Upon inspection of the source code on the home page we notice another term to add to our /etc/hosts file, which we can soon explore: s3.bucket.htb. This is something I did not pick up while fuzzing for virtual hosts.

Visiting that page does not return anything too exciting, neither does going to those other directories on it and going up one by one to see what is inside each.

I was unable to click on any of the objects on the home page to go anywhere else. Fuzzing for other directories did not pan out on the base page either. So I started to fuzz for directories on the http://s3.bucket.htb page and ended up finding some 200 OK returning pages.

If we visit the /shell page which is an exciting phrase to see, we don’t get anything. If we curl it we do get some information about the confirmation of AWS and we see that the server is running 'Hypercorn-h11, which Wappalyzer will also show us in the background too.

So we know that this target is running an s3 bucket and AWS. We can install the Amazon Web Services CLI on Linux with apt-get install awscli and then see if we can connect to this AWS bucket. Notice that it will ask for credentials when we try to connect to an endpoint. Configuring it without credentials will not work, we need some filled parameters but after we do so it will connect us to the endpoint.

We can interact with this more, see what is inside this remote bucket. Then we can work on copying over a configured reverse shell to our parameters as there is a functionality to copy files to s3 buckets.

Now that we have that configured, we can upload it and visit http://bucket.htb/reverse.php to call the shell back to our listener on nc -nvlp PORT

So we have an initial foothold on the target, you will notice, you cannot obtain the user.txt flag yet. We have to work on escalating probably to the user roy who is sitting in the home directory.

This project directory is interesting though. We should comb through the information to see if we obtain any important information. We should also probably elevate our TTY to a better session. python3 -c 'import pty; pty.spawn("/bin/bash")'

(inside the nc session) CTRL+Z;stty raw -echo; fg; ls; export SHELL=/bin/bash; export TERM=screen; stty rows 38 columns 116; reset;

There is a potential directory to look at once the root user is acquired.

Some more interesting information. There is a docker container that we could potentially break into.

Looking at the internally listening ports with ss -ntplu we can see there is a potentially interesting port 8000 running.

Looking for apache web server configuration files we can see one exists. If we grep these running ports with that file we can gather more information about the relevance here. We can see by catting the file that root is running the port 8000.

This is important to note too, the port on 8000 is being run at /var/www/bucket-app

We can see that the s3.bucket.htb server is correlating to port 4566. This is good information for us to know as well.

From looking at the files earlier in Roy’s home directory under projects, at the db.php file we know there is a DynamoDB database running on this target. We can attempt to use the AWSCLI to interact remotely with the endpoint. Listing the tables that dynamodb has we can see there is a user table. Then we can scan the contents of that user table and find some credentials we may be able to use.

We’re able to clean up the output it is returning more using JQ to organize the JSON and calling just on .Items to see just what we want too.

Attempting the password for the bottom one, we are able to log into the Roy user account and acquire our user.txt flag. At this point it would be worth seeing if we could SSH into the box using ssh roy@10.10.10.212 and the password we confirmed the usage for.

Circling back to the directory we noted earlier on port 8000. We can see there is a plus sign on the directories / files in here, this means there are extended permissions on these.

Using the command getfacl we can see those extended permissions more clearly and that our ‘Roy’ user can read these.

We need to more granularly inspect the index.php file in order to understand what is going on.

So we need to learn how to use PD4ML in order to attach files: https://old.pd4ml.com/cookbook/pdf-attachments.htm

We are going to port forward on the SSH session in order to browse to what is being hosted: ssh -L 8000:127.0.0.1:8000 roy@10.10.10.212

We read the index.php so we understand the functionality of the website. So in order to exploit port 8000 we are going to have to create a new table in DynamoDB to replicate the alerts table. We can do this using the AWS CLI to create the table and check the list of tables to confirm we added our table. Something I noticed is that the application will delete your table quickly, so you need to replicate these steps quickly.

Now we need to create a JSON file to attach with the expected ransomware name. We can do this with the following command: aws --endpoint-url http://s3.bucket.htb dynamodb put-item --table-name alerts --item '{"title":{"S":"Ransomware"},"data":{"S":"This is a test"}}'

Use SCP to quickly copy over the file from /var/www/bucket-app/files/ before it gets deleted using:

Install a tool called pdfdetach and use it with the following parameters to exfiltrate the data from the embedded file it is putting in there:

After confirming that this worked, we can attempt to acquire the ID_RSA key from the root directory.

Acquire the file from the SCP method and repeat the pdfdetach method and cat the ID_RSA file that gets spit out from the process.

Then make the ID_RSA file match 600 permissions, login as the root user, and acquire your root.txt flag