Abusing File Permissions

Planting Something and Waiting

Enumerating Linux and Hunting Exposed Secrets were about finding things: the machine’s layout, then the secrets people left behind.

This one is different. Here you plant something yourself, and let the system run it as root.

It all comes back to the one sentence:

Find a file that runs at high privilege, but that you are allowed to write.

If root runs a file, and you can edit that file, then you decide what root runs.

Two classic places this happens: cron jobs and /etc/passwd.

Cron Jobs

cron is the Linux job scheduler. It runs tasks on a timer, and system jobs run as root.

The vulnerability is a pairing:

• system cron jobs execute with root privileges
• admins constantly write cron scripts with sloppy permissions

Root runs it, you can change it. That’s the whole opening.

Beat 1: Find What Cron Runs

Enumerating Linux showed the /etc/cron* directories. The logs go further, they show jobs actually firing, and who they run as:

Same script, every minute, run by root. That’s a recurring trigger and a privileged runner. Now the only question is whether you can touch the file.

Beat 2: Check If You Can Write It

Read that permission string with the eyes from Enumerating Linux:

The file is owned by root, but that final rw- (the others triad) means every user can write to it. Owned by root, writable by you. The trap is set.

Beat 3: Weaponize It

Append a reverse-shell one-liner to the script. The original backup command still runs, so nothing looks broken:

Hint: don’t memorize these. revshells.com builds a reverse shell in any language or style you need, just plug in your IP and port and copy the one-liner.

Beat 4: Wait for the Clock

Start a listener and let the next tick do the work:

Within a minute, cron runs the script as root, your line included, and a root shell lands in your listener:

The permission string was the entire story. -rwxrwxrw- on a root-owned script that cron runs is a root shell waiting for the next minute. Nothing exotic, just a write bit in the wrong place.

Writable /etc/passwd

This one is a beautiful trick, and it’s built on two facts most people don’t know.

Fact 1: root Is a Number, Not a Name

What makes an account all-powerful isn’t the word “root”. It’s UID 0.

Any account with UID 0 is a superuser. A second UID-0 account is every bit as much root as root itself.

So if you can create an account and set its UID to 0, you haven’t made a normal user, you’ve made another root.

Fact 2: A Password in /etc/passwd Beats /etc/shadow

Normally password hashes live in /etc/shadow, which normal users can’t read. The /etc/passwd file just carries an x placeholder in the password field.

But there’s a legacy behavior still honored today:

If you put a real hash in the second field of an /etc/passwd line, Linux accepts it, and it takes precedence over /etc/shadow.

And /etc/passwd is world-readable by design, sometimes world-writable by misconfiguration.

Putting Them Together

If you can write to /etc/passwd, you can add your own root user:

First, generate a password hash. openssl does it in one line:

Then append a new account, with a hash in field two and zeros for UID and GID:

Switch to it with the password you chose:

Those two zeros (:0:0:) are the whole point. You just minted root.

Finding /etc/passwd world-writable seems unlikely, until you meet the hybrid third-party integrations that quietly loosen its permissions for “usability.” The find / -writable sweep from Enumerating Linux catches it in seconds.

Where This Leads

Both attacks here were about a write bit in the wrong place: a script you shouldn’t be able to edit, a config file you shouldn’t be able to touch. Spot the loose permission, and root falls out.

But sometimes the permissions are perfect and the system still hands you power, through the special ways Linux lets programs run as someone else: setuid binaries, capabilities, and sudo. That’s Abusing System Components.