Untangling Users — Linux Luminarium Writeup

A writeup for the Untangling Users module in pwn.college’s Linux Luminarium, covering four challenges on Linux privilege escalation: su, switching users, cracking password hashes, and sudo. I've documented both what worked and the mistakes I made along the way, since the errors were where most of the learning happened.

Background

The Linux Luminarium is pwn.college’s introductory Linux track. The Untangling Users module introduces how privilege escalation works on Linux, starting with the older su command and progressing to modern sudo.

A key concept up front: /usr/bin/su and /usr/bin/sudo both have the SUID bit set (-rwsr-xr-x, owned by root). That means when any user runs them, they execute with root's effective privileges, which is what allows them to grant elevated access. Both also hash your input password and compare against stored hashes in /etc/shadow.

Challenge 1 — Becoming Root with su

Goal: Use su to become root and read the flag. The root password was given as hack-the-planet.

My errors:

1. I passed the password as an argument. I ran:
2. text

• sudo su hack-the-planet

1. This was wrong on two counts: su takes a username as an argument, not a password, and sudo wasn't privileged in that workspace yet. It failed with sudo: workspace is not privileged.
2. I didn’t realize the password prompt is blind. When you type at Password:, nothing echoes — no asterisks, no dots. My first su attempt failed with su: Authentication failure because I likely mistyped (or didn't realize input was being accepted at all).

What worked:

text

su
# at Password: type hack-the-planet, press Enter
cat /flag

The prompt changed from hacker@...:$ to root@...:# — the # confirms root.

Flag: pwn.college{cvRysdiN4xcv3nKSDhbkNjpoFgX.QX1UDN1wyN0czMzIzW}

Takeaway: su is interactive. The password is typed at the prompt, not passed as an argument. The $ → # prompt change is your confirmation of elevation.

Challenge 2 — Other Users with su

Goal: Switch to the zardus user (password dont-hack-me) and run /challenge/run.

My errors:

1. I copy-pasted the placeholder username literally. The challenge example showed su some-user, and I ran exactly that:
2. text

• su some-user

1. It failed with su: user some-user does not exist. The warning even told me: "you are invoking 'su' without specifying the 'zardus' user." The example was a placeholder, not a real account.
2. I ran /challenge/run before switching users, which correctly rejected me: "You are the hacker user... You MUST become the zardus user."

What worked:

text

su zardus
# at Password: type dont-hack-me
/challenge/run

Flag: pwn.college{Mif5Mw0rWf5EmcEudLpH9Rn41Y7.QX2UDN1wyN0czMzIzW}

Takeaway: su <username> authenticates against that user's password. With no argument it defaults to root. Read examples carefully — placeholders aren't real values.

Challenge 3 — Cracking Passwords

Goal: A leaked /etc/shadow file was provided. Crack zardus's hash, su to zardus, run /challenge/run.

Background: /etc/shadow stores password hashes (e.g. $6$... = SHA-512 crypt). su hashes your input and compares. If a leak occurs (backups, misconfigured file servers), an attacker can crack hashes offline using tools like John the Ripper.

Get David Wairimu’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

My errors:

1. I ran john against a nonexistent file. I used the example filename from the tutorial:
2. text

• john ./my-leaked-shadow-file

1. Result: stat: ./my-leaked-shadow-file: No such file or directory. The actual leak was at /challenge/shadow-leak. I'd confused the tutorial's illustrative filename with the real path.
2. I pasted an entire previous terminal session back into the shell. I accidentally copied lines like hacker@users~cracking-passwords:~$ and Password: into the prompt, producing a wall of bash: ...: command not found errors. Harmless, but noisy. Lesson: only paste commands, not transcript output.
3. I retried su zardus repeatedly with wrong guesses before cracking the hash — wasted effort.

What worked:

text

john /challenge/shadow-leak

Output after ~10 seconds:

text

aardvark         (zardus)

Then:

text

su zardus
# Password: aardvark
/challenge/run

Flag: pwn.college{cFGkgelwDqLgJIjLbqJ6o4eAiq3.QX3UDN1wyN0czMzIzW}

Takeaway: This is a classic attack chain — leaked hash → offline cracking (no access to the target needed) → credential reuse → lateral movement. Offline cracking works because su merely hashes input and compares; the attacker can brute-force locally. Defensively: protect /etc/shadow (mode 0600 root:root), keep it out of backups, and don't reuse weak passwords. This is why the world moved to sudo.

Challenge 4 — Using sudo

Goal: Use sudo to read the flag.

My errors:

1. I treated /etc/sudoers as a command. I ran /etc/sudoers and then su /etc/sudoers. Both failed — it's a config file, not executable, and su takes a username, not a path. Permission denied on reading it is also expected for a normal user.
2. I invented a flag that doesn’t exist. I ran sudo -practice, which produced a giant usage dump. There's no -practice option — I'd misread the "Privileged Mode" note as a CLI flag. (Privileged Mode is a workspace toggle via the lock icon, not an argument.)

What worked:

text

sudo cat /flag

Flag: pwn.college{ATOTEqz1YiQrpK_SrmvudnjbDtN.QX4UDN1wyN0czMzIzW}

Takeaway: sudo elevates a single command, not your session — you don't need to become root. Useful variants: sudo -l (list permissions), sudo -i (interactive root shell), sudo -u <user> <cmd>.

Comparison: su vs sudo

susudoAuthTarget user's passwordPolicy in /etc/sudoersDefault actionShell as target (root)Run one command as rootModern usageLegacy; rarely used for rootStandard admin mechanismWhy obsoleteRequires maintaining a root password; hashes can leakPer-command, per-user, auditable, no shared password

Both binaries are SUID-root, which is how they gain the privilege to elevate in the first place.

Note on Privileged Mode (post-level-4)

After this level, pwn.college enables Privileged Mode: click the lock icon to restart the workspace with full sudo access. The hostname then ends in ~practice, and you get a placeholder flag that cannot be submitted. Use it for introspection/debugging, then switch back (open lock) to normal mode to solve the real challenge.

Summary of Mistakes (the honest list)

#MistakeFix1Passed password as su argumentType it at the interactive prompt2Didn't know password input is blindType and press Enter; nothing echoes3Ran placeholder su some-user literallyUse the real username (zardus)4Ran /challenge/run before switching userSwitch first, then run5Ran john on tutorial's example filenameUse the real path /challenge/shadow-leak6Pasted whole terminal transcript into shellPaste only commands7Tried /etc/sudoers as a commandIt's a file; use sudo cat to read8Invented sudo -practice flagPrivileged Mode is a UI toggle, not an option

Almost every failure came from one of three roots: copying examples literally instead of adapting them, not reading what the error message actually said, and misunderstanding the tool’s input model (argument vs. prompt, command vs. file). The technical concepts were simple; the friction was all in attention to detail.

Conclusion

The Untangling Users module builds a clean progression: su (password-based elevation) → su <user> (targeted switching) → hash cracking (why password auth leaks are dangerous) → sudo (policy-based, per-command elevation). The through-line is that privilege escalation mechanisms are only as strong as their authentication model — and the historical shift from shared root passwords to sudo policies reflects exactly the weaknesses demonstrated in challenge 3.

All flags reproduced above were legitimately obtained in the pwn.college Linux Luminarium training environment.