Abusing Cron Jobs
Let’s focus on another family of privilege escalation techniques
and learn how to leverage insecure file permissions.
For this section, we will assume that we have already gained access
to our Linux target machine as an unprivileged user.
In order to leverage insecure file permissions,
we must locate an executable file that not only allows us write access,
but also runs at an elevated privilege level.
On a Linux system, the cron time-based job scheduler is a prime target,
since system-level scheduled jobs are executed with root user privileges
and system administrators often create scripts for cron jobs
with insecure permissions.
In a previous section, we demonstrated where to check the filesystem
for installed cron jobs on a target system.
We could also inspect the cron log file for running cron jobs.
It appears that a script called user_backups_ under /home/joe/__
is executed in the context of the root user.
Judging by the timestamps, it seems that this job runs once every minute.
Since we know the location of the script,
we can inspect its contents and permissions.
The script itself is fairly straight-forward:
it simply copies the user’s home directory to the backups subdirectory.
The permissions of the script reveal that every local user can write to the file.
Since an unprivileged user can modify the contents of the backup script,
we can edit it and add a reverse shell one-liner.
If our plan works,
we should receive a root-level reverse shell on our attacking machine after,
at most, a one-minute period.
We’ll first change to the scripts directory,
Then write our reverse shell one liner to the file.
All we have to do now is set up a listener on our Kali Linux machine
and wait for the cron job to execute.
The cron job executed, as well as the reverse shell one-liner.
We have successfully elevated our privileges and have access
to a root shell on the target.
Although this was a simple example,
it is not uncommon to find similar situations in the field since
administrators are often more focused on pushing systems into production
rather than securing script file permissions.