Permissions picoCTF 2023 Solution

Description

1. Step 1Discover the sudo entry for vi

   Observation

   The challenge is named permissions and drops you into SSH as a non-root user. That points at a misconfigured permission entry rather than a binary exploit, so sudo -l is the first thing to run.

   Run sudo -l after logging in. The output shows that picoplayer may run /usr/bin/vi as root without a password (NOPASSWD). Text editors like vi can execute arbitrary shell commands from within the editor, which is exactly what makes this a privilege escalation path rather than a simple file-read challenge.

   bash

   sudo -l

   Copied!

   Expected output

   User picoplayer may run the following commands on permissions:
       (ALL) NOPASSWD: /usr/bin/vi

   What didn't work first

   Tried: Check for SUID binaries with find / -perm -4000 instead of running sudo -l

   Searching for SUID binaries covers a different escalation class, and this box has none worth finding. The intended path is the sudo rule, so skipping sudo -l means never seeing the passwordless entry and hunting an exploit that does not exist.

   Tried: Run sudo su or sudo bash directly to get a root shell

   sudo su and sudo bash work only when your user may run those binaries as root. The rule here grants vi and nothing else, so both are refused outright. Use the specific binary sudo -l named.

   Learn more

   sudo -l (list) is always the first command to run when enumerating privilege escalation paths on a Linux box. It prints every command your current user is allowed to run via sudo, along with whether a password is required. A NOPASSWD entry means you can run that command as root with no additional authentication.

   The challenge name permissions is a hint at sudo permissions, not just filesystem permissions. Many CTF beginners assume privilege escalation requires a kernel exploit or a SUID binary; in reality, a single misconfigured sudo rule is often all you need.

2. Step 2Escape vi to a root shell via GTFOBins

   Observation

   sudo -l grants passwordless access to vi specifically, which GTFOBins lists for good reason: its -c flag runs arbitrary Ex commands at startup. Passing a shell escape there drops a root shell without touching the editor interface.

   Use the NOPASSWD vi entry to open vi as root, then immediately execute a shell command from within vi using its -c flag. The command sudo /usr/bin/vi -c ':!/bin/bash' /dev/null launches vi, runs :!/bin/bash in command mode before you ever see the editor, and drops you into an interactive bash shell running as root.

   bash

   sudo /usr/bin/vi -c ':!/bin/bash' /dev/null

   Copied!

   bash

   whoami

   Copied!

   bash

   cat /root/.flag.txt

   Copied!

   Expected output

   root
   picoCTF{uS1ng_v1m_3dit0r_...}

   After running the command, bash spawns as root. Confirm with whoami (should print root), then read the flag with cat /root/.flag.txt.

   What didn't work first

   Tried: Open vi normally with 'sudo vi /dev/null' and then type ':shell' or ':!bash' interactively inside the editor

   This works eventually, though the -c flag is cleaner and skips the editor interface entirely. And forget the leading colon, typing only the exclamation form, and you stay in normal mode and get a not-an-editor-command error, because vi needs that colon to enter Ex mode first.

   Tried: Try 'sudo vi -c ':!/bin/sh'' instead of ':!/bin/bash'

   sh works and gives a root shell, with a different-looking prompt and limited tab completion that can read as a failed escalation. bash gives a recognizable interactive prompt instead. Either reads the flag; the difference is cosmetic.

   Learn more

   GTFOBins (gtfobins.github.io) is a curated list of Unix binaries that can be abused for privilege escalation, file reads, reverse shells, and more when they are granted elevated permissions. Many standard tools such as vi, less, find, awk, and python appear on the list because they have built-in mechanisms to execute arbitrary commands.

   For vi/vim, the -c flag runs an Ex command immediately on startup. The Ex command :!/bin/bash shells out to bash. Because the entire process is running under sudo, the resulting bash session has root privileges. Using /dev/null as the file argument is a common trick to avoid needing a real file to open; vi simply has nothing to display before the shell command runs.

   This is why granting sudo access to text editors is dangerous: even if the intent is only to let a user edit a specific config file, the editor can always be used to break out into a full shell. The safe alternative is to use a more restrictive mechanism, such as sudoedit, which does not allow shell escapes.

Flag

The flag lives in /root/.flag.txt and is only readable after escalating to root via the misconfigured sudo vi entry.