dont-you-love-banners picoCTF 2024 Solution

Description

1. Step 1

   Harvest the password

   Observation

   I noticed the challenge description explicitly called PORT1 a 'leak' endpoint, which suggested the server was voluntarily broadcasting a credential in its banner before any authentication handshake.

   The leak on port <PORT1_FROM_INSTANCE> prints its SSH banner, exposing the password (e.g., My_Passw@rd_@1234). Save it for the next step.

   bash

   nc tethys.picoctf.net <PORT1_FROM_INSTANCE>

   Copied!

   What didn't work first

   Tried: Running nmap -sV against PORT1 to grab the banner instead of plain netcat

   nmap -sV performs active probing and version negotiation that can suppress or truncate the raw banner text the server volunteers before any handshake. Plain netcat prints exactly what the server sends on connect, making the leaked password visible immediately without nmap's filtering layer.

   Tried: Using curl or a browser to connect to PORT1 expecting an HTTP response

   The leak port is a raw TCP service, not HTTP. curl will send an HTTP request and then wait for an HTTP response that never comes, timing out without printing the banner. Netcat makes a bare TCP connection and prints whatever the server sends, which is exactly the banner with the credential.

   Learn more

   A service banner is the initial text a server sends when a client connects - before any authentication occurs. SSH, FTP, SMTP, and many other protocols transmit banners that typically include the software name and version. This information helps clients negotiate compatible protocols, but it also helps attackers fingerprint services and identify exploitable versions.

   Banner grabbing is one of the first steps in network reconnaissance. Tools like netcat, nmap (with -sV), and Shodan collect banners to build a picture of exposed services. The key insight in this challenge is that someone configured the banner to include a credential - a serious misconfiguration that mirrors real-world cases where developers accidentally hardcode secrets in configuration files that end up in banners or error messages.

   In penetration testing, information leakage through banners is a common finding. Beyond passwords, banners can reveal internal hostnames, software versions with known CVEs, and even environment variables. Security hardening guides recommend minimizing banner verbosity - for example, configuring SSH to show only "SSH-2.0" rather than the full OpenSSH version string.

   The OWASP Top 10 lists Security Misconfiguration as a critical vulnerability class. Credentials in banners are an extreme but not unheard-of example - similar to finding database credentials in HTML comments, error messages that expose stack traces, or directory listings that reveal sensitive files.

2. Step 2

   Authenticate on the main service

   Observation

   I noticed the banner from PORT1 contained a plaintext password, and the challenge description pointed to a second port for 'the real service', which suggested using the harvested credential to log in there.

   Connect to <PORT2_FROM_INSTANCE>, enter the leaked password, and answer the security trivia (DEFCON / John Draper). You'll drop into /home/player with limited rights.

   bash

   nc tethys.picoctf.net <PORT2_FROM_INSTANCE>

   Copied!

   What didn't work first

   Tried: Trying to SSH into PORT2 with the leaked password instead of using netcat

   PORT2 is a custom netcat-based service that mimics a login prompt, not a real SSH daemon. Running ssh user@tethys.picoctf.net -p PORT2 will fail with a protocol mismatch error because the server is not speaking the SSH binary protocol. Netcat connects raw TCP and lets you type answers to the trivia prompts interactively.

   Tried: Reusing PORT1 to authenticate with the leaked password

   PORT1 is a read-only banner leak endpoint that does not accept credentials - it just prints its message and closes. The actual interactive login session lives on PORT2. Sending the password to PORT1 will produce no response or an immediate disconnect.

   Learn more

   Security trivia questions (like the DEFCON and John Draper questions here) are a challenge mechanic simulating knowledge-based authentication - a second factor beyond the password. In the real world, knowledge-based authentication (KBA) like "What was the name of your first pet?" is widely considered weak because answers can often be researched from public information.

   DEFCON is the world's largest underground hacking conference, held annually in Las Vegas. John Draper (a.k.a. Cap'n Crunch) is a legendary phone phreaker who discovered that a toy whistle from Cap'n Crunch cereal produced a 2600 Hz tone that could manipulate AT&T's phone network - a famous early example of exploiting unintended system behaviors. These trivia questions are nods to hacker culture and history.

   Once authenticated, landing in /home/player with limited rights demonstrates the principle of least privilege: even authenticated users should not have root access by default. The challenge requires a privilege escalation step to reach /root/flag.txt, reflecting real-world attack chains where an initial foothold must be leveraged for further access.

3. Step 3

   Abuse the banner reader

   Observation

   I noticed that /home/player/banner was a file in a user-writable directory that a root-owned script read on each login, which suggested replacing it with a symlink to /root/flag.txt so root's process would read the flag on our behalf.

   The root-owned script reads /home/player/banner. Replace it with a symlink to /root/flag.txt so the next login displays the flag as the banner.

   bash

   cd /home/player && rm banner && ln -s /root/flag.txt banner

   Copied!

   Reconnect to <PORT2_FROM_INSTANCE>; root prints the flag when it loads the banner.

   What didn't work first

   Tried: Overwriting the banner file with flag content using echo or cat instead of creating a symlink

   The player account cannot read /root/flag.txt directly, so there is no flag content to write into the banner file. The trick is that a symlink causes the root-owned script to follow the pointer and read /root/flag.txt on your behalf using root's privileges. Writing to the file yourself would require you to already know the flag.

   Tried: Creating the symlink as ln -s banner /root/flag.txt (arguments reversed) instead of ln -s /root/flag.txt banner

   Reversing the ln -s arguments creates a symlink at /root/flag.txt (if that path were even writable) pointing back to banner, which is the opposite of what is needed. The correct form is ln -s TARGET LINK_NAME, so ln -s /root/flag.txt banner makes a file called banner that points to /root/flag.txt. The reversed command will either fail with a permissions error on /root or create a dangling symlink in the wrong direction.

   Learn more

   A symbolic link (symlink) is a special file that acts as a pointer to another path. When any process reads the symlink, the OS transparently redirects the read to the target. Here, replacing the player-owned banner file with a symlink to /root/flag.txt causes the root-owned banner-reading script to unknowingly read and display the flag.

   This is a symlink attack - a classic privilege escalation technique. It works when: (1) a privileged process reads a file in a location writable by a lower-privileged user, and (2) the process follows symlinks without checking that the target is in a safe location.

   Two complementary mitigations:

   • O_NOFOLLOW on open() refuses to traverse a symlink and returns ELOOP. Cheap, kernel-level, but only blocks the final component.
   • realpath() canonicalizes the target path, expanding every symlink and ... The privileged script then checks the resolved path is inside an allowed prefix (e.g. /var/banners/) before reading. This catches symlinks anywhere in the path, not just the leaf.

   For more on Linux file primitives that bite in CTFs, see the Linux CLI for CTF guide.

   The broader vulnerability class is called TOCTOU (Time Of Check to Time Of Use): the script checks that the banner file exists (TOCT), then later reads it (TOU). Between these two events, an attacker can replace the file with a symlink. Even atomic operations can sometimes be exploited if the race window is large enough.

   Symlink attacks appear regularly in CVEs affecting Linux system services. Notable examples include vulnerabilities in sudo, systemd, and various package managers. The Linux security model has been extended with features like open_basedir and Seccomp-BPF to limit the damage such attacks can cause, but misconfigurations that allow them remain common.

Flag

When the root script renders your symlinked banner, it prints the flag exactly as shown.