Most administrators check the cron jobs that they have on their server by just logging into their cPanel and clicking on the Cron Jobs link under the Advanced section.
The more advanced administrators check their cron jobs by typing the following command in the shell:
crontab -e
So, in the absolute majority of cases, an administrator does not directly open a physical file to check the cron jobs, he checks them through an interface whether through cPanel or the Linux crontab (or a different interface altogether). Now, the question is, where does the cron information come from? In other words, where is it stored?
Well, on a CentOS server (which is the typical server used for a WHM environment), cron jobs are stored in files under the directory /var/spool/cron. Each file is named after a user (each user is typically the username of a cPanel account), and each file contains the cron jobs for that particular user.
Now, you might be wondering, is there any point to this? Why should anyone check the actual physical file instead of using an interface to view the cron jobs? Well, because, in some cases, some information is not displayed in the interface, and, in most of these cases, this information is malicious. Let us give you an example…
Yesterday morning we were hired to add a cron job to a Joomla website, and, for some reason, we were having problems creating this cron job using the cPanel interface and using the crontab -e command, so, we went straight to editing the physical file containing the cron. Here’s what we did:
- We ssh’d to the server as root.
-
We opened the file cpanel-user which is located under the /var/spool/cron folder (you will need to change cpanel-user to your cPanel username) for editing the following way:
vi /var/spool/cron/cpanel-user
-
We saw this code:
SHELL="/bin/bash"
MAILTO=""
DOWNLOAD_URL="http://[malicious-domain].com/u/w.gz"
LOCAL_FILE_PATH="/home/[cpanel-user]/public_html/libraries/joomla/client/client.php"
TMP_DIR="/var/tmp"
As you can see in the above code, only the first line is benign, the remaining lines are malicious. On the bright side, however, the code had no effect because it was missing the actual cron job. Its seems that the Joomla website we were working on had a cron job hack identical to the one we described here (a malicious file was being downloaded from DOWNLOAD_URL, and was being extracted to the client.php core Joomla file), and whoever fixed it didn’t fully cleanup the cron file (he just removed the cron job from the interface). So, we cleaned up the file and, after doing that, we were able to add the cron job through the interface.
So, it’s always a good idea to regularly check the contents of the files located under the /var/spool/cron folder. If you find anything suspicious and you are not sure what to do, then please contact us. We are experts in Joomla security, our work is quick, and our fees are always affordable!