Sometimes the hardest part of a CTF isn’t the exploit itself, but just getting the target to talk to you. After solving the initial connectivity puzzle, I faced a WordPress instance that seemed secure—until I looked at its plugins.
But in this write-up, I won’t stop at the user flag. I’ll show you how a simple file read vulnerability allowed me to pivot from the web server to a full compromise of the database.
Phase 1: The „Ghost” Website (Recon & DNS)
The initial Nmap scan revealed a web server running on a non-standard port: 8088, and—crucially for later—a MySQL database exposed on port 3306.
However, trying to access the IP directly resulted in connection errors. The server was redirecting requests to megablog.cbr. Since this domain doesn’t exist in the public DNS (it’s an intranet site), my browser had no idea where to go.
The fix was simple: I added the mapping to my /etc/hosts file.
10.87.160.175 megablog.cbr
With the „plumbing” fixed, the site finally loaded. It was a WordPress blog for a medical intranet, confirming the „Intranet” hypothesis.
Phase 2: Digging Deeper with WPScan
Knowing it was WordPress (version 6.7.1, released Nov 2024), I fired up wpscan. This tool is essential for enumerating users, themes, and plugins.
wpscan --url http://megablog.cbr:8088/ --enumerate u,ap
The scan returned two critical pieces of information:
- User Enumeration: It found a valid user named michal.
- Plugin Enumeration: It identified the simple-backup plugin. It flagged version 2.7.10 (detected range 2.7.9-2.7.11) as outdated.
Phase 3: The Exploit (Path Traversal)
I checked searchsploit for this specific plugin.
searchsploit simple backup
The result was promising: „File Read / Path Traversal”. This vulnerability allows an attacker to trick the web server into displaying files from the local file system by manipulating the file path.
I downloaded the exploit script (51937.py). First, I verified it by reading /etc/passwd.
https://www.exploit-db.com/exploits/51937
It worked. I could see the system users. Now, for the main objective: the flag in Michal’s home directory.
python3 51937.py http://megablog.cbr:8088 /home/michal/flag.txt 5
Flag:
CBR{W0RDPR355_S14Y3R}
Phase 4: The Extra Mile (Database Takeover) 🚀
Getting the flag is nice, but in a real engagement, we want persistence or data. Since I had Arbitrary File Read, I decided to target the most important file in any WordPress installation: wp-config.php.
This file sits in the root directory and contains the database credentials in plain text.
python3 51937.py http://megablog.cbr:8088 wp-config.php 1
The script successfully downloaded the config file. Inside, I found the keys to the kingdom:
- DB_USER:
wordpress - DB_PASSWORD:
wordpress_password
Connecting to the Database
Since Nmap showed port 3306 (MySQL) was open to the outside world, I tried to connect using these credentials.
However, I hit a wall: ERROR 2026 (HY000): TLS/SSL error: self-signed certificate...
The server was enforcing SSL, but my client rejected the server’s self-signed certificate. To bypass this, I explicitly disabled certificate verification:
mysql -u wordpress -h megablog.cbr -p --ssl-verify-server-cert=FALSE
I was in! I had full read access to the database.
I switched to the wordpress database and dumped the wp_users table to get the administrator’s hash.
Now I have the password hash ($P$B...) for the admin user michal. Even though WordPress salts its hashes (making them slow to crack), having this hash allows for offline cracking attempts or Pass-the-Hash attacks in some scenarios.
Summary & Mitigation 🛡️
This box demonstrates a critical chain of failure:
- Outdated Plugin: The
simple-backupplugin acted as an open door to the filesystem. - Exposed Database: While the web server was on port 8088, the database port 3306 was exposed to the network. It should have been bound to
localhost(127.0.0.1) or firewalled. - Hardcoded Credentials: The
wp-config.phpfile is a goldmine. In high-security environments, credentials should be loaded from environment variables.
Lesson: A single file-read vulnerability can lead to a total data breach if the database is also exposed.
Thanks for reading! Stay tuned for the next challenge. 💀