Linux Privilege Escalation – Scheduled Tasks

Introduction

Linux-based operating systems, like most systems, have a way of scheduling the launch of programs or scripts based on certain time intervals to help automate recurring tasks. This can often become weaknesses and allow attackers to escalate privileges to root if improperly configured.

This guide will go through the main methods used to exploit scheduled tasks.

Cron Jobs

Cron is a Linux utility used to create scheduled tasks (called cron jobs) that run at specific time intervals and it is the most common one nowadays.

Cron jobs are normally saved in text files, where each line represents a cron job. They are made of three main elements:

1. The time interval at which the script or command is executed
2. User to execute the command/script as (optional)
3. Command/script to execute

For example, the cron job below will execute the “ifconfig” command as the “stef” user at 10:30 in the morning of every day of March:

Cron jobs can be stored in the following places:

1. A specific user’s or the system’s crontab
2. A script contained in one of the /etc/cron.* folders

This can be confusing, but luckily a command can be used to list all existing cron jobs:

crontab -l; ls -alh /var/spool/cron; ls -al /etc/ | grep cron; ls -al /etc/cron*; cat /etc/cron*; cat /etc/at.allow; cat /etc/at.deny; cat /etc/cron.allow; cat /etc/cron.deny; cat /etc/crontab; cat /etc/anacrontab; cat /var/spool/cron/crontabs/root

Enumeration scripts such as LinPEAS will enumerate cron jobs as well.

Systemd Timers

Just like cron jobs, systemd timers can be used to execute commands or scripts at specified time intervals. The real benefit of using timers is that they trigger actions not only based on time, but also based on certain system events, such as system boot, hardware state changes etc. which makes them also useful as a system maintenance tool.

They are also a lot easier to configure and to manage, as they are all stored in the systemd journal.

Systemd timers are stored in the /etc/systemd/system/ directory and they are made of the following:

1. A unit section, that contains a name or description for the timer
2. A timer section, that specifies the time interval or event to act as trigger
3. An install section, that specifies the target unit to be used for the timer

The below timer downloads daily apt updates at 6am and 6pm:

The following command can be used to display all available systemd timers:

systemctl list-timers --all

Enumeration scripts such as LinPEAS will also enumerate systemd timers.

Exploiting Scheduled Tasks

There are three main ways to exploit scheduled tasks:

• Weak File Permissions used for the cron files or script being run by them
• Missing absolute path in binaries and commands, which can be exploited through the PATH Environment Variable
• Wildcards being used when running commands, using wildcard injection

Exploiting Weak File Permissions

If the current user is allowed to edit either the file in which the cron job is stored, or a script/binary that is being executed by the cron job, this could allow to execute commands as the user running the cron job.

Example

When viewing the system crontab, one of the cronjobs executes a /tmp/stef.py script every minute:

When looking at the stef.py script, all it does is removing all files within the /var/www/html/backup directory:

When viewing the permissions allocated to this file using ls -la, it looks like it can be edited by all users:

The easiest way to exploit this to escalate privileges to root is to create a /bin/bash binary with SUID permissions, so that it can be executed as root:

After the cron job runs, this has created the /tmp/stef bash SUID binary, which can then be executed with the -p flag, which does not reset the effective user id and allows to run a script as the owner, to gain root access:

Exploiting Missing Absolute Paths

The Linux environmental path variable allows users to run commands or scripts without having to run specify 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.

Example

When viewing the system crontab, one of the cronjobs executes a stef.sh script every minute, although it doesn’t provide an absolute path.

It also looks like the “PATH” variable in crontab includes /tmp, which is world-writable.

Creating a stef.sh script in the /tmp directory that will create a stef2 bash SUID binary, the same vector used above to escalate privileges, and assigning to it execute permissions:

After the cron job has run and has created the stef2 binary, executing it with the -p flag to become root:

Exploiting Wildcards in Commands

Commands can use wildcards as arguments to perform actions on more than one file at a time, also called globbing, which will apply said command to all files and folders in the current directory.

For example, when running cat /etc/cron.d/*, this will output the contents of all files contained in the /etc/cron.d directory:

How does the attack work?

This attack exploits a weakness in tar, a Linux utility used to create .tar.gz or .tgz archives.

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.

Example

When viewing the system crontab, one of the cronjobs creates an archive of the contents of /var/www/html and saves it to /tmp/backup/ every minute.

Creating a stef.sh script in the /tmp directory that will create a stef2 bash SUID binary, the same vector used above to escalate privileges, and assigning to it execute permissions:

Creating the required files and linking checkpoint-action to the script:

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

After the cron job has run and has created the stef2 binary, executing it with the -p flag to become root:

Conclusion

Scheduled tasks have been an exploitation vector for a very long time, as there has always been the need for automation, now more than ever.

They should be carefully configured, especially when executed as root, es they could lead to full system compromise. Systemd timers should be used when possible as they are less likely to be manipulated or tampered with.