Schedule Job¶
Overview¶
Technique fro job schedule
Element¶
Crontab¶
crontab exists on almost linux distribution
The overview
CRONTAB(1) User Commands CRONTAB(1)
NAME
crontab - maintains crontab files for individual users
SYNOPSIS
crontab [-u user] file
crontab [-u user] [-l | -r | -e] [-i] [-s]
crontab -n [ hostname ]
crontab -c
DESCRIPTION
Crontab is the program used to install a crontab table file, remove or list the existing tables used to serve the cron(8) daemon. Each user can have their own crontab, and though these are files in /var/spool/, they
are not intended to be edited directly. For SELinux in MLS mode, you can define more crontabs for each range. For more information, see selinux(8).
In this version of Cron it is possible to use a network-mounted shared /var/spool/cron across a cluster of hosts and specify that only one of the hosts should run the crontab jobs in the particular directory at any one
time. You may also use crontab(1) from any of these hosts to edit the same shared set of crontab files, and to set and query which host should run the crontab jobs.
Running cron jobs can be allowed or disallowed for different users. For this purpose, use the cron.allow and cron.deny files. If the cron.allow file exists, a user must be listed in it to be allowed to use cron If the
cron.allow file does not exist but the cron.deny file does exist, then a user must not be listed in the cron.deny file in order to use cron. If neither of these files exists, only the super user is allowed to use cron.
Another way to restrict access to cron is to use PAM authentication in /etc/security/access.conf to set up users, which are allowed or disallowed to use crontab or modify system cron jobs in the /etc/cron.d/ directory.
The temporary directory can be set in an environment variable. If it is not set by the user, the /tmp directory is used.
OPTIONS
-u Appends the name of the user whose crontab is to be modified. If this option is not used, crontab examines "your" crontab, i.e., the crontab of the person executing the command. Note that su(8) may confuse
crontab, thus, when executing commands under su(8) you should always use the -u option. If no crontab exists for a particular user, it is created for him the first time the crontab -u command is used under his
username.
-l Displays the current crontab on standard output.
-r Removes the current crontab.
-e Edits the current crontab using the editor specified by the VISUAL or EDITOR environment variables. After you exit from the editor, the modified crontab will be installed automatically.
-i This option modifies the -r option to prompt the user for a 'y/Y' response before actually removing the crontab.
-s Appends the current SELinux security context string as an MLS_LEVEL setting to the crontab file before editing / replacement occurs - see the documentation of MLS_LEVEL in crontab(5).
-n This option is relevant only if cron(8) was started with the -c option, to enable clustering support. It is used to set the host in the cluster which should run the jobs specified in the crontab files in the
/var/spool/cron directory. If a hostname is supplied, the host whose hostname returned by gethostname(2) matches the supplied hostname, will be selected to run the selected cron jobs subsequently. If there is
no host in the cluster matching the supplied hostname, or you explicitly specify an empty hostname, then the selected jobs will not be run at all. If the hostname is omitted, the name of the local host returned
by gethostname(2) is used. Using this option has no effect on the /etc/crontab file and the files in the /etc/cron.d directory, which are always run, and considered host-specific. For more information on clus‐
tering support, see cron(8).
-c This option is only relevant if cron(8) was started with the -c option, to enable clustering support. It is used to query which host in the cluster is currently set to run the jobs specified in the crontab files
in the directory /var/spool/cron , as set using the -n option.
SEE ALSO
crontab(5), cron(8)
FILES
/etc/cron.allow
/etc/cron.deny
STANDARDS
The crontab command conforms to IEEE Std1003.2-1992 (``POSIX''). This new command syntax differs from previous versions of Vixie Cron, as well as from the classic SVR3 syntax.
DIAGNOSTICS
An informative usage message appears if you run a crontab with a faulty command defined in it.
AUTHOR
Paul Vixie ⟨vixie@isc.org⟩
Colin Dean ⟨colin@colin-dean.org⟩
cronie
The individual cron exist at individuals cron
# For details see man 4 crontabs
# Example of job definition:
.---------------- minute (0 - 59)
| .------------- hour (0 - 23)
| | .---------- day of month (1 - 31)
| | | .------- month (1 - 12) OR jan,feb,mar,apr ...
| | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
| | | | |
* * * * * user-name command to be executed
Privilege Escalation Via Cron Apr 17, 2020 4 minute read Photo by Lukas Blazek on Unsplash
If you use Unix, you should probably use "Cron". Cron is a super useful job scheduler in Unix-based operating systems. It allows users to schedule jobs that 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 in the /var/spool/cron folder. 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. By default, Cron will run as the root user when executing scripts and commands in this file. In Linux systems, the location for the system-wide crontab is /etc/crontab.
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.
Crontab syntax All crontabs follow the same syntax. Each line specifies a command to be run and the time at which it should run.
(1)(2)(3)(4)(5)
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:
For example, this entry will tell Cron to run the same commands, but as the root user:
30 21 * * * root cd /Users/vickie/scripts/security; ./scan.sh
Another useful thing to know is that if you wish to run a script every 5 minutes, then you should put */5 in the "minutes" field, like so:
_/5 _ * * * root cd /Users/vickie/scripts/security; ./scan.sh
Running scripts in batches It is also customary to place scripts that the system-wide crontab uses in the /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly directories, if they should run after those intervals.
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
Cron Privilege Escalation So how does Cron become a source of vulnerabilities?
Since Cron runs as root when executing /etc/crontab, any commands or scripts that are called by the crontab will also run as root. 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!
For example, let’s say the following line is in /etc/crontab. Every day at 9:30 pm, Cron runs the maintenance.sh shell script. The script is run under root privileges.
30 21 * * * root /path/to/maintenance.sh
Now let’s say that the maintenance.sh script is also editable by everyone, not just the root user. In this case, anyone can add commands to maintenance.sh, and get that command executed by the root user!
This makes privilege escalation trivial. For example, attackers can grant themselves Superuser privileges by adding themselves as a Sudoer.
echo "vickie ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
Or, they can gain root access by adding a new root user to the "/etc/passwd" file. Since "0" is the UID of the root user, adding a user with the UID of "0" will give that user root privileges. This user will have the username of "vickie" and an empty password:
echo "vickie::0:0:System Administrator:/root/root:/bin/bash" >> /etc/passwd
And so on. There are many more ways to escalate a user’s privilege on a Unix-based system. By exploiting a misconfiguration in a crontab, the attacker will be able to execute any command of their choosing and gain root privileges.
What if my file permissions are secure? Another common security hole is vulnerabilities in the scripts themselves. If a script behaves in an insecure manner and you run it as root using Cron, then that could introduce vulnerabilities too.
For example, attackers might be able to exploit a wildcard injection to escalate their privilege instead..
Conclusion 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! You could accidentally leave your system wide open to privilege escalation attacks.
I am trying to list all the cron jobs for all the users in my Ubuntu system using the following command:
for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done Why am I getting the following error:
must be privileged to use this -u command-linecron Share Improve this question Follow edited Mar 20, 2014 at 9:30 Aditya's user avatar Aditya 13.2k1717 gold badges6464 silver badges9595 bronze badges asked Mar 20, 2014 at 7:16 Computernerd's user avatar Computernerd 1,38155 gold badges1717 silver badges2121 bronze badges Add a comment 1 Answer Sorted by:
Highest score (default)
from https://askubuntu.com/questions/436734/why-do-i-get-an-error-saying-i-must-be-privileged-to-use-crontab-u 4
You don't have the necessary permissions to read other users' crontabs, either run as root or use sudo to invoke crontab -u, e.g.
for user in $(cut -f1 -d: /etc/passwd); do sudo crontab -u $user -l; done or
awk -F: '{print $1}' /etc/passwd | xargs -n1 sudo crontab -lu
Reference¶
https://askubuntu.com/questions/436734/why-do-i-get-an-error-saying-i-must-be-privileged-to-use-crontab-u