Hack the Box Writeup - Stratosphere

This is my writeup of retired Hack the Box machine, Stratosphere. An interesting box, with more than a few rabbit holes that need avoiding.

Enumeration

So let's get right into it. We start, as always, with our nmap scan.

$ nmap -sC -sV -p- -oA nmap/scan 10.10.10.64

Just three ports open; 22, 80 and 8080. It also looks like the same HTML is being served by both 80 and 8080.

Browsing to the site presents us with the frontpage of a credit monitoring company, but it seems to still be under development as either the links don't work or simply take you to an "under construction" page.

Let's get gobuster fired up, and see if we can find anything else.

$ gobuster -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://10.10.10.64 -t 50

In short order, we find two new directories. The first one there, /manager could be interesting so we browse to it, only to be presented with a HTTP basic authentication prompt.

If we can find credentials for this then maybe we can use a file upload exploit, but as we have none at the moment and the default credentials of tomcat:s3cret don't work lets take a look at the other directory that gobuster found - note the capitalisation of this directory. Browsing to /monitoring will just give you a 404.

Now, this looks more interesting. Another site listed as a credit monitoring portal, but with login and registration links! However, this soon leads to dissappointment, as both the registration and login links just lead to more "under construction" pages.

Exploit

However, take note of the URLs for this new site. They have a fairly uncommon extension of .action. A quick google shows that this extension probably means the site is running apache struts, and more googling reveals that (depending on the version) there are remote command execution exploits available. So let's download one and give it a try. The first one we find is called struts-pwn, so copy it locally and let's give it a go.

We have remote command execution! Ignore the error messages given, everything still seems to work fine.

Now lets see if we can get a shell.

Hmmm, normally this would be fairly easy once we have RCE, yet all outgoing traffic seems to be blocked. We can't even ping back to our machine :(

Further Enumeration

And even more frustratingly, our tomcat user doesn't have permission to access the home directory, so we need to escalate our privileges further before we can get the first flag >:(

As we can't talk back to our machine, we can't get any enumeration scripts onto the box, so we have to do things the old fashioned - manual - way.

This is where I remembered the Tomcat Manager url from our initial enumeration. Now we have command execution we should be able to read the tomcat configuration files.

$ python struts-pwn.py -u http://10.10.10.64/Monitoring/example/Welcome.action -c 'cat /etc/tomcat8/tomcat-users.xml'

Frustratingly, these credentials still don't seem to work. So back to the drawing board now we have eliminated that rabbit hole.

Checking the working directory that our commands are running in, reveals a file called db_connect.

Seems we have some more credentials, and given the name of the file it leads me to think it will be for a database. Checking the running services we can see that MySQL is running on this machine.

Lets see what databases we can see.

$ python struts-pwn.py -u http://10.10.10.64/Monitoring/example/Welcome.action -c 'mysql -h localhost -u admin -padmin -e "show databases"'

That users one looks interesting, and listing the tables in there shows one table only, called accounts. And that table contains more credentials.

Shell Access

Now we have credentials for a user called richard, we refer back to our nmap scan and see that ssh is running, so let's give that a try.

We have a shell! And access to the first flag (finally).

Privilege Escalation

Now we have a proper foothold, we start our enumeration all over again. Looking in our home directory, we see a python script called test.py. Checking sudo -l we also see that we can run this python script as root.

I noticed that the sudoers entry had a wildcard in there which led me down a rabbit hole again as I searched for ways to abuse the wildcard and be able to run something other than the intended script. No joy there though.

Running the script gives us some puzzles to solve, all hash related. You can simply google for the answers to the first few questions as the hashes used are MD5, SHA1 and MD4. The last one is a little trickier however. We can cheat a little and take a look at the source code of the script.

We can see the final hash algorithm used is Blake2b-512. There's no easy online hash checker for this one so we will need to break out john the ripper.

Copy the hash into a file on your machine, and fire it off. It doesn't take long at all.

$ john --wordlist=/usr/share/wordlists/rockyou.txt --format=Raw-Blake2 hash.txt

But then it turns out all this hash cracking was all for naught as the script that should be run after entering all the correct phrases seems to be missing >:(

Hopefully that will be the last rabbit hole we waste our time on!

Going back to the source code of the python file I noticed how the user input is not being sanitised in any way, and with some googling I find that the input() function in python2 is the equivalent of eval(raw_input()), which means that we can enter valid python code as the input and have it execute! Fortunately for us, this is where the wildcard in the sudoers file helps us as we can specify which version of python we want to run.

So if we fire up the script using the following:

$ sudo python2 /home/richard/test.py

Then enter the following python code, we get our root shell :)

__import__('os').system('su')

And there we have it, root user and access to the final flag. Quite a few twists and turns on this one, but we got there in the end.