🚀 TL;DR

Box: Plum (Linux)

Vulnerability: PluXml 5.8.7 Authenticated RCE (CVE-2022–25018).

Entry: Weak Credentials.

Privilege Escalation: Cleartext password stored in /var/mail/www-data.

Key Learning: Always check /var/mail. It's the "Post-it note with a password" of the Linux world.

🔍 Phase 1: Recon & The "Easy Win"

I started with the standard Nmap scan to map the attack surface.

Command:

nmap -sV -sC -O -T4 -n -Pn 192.168.64.28

The scan showed Port 80 open. Browsing the site, I found a blog running PluXml.

None
Initial Nmap scan results showing Port 80

I scrolled to the footer and saw the Administration link.

None
Identifying the CMS version Administration link in the site footer

The Login: I located the admin panel at /core/admin/. Before firing up Hydra, I tried the "Script Kiddie Special": User: admin, Pass: admin.

None
Success! Default credentials 'admin:admin' grant access to the dashboard

Result: It worked. I was in the dashboard as an administrator.

🔓 Phase 2: The Foothold (Editing Static Pages)

With admin access, I looked for a way to execute code. A quick search for "PluXml 5.8.7 exploit" led me to CVE-2022–25018. The vulnerability is simple: The CMS allows admins to edit "Static Pages" and does not sanitise PHP code.

The Exploit:

  1. I navigated to Static Pages.
  2. I selected an existing page (or created a new one).
  3. I replaced the content with a PentestMonkey PHP Reverse Shell (configured to my IP and Port 4119).
None
Injecting the PHP reverse shell code into the Static Page editor

Triggering the Shell: I started my listener (nc -lvnp 4119) and browsed to the page URL to trigger the code.

The Catch: The connection was established immediately. I was www-data.

None
Foothold obtained: Catching the reverse shell as www-data

Stabilization: I upgraded the shell to a proper interactive TTY using Python:

python3 -c 'import pty; pty.spawn("/bin/bash")'
export TERM=xterm
^Z
stty raw -echo && fg

I browsed to /var/www/ and grabbed the first trophy, local.txt.

None
Capturing the user flag (local.txt)

👑 Phase 3: Privilege Escalation (You've Got Mail)

I started my standard enumeration. I uploaded LinPEAS, and under Mails section, I find some interesting directories:

None
LinPEAS output checking for Mails (standard enum)

I checked the mail directory for the www-data user.

None
Reading /var/mail/www-data reveals a root password

Command:

cat /var/mail/www-data

The Discovery: Inside the mailbox was an email stating, "Patrick is having trouble with his password," followed by the password explicitly written out: my_secret_pass!

The Root: I didn't need a kernel exploit. I simply switched users to root using the password found in the email.

su - root
Password: my_secret_pass

Access Granted. I verified my ID and captured the flag.

None
Victory: Capturing proof.txt

🛡️ The Fix

  1. Change Default Credentials: admin:admin should never exist on a production server.
  2. Disable PHP Execution: Configure the web server (Nginx/Apache) to disable PHP execution in the /data/ or /static/ directories where CMS content is stored.
  3. Clear Mail Spools: Verify that sensitive information (like passwords) is not stored in local mail spools (/var/mail).

🧠 Lessons Learned

  • The "Script Kiddie" Checks Work: Always try admin:admin, root:root, or guest:guest before over-complicating the attack.
  • Read the Mail: /var/mail and /var/spool/mail are often overlooked. On older systems or CTF boxes, they are a goldmine for internal chatter and credentials.