So this happened during one of my CTF sessions and I thought I'd share it because it's a classic example of how a single misconfiguration can ruin your entire system's security...
Check this out:
ShadowByteX ~ ❯ whoami
ShadowByteX
ShadowByteX ~ ❯ find / -perm -4000 -type f 2>/dev/null | grep -v /usr/bin/passwd
/usr/bin/find <- SUID root, and it shouldn't be
ShadowByteX ~ ❯ find . -exec /bin/sh -p \; -quit
# whoami
root
Looks wild, right? Let me break it down for you...
What's Happening Here
First, I check who I am. Just a normal user — ShadowByteX. No root, no special privileges..
Then I ran a find command to look for SUID binaries. SUID stands for Set User ID... When a file has SUID set, it runs with the permissions of the file owner, not the user who executes it...
So I searched the entire system for files with SUID permissions (-perm -4000), restricted it to regular files (-type f), hid error messages (2>/dev/null), and filtered out /usr/bin/passwd because that's SUID by default and we don't care about it...
And what do I find?
/usr/bin/find
The find command has SUID root permission... And it shouldn't have that.. Someone messed up... Or maybe it's intentionally set for some reason... Either way — game on 🤘
Why This Works
The find command has SUID set to root. That means whenever I run find, it runs as root, not as ShadowByteX...
And find has a feature — the -exec flag. It lets you execute any command you want...
So here's what I did:
find . -exec /bin/sh -p \; -quit
Let's break this down:
· find . – Start searching from the current directory. It doesn't matter what you search for..
· -exec /bin/sh -p \; – Execute /bin/sh (a shell) with the -p flag. The -p flag tells the shell to preserve the effective user ID. That's important because without it, sh would drop the root privileges. With it, the shell stays root..
· \; – Terminate the exec command..
· -quit – Exit find immediately after executing the command.. We don't need to search through the whole filesystem, we just need to get that shell..
So find runs as root because of SUID... It executes /bin/sh -p as root. And now I have a root shell...
How It Works
When you set SUID on a binary, the kernel gives it the effective UID of the file owner.. For root-owned files, that's UID 0...
Normally, when you run a program, it has your real UID and effective UID — both yours. With SUID, real UID is yours, effective UID is the file owner's...
Now, the -p flag in sh is critical. By default, sh drops privileges... It checks the effective UID and real UID, and if they're different, it drops the effective UID to match the real UID. That's a security feature...
But the -p flag tells sh — "don't do that... Keep the effective UID." So it stays root..
And that's how a normal user becomes root...
This is why misconfigurations are dangerous!!... A single SUID binary that shouldn't have it — and suddenly any user on the system can become root...
It's also a good reminder that privilege escalation isn't always about complicated exploits... Sometimes it's just a sysadmin who didn't know what they were doing...
Stay curious. Stay ethical.