Introduction
In Linux systems, administrators frequently use automated task schedulers to perform routine maintenance, backups, and system updates. The most common utility for this purpose is Cron. While Cron is incredibly useful, misconfigured scheduled tasks can introduce severe security vulnerabilities.
Scheduled tasks are dangerous when trust and write access do not align. If a privileged task executes something that lower-privileged users can modify, the schedule becomes a delayed privilege-escalation mechanism.
In this lab, you will explore a scenario where a system administrator has created a maintenance script that runs automatically as the root user. However, the administrator accidentally left the file permissions too loose. You will learn how to identify this misconfiguration, understand its implications, and exploit it by injecting your own command payload to escalate your privileges from a standard user to root.
Enumerate Cron Jobs
In this step, you will learn how to enumerate system-wide Cron jobs. Cron is a time-based job scheduler in Unix-like operating systems. System administrators use it to schedule jobs (commands or shell scripts) to run periodically at fixed times, dates, or intervals.
System-wide cron jobs are often defined in the /etc/crontab file or within the /etc/cron.d/ directory. These configuration files specify the schedule, the user account under which the command should run, and the command itself.
That means cron entries reveal three critical facts at once: when code will run, under which identity it will run, and which file or command gets executed.
Let us inspect the /etc/cron.d/ directory to see if there are any custom scheduled tasks. Use the cat command to read the contents of the maintenance cron job file.
cat /etc/cron.d/maintenance
Output:
* * * * * root /usr/local/bin/maintenance.sh
The output shows a cron job scheduled to run every minute, indicated by the five asterisks (* * * * *). It is configured to run as the root user and executes the bash script located at /usr/local/bin/maintenance.sh.
Identify Writable Scripts
In this step, you will investigate the script executed by the cron job to identify potential security vulnerabilities. When a script is executed by a highly privileged user like root, any commands inside that script will also run with root privileges.
This is why writable script paths are a major escalation signal. Control of the script content becomes indirect control of the privileged scheduled task.
If standard users can modify this script, they can inject their own commands, which the system will then execute as root. This is a common privilege escalation vector.
Let us check the file permissions of the maintenance script using the ls command with the -l flag for a detailed listing.
ls -l /usr/local/bin/maintenance.sh
Output:
-rwxrwxrwx 1 root root 78 Oct 10 10:00 /usr/local/bin/maintenance.sh
Notice the rwxrwxrwx permissions at the beginning of the output line. This means the file is readable, writable, and executable by the owner, the group, and everyone else on the system. Because it is writable by everyone, your current standard user can modify its contents.
Inject a Root Command Payload
In this step, you will exploit the weak file permissions by injecting your own command into the maintenance script.
Since the script runs as root every minute, any command you append to it will also run as root. For a beginner-friendly and reliable proof, we will append a command that writes the output of id into a file in your project directory.
We will use the echo command to append this payload to the script. The >> operator ensures we add our payload to the end of the file without deleting its original contents.
echo "id > /home/labex/project/cron_pwned.txt" >> /usr/local/bin/maintenance.sh
You can verify that your payload was successfully added by reading the end of the file using the tail command.
tail -n 2 /usr/local/bin/maintenance.sh
Output:
echo "Maintenance run at $(date)" >> /var/log/maintenance.log
id > /home/labex/project/cron_pwned.txt
Wait for the Root-Owned Task to Run
In this step, you will wait for the cron job to execute your injected payload.
The cron job runs once every minute. When it runs, it will execute the id command as root and save the output to ~/project/cron_pwned.txt.
Wait for up to 60 seconds, then read the proof file:
cat /home/labex/project/cron_pwned.txt
If the exploit worked correctly, you will see output similar to this:
uid=0(root) gid=0(root) groups=0(root)
Congratulations. You have successfully hijacked a cron job to execute commands as root.
Summary
In this lab, you learned how to identify and exploit poorly secured system maintenance tasks to escalate privileges in a Linux environment. You started by enumerating system-wide cron jobs to find tasks running as the root user. Then, you investigated the target script and discovered it had weak file permissions, allowing any user to modify it. By injecting a reverse shell payload into the writable script and setting up a Netcat listener, you successfully hijacked the automated process and gained a root shell. This exercise highlights the critical importance of proper file permission management, especially for scripts executed by privileged automated processes.
