Rewind

There are other ways to abuse a cron job in addition to the tar hack I just described. Remember that I actually had read/write access to the backup shell script that is called by the cron job, so I didn't have to use the wildcard trick described in the tar example.

Instead, I could have just edited the backup script directly. Because it runs as the root user in the crontab file, I could have filled it with all sorts of weird and wonderful payloads to gain access to superuser privileges.

For example, I could have added a line to the backup script that altered the configuration in the /etc/sudoers file, our old friend from earlier, which wrote a rule that provided root user access:

echo "chris ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

Or, I could have created a new user in the /etc/passwd file:

echo "superuser:0:0:superuser:/var:/bin/sh" >> /etc/passwd

And, what about adding a password hash that you created yourself to the /etc/shadow file? Have a think about the following (redacted to hide my "root" password):

echo "root:$6$Ldsxp$rDAaI/0SC/kfs7VL/:19217:0:99999:7:::" >> /etc/shadow

With a bit of testing, you can soon

su -

to the root user on the target machine with impunity.

I'm certain that having seen these examples, you will fully understand the implications of having any type of access to cron jobs that run as the superuser. And, even having visibility of what such cron jobs are doing clearly gives an attacker an advantage.

Conclusion

I hope the content I've covered will encourage you to learn more about ethical hacking. It is both useful and edifying to understand how attackers think. It is also comforting to see the limitations attackers face, hindered by only a few well considered Linux security controls. The knowledge that you gain practicing PrivEsc can only make you more effective at defending your systems.