HTB Writeup Writeup

A fairly straightforward machine that can be initially compromised using an off the shelf exploit but needs a little fiddling for root.…

Enumeration

Starting with Autorecon and analysing the output we find a bunch of the tests failed with connection denied after initially determining that ports 22 and 80 were open. Trying to connect to port 80 in a browser fails too. After a waiting a bit the text on the website suggests some kind of DoS protection is in place, hence the tools failing.

Looking through the Nmap  output we can see that /writeup exists on the webserver. You can also find this by looking at /robots.txt.

A quick read through provides nothing much of interest, but looking at the page source we can see a CMS is in use.

Reading into this product it seems the admin URL is at /admin. Trying http://10.10.10.138/admin/ fails, but http://10.10.10.138/writeup/admin/ gets us a password prompt, so this software may well be installed.

Searchsploit turns up a bunch of potential exploits.

Initial Exploitation

The SQL injection that works on versions under 2.2.10 sounds like a good place to start as it doesn’t require authentication. Reading the code it uses a timing vulnerability to extract username, email and password seed before trying to crack the password. Sounds perfect. I checked the script and verified that the URL it uses was present under /writeup as I could see a 200 status returned in the dev console. Lets run it.

root@RD1734747W10:~/hackthebox/writeup# python 46635.py -u http://http://10.10.10.138/writeup/ --crack -w /usr/share/wordlists/rockyou.txt

I then tried the credentials on the admin url, nope, don’t work. I then try them on ssh and we’re in and can get the user flag.

Escalating privileges

Time for some more enumeration. I use LinPE at the point and the main thing it turns up are odd permissions on /usr/local/bin and /usr/local/sbin which allow accounts in the staff group to write files to the directories but not read them or list the directory contents.

Nothing else turned up, so I tried Pspy next, which allows process monitoring without being root.

Running this turned up a cronjob running as root, but the permissions didn’t let me get to this. I then tried starting a new ssh session while Pspy was running.

Okay, this looks interesting. A file is run as root on login and the path means the odd bin and sbin directories will be evaluated first.

The script just calls something called uname, so if we create a uname script in /usr/local/bin or /usr/local/sbin it will get called before the real uname.

The classic Python reverse shell should work nicely, with a listener on Kali started with nc -lvp 8080. The uname script is copied to /usr/local/sbin You have to be fairly quick as a cleanup script runs that deletes these new created files. Start a new ssh session and: