Detecting cron tasks run by another user

cronprivileges

I am currently working through the Nebula challenges on exploit-exercises.com, and one of the challenges relies on a script being run by cron.

This is run by another user (flag03) and the user I am logged in as (level03) doesn't have privileges to run crontab -u flag03 to view the job.

The hint clearly indicates the script is run by cron. Additionally, it is the only script in the /home/flag03 directory, so we would likely investigate further.

However, if this was the real world, I wouldn't know that this script was being run by cron.

Therefore the question is, how would I detect that the task was being run from the perspective of an unprivileged user?

I have tried the following:

while true; do ps au | grep <scriptname> | grep -v grep; done;

This allows me to see processes that run for a significant length of time, but not ones that exit almost immediately. It also presumes I know the name of the script.

The specific environment is Ubuntu. I can't use apt-get, but I have access to gcc.

Any ideas?

Best Answer

Which version of Ubuntu? If it's using systemd, you could rely on the cron cgroup created by systemd I guess, as all processes started by cron will be a direct child.

One of the option to get this information is to use the ps command with something like:

ps -eo user,pid,cmd,unit | grep cron.service | grep flag03

Related Solutions

Cron Sudo – Why Cron Fails to Run Sudo Commands in Scripts

Sudo has some special options in it's permissions file, one of which allows a restriction on it's usage to shells that are are running inside a TTY, which cron is not.

Some distros including the Amazon Linux AMI have this enabled by default. The /etc/sudoers file will look something like this:

# Disable "ssh hostname sudo <cmd>", because it will show the password in clear.
#         You have to run "ssh -t hostname sudo <cmd>".
#
Defaults    requiretty

#
# Refuse to run if unable to disable echo on the tty. This setting should also be
# changed in order to be able to use sudo without a tty. See requiretty above.
#
Defaults   !visiblepw

If you had captured output to STDERR at the level of the shell script rather than the sudo command itself, you would have seem a message something like this:

sorry, you must have a tty to run sudo

The solution is to allow sudo to execute in non TTY environments either by removing or commenting out these options:

#Defaults    requiretty
#Defaults   !visiblepw

Using Cron to restart a systemd user service

systemctl --user needs to talk to the D-Bus session, which involves setting at least DBUS_SESSION_BUS_ADDRESS and perhaps XDG_RUNTIME_DIR; typically:

XDG_RUNTIME_DIR=/run/user/$(id -u)
DBUS_SESSION_BUS_ADDRESS=unix:path=${XDG_RUNTIME_DIR}/bus
export DBUS_SESSION_BUS_ADDRESS XDG_RUNTIME_DIR
systemctl --user restart myservice.service

You might want to look at systemd timers instead of cron for this.

Related Question