Command Triggers
Finding commands that are / can be executed with elevated privileges
Last updated
Finding commands that are / can be executed with elevated privileges
Last updated
Cron Jobs are a default way to execute commands or scripts in regular intervals. You can make scripts run every 2 minutes, every hour, every 3rd day of the month, etc. They execute commands as certain users, so if we as a low-privileged user can change some behavior of these commands to get us as shell as that other user, we escalate privileges.
Cron table files (crontabs) store the configuration for cron jobs. The system-wide crontab is located at /etc/crontab which is often readable by all users:
Know that you can't always find the source for cron jobs, as they may be hidden in unreadable files by your user. Tools like can show starting process in realtime in such cases to hypothesize about Cron Jobs
Here the top 4 jobs are pretty standard. Using the run-parts command they just say to run the scripts inside /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly. They also say exactly when it will run, indicated by the first 5 values. The /etc/cron.daily directory for example runs every day at 6:25 AM.
In the example above, there are also two overwrite.sh and compress.sh scripts, which run every minute (indicated by the * * * * *, here's a tool). These are often interesting because they run very often, allowing us lots of chances to mess with them.
Tip: Use the date command to see the exact current time. Cron jobs execute at the 0-second mark so you'll know exactly when your payload should have executed.
You can even use watch -n 1 date to get a date output that updates every second, so you can count down to exactly when it executes
Using this command you get a list of commands you can execute as other users:
If you get any error message like these, it means you probably cannot use this technique for this user:
Sorry, user <username> may not run sudo on <machine>.
<username> is not in the sudoers file. This incident will be reported.
In the best-case scenario, you can run any command (even sudo /bin/bash) as root (without a password):
Another more common example is that you can only execute a certain program or the NOPASSWD tag is not set meaning you do need to enter the current user's password:
Another common syntax to recognize is which other user you execute the command as, as this is not always root:
env_keepSometimes the program itself is not exploitable, but there is an env_keep option. This option allows you to keep environment variables while executing the program, that normally get cleared.
Set User ID (SUID) binaries are programs that when executed by anyone, will perform actions with the permissions of the owner of the program. All programs are files, and the SUID bit on a program is just a permission like read/write/execute that you might be familiar with. The SUID bit can be seen as an s character where there would normally be an x for executable permissions:
When this s permission is set by the owner, it means that for anyone executing this program, it will be like the owner of the program ran it. If the file owner is root for example, then you would be executing the program as root. This sounds very dangerous because it is.
Note: The Set Group ID (SGID) bit is very similar. When executed by anyone, it just sets the permissions to those of the group owner of the file. The second name in the ls output is the group, so you can see what permissions you would be getting
As a defender, you need to be absolutely sure that the program that is executing cannot do things other users shouldn't be able to do, like reading files, writing files, or executing arbitrary commands. Programs like sudo in the example above are secured by asking for a password and checking permissions very carefully. But this is also why a vulnerability in sudo or any other SUID program is a big deal.
To find all files on the system having the SUID or SGID bit set, you can use a find command:
Note: Shell scripts do not use the SUID bit, these only matter on ELF executables. This was a decision made because SUID binaries should be as secure as possible (more info)
These rules often trigger scripts, which are very valuable to read and understand when possible. More configurations like the variable are interesting to check, but most exploitation comes from the commands that are executed, and how you can influence them. For example, by overwriting the scripts directly with sufficient permissions, or writing malicious files that it uses.
Normally no environment variables are set at all (env_reset is doing this). All names added via env_keep+= can be set in your shell session, and will be kept when you run sudo.
If it were !env_reset instead, all variables would be kept. This is even more exploitable as many ways exist to use environment variables for unintended behavior (see ).
An important note is that executing these programs keeps the environment variables that you set. This opens up a whole load of new inputs the binary does something with. The variables are filtered, but the variable is kept! If developers aren't careful to use absolute paths, this resolution can be overwritten by an attacker.