HTB: Cronos Writeup w/o Metasploit
Intro
This is another box we did as a group during a live hacking session. It was a lot of fun to learn other inputs and thought processes while solving this. If you would like to join us leave a comment below, it is free and all are welcome.
Recon
So, the first thing we did was run a nmap scan. We found a few open ports after running a version scan.
Enumeration
We checked port 80 to see what it was hosting and if there was any useful information to note. Please note, before we do our exploitations, we usually edit the /etc/hosts file. We added 10.10.10.13 cronos.htb to ours.
The home page didn’t give us much. The site was hosting 3rd party documentations and resources. From one of the links, it appears the server may have the Laravel web app installed. It could have been useful but we did not need it for the exploits.
There wasn’t much for us to use here just yet. So we re-examined the open ports and remembered port 53 was open. We queried the dns server for information on 10.10.10.13 and it returned another host admin.cronos.htb.
admin.cronos.htb brings us to a login page.
We thought about running a password cracker but we decided to throw some sql queries at it first. Why? Because there may be a sql database behind this web server with the creds we need to authenticate or bypass it. We tried a few from a list of sql queries I have and one of them worked.
Exploitation
Now we are presented with an admin tool that can run system commands for us. All this can be done remotely by accessing this web page. This reminded me of a DVWA challenge we did during one of our Cyber Thursday events. There is a command injection vulnerability that allows us to run our own system commands using the input field.
We found this after playing around with the input field and combining commands together using the & or the | symbol. For instance, 8.8.8.8 | whoami returns a user.
Eventually we found a reverse shell command to work and return a shell to our listening port. We started up a listener with netcat on port 4242. Next, we used a python reverse shell command from here, to connect back to our listener. Once we put that after the | and hit enter, we received a shell.
Privilege Escalation
Ok, now it is time to escalate our privileges. Running sudo -l does not return us anything. We checked netstat, saw a sql db running on the box but we did not try to enumerate that right away. Since the name of the box was cronos it only made sense to look at the cronjobs. The current user account we are using does not have any jobs running. You can use “crontab -L” to check cronjobs. Maybe root has some cronjobs. To find if root has cronjobs scheduled we used linpeas. We hosted linpeas on our attacking machine using a python web server python3 -m http.server 8000. Then we used wget to pull it down to the cronos machine.
Out of all the info we get from linpeas, we can see a cronjob is scheduled to run every minute. It is running as root and it is using php to run a file we have access to.
All we have to do now is upload a php reverse shell to cronos and rename it to match what the cronjob is looking for. The cronjob should execute our script for us and we should get a shell as root.
The top half of the picture above shows us downloading our php script artisan to the cronos server. The bottom half of the picture shows the artisan file, its contents, the artisan file being retrieved from the python web server, and then a shell as root from our netcat listener.
AAR
This box was a good challenge that forced us to brush up on our dns skills. There are few suggestions to prevent this from happening again in the future. One would be, preventing unauthorized parties from retrieving zone transfers. We were able to find the admin.cronos.htb box because of the zone transfer we did with the host command (host -l cronos.htb 10.10.10.13). My second suggestion, create an input validation script that prevents sql injection attacks. That should help prevent the login screen from being bypassed. Finally, tighter access controls. If root is being used to schedule jobs, then there needs to be better access controls. In addition, those files scheduled to run as root should be in a directory only root has access to. Otherwise, disallow the root account from running jobs.
Hopefully, you enjoyed this writeup. There are more coming to help me reinforce what I am learning. Simultaneously, others can benefit too! Here is a video walkthrough of this box.
