Privilege Escalation Via Cron
Exploiting Misconfigured Cron Permissions To Gain Root Access
--
Cron is a super useful job scheduler in Unix-based operating systems. It allows you to schedule jobs to run periodically.
Cron is usually used to automate system administration tasks. But for the individual user, you can use Cron to automate tasks like downloading emails, running malware scanners and checking websites for updates.
Today, let’s dive into how to use Cron and the security risks of a misconfigured Cron system.
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
There is also a system-wide crontab that administrators can use to configure system-wide jobs. 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.
Crontab syntax
All crontabs follow the same syntax. Each line specifies a command to be run and the time at which it should run.
* * * * * <command to be executed>
- - - - -
| | | | |
| | | | ----- Weekday (0 - 7) (Sunday is 0 or 7, Monday is 1...)
| | | ------- Month (1 - 12)
| | --------- Day (1 - 31)
| ----------- Hour (0 - 23)
------------- Minute (0 - 59)
For 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 /Users/vickie/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>
For example, this entry will tell Cron to run the same commands, but as the root user: