Wessel Swanepoel
Road to Root: WordPress and WAVE XXE

In this installment of Road to Root we demonstrate -again!- why, you should never host your WordPress applications on the same environments as other mission critical systems.
Administrators try their best to restrict and lock-down these installs, but maintaining WordPress often feels like sharing a bed with 9 rabid wolverines. WordPress themes and its many plugins are notorious for breaking after updates are applied to either WordPress itself or to the host's PHP runtime, and in the end many admins throw in the towel and exclude these applications from regular update runs due to the costs involved in repairing them over and over again.

To date the WPScan vulnerability database contains over 21,755 vulnerabilities, and in many cases they can lead to remote access of the machine as I will demonstrate in this blog post.
WordPress login bypass
Our target in this engagement was typical for WordPress installs, a simple webserver to serve the site, FTP for remote deployments and SSH for administration.

The website's primary function was to enable users to make bookings of hosted events:

Looking at the html source code, the booking module of the site seemed to be powered by a WordPress plugin called "Booking Press v1.0.10".

BookingPress is actually a fairly well-established developer of plugins for WordPress related to appointments and scheduling.

The particular version of the plugin running on our target was still vulnerable to a SQL injection attack documented under CVE-2022-0739:
The plugin fails to properly sanitize user supplied POST data before it is used in a dynamically constructed SQL query via the bookingpress_front_get_category_services AJAX action (available to unauthenticated users), leading to an unauthenticated SQL Injection
BookingPress < 1.0.11 - Unauthenticated SQL Injection WordPress Security Vulnerability (wpscan.com)
Armed with the CVE information I was able to craft a few strategic requests in Burp Suite and pull some hashed WordPress credentials:

With the username and hash in hand, I pulled out the ol' dictionary and got crackin':




Bam, just like that we were logged into the WordPress admin panel!
WordPress WAVE XXE
The first thing I then tried to do with my new WordPress admin powers was to upload backdoors in the form of .php, .js, .json scripts- but it quickly became apparent that my access rights had been limited to upload only media files.

After a bit of research, I found an interesting vulnerability discovered in WordPress back in 2021 documented under CVE-2021-29447
WordPress XXE Vulnerability in Media Library - CVE-2021-29447 - WPSec
A user with the ability to upload files (like an Author) can exploit an XML parsing issue in the Media Library leading to XXE attacks. WordPress used an audio parsing library called ID3 that was affected by an XML External Entity (XXE) vulnerability affecting PHP versions 8 and above. This particular vulnerability could be triggered when parsing WAVE audio files.

With this knowledge in hand, I set out to build a script that would automate the execution of the vulnerability. A script is particularly useful in this case as there's quite a few steps involved, and we'll be poking around blindly on the server hoping to discover something useful.
Here is what I came up with:
The code above can be summarized diagrammatically in the following data flow diagram:

After poking around for a few minutes, I found some interesting information from the following files:
/etc/passwd

../wp-config.php

Interesting...
FTP Exploration
Using the credentials I found, I pivoted to the FTP server and started rummaging through each and every file on it looking for more goodies.

Not too long into my search, I came across the mailer's source-code that had the SMTP server's credentials hardcoded to the same user we found earlier in the /etc/passwd

Lucky for me, these credentials were reused for the SSH Service.

Privilege Escalation
Now that I finally had some useful access to the machine, I started exploring the environment and quickly found some interesting folders:

Passpie is an open-source command-line password manager freely available on github, which seemed like it had the ssh credentials for both our current user and root stored in it.

Unfortunately, I needed the passphrase to extract any credentials.

So close!
I spent some time exploring Passpie's code and noticed it uses GnuPG under the hood, an extremely robust, mature and secure set of tools for encryption and signing tasks.

PGP like any encryption, is not impenetrable and is only as strong as the passphrase used. To crack it I had to:
1. Download the private key to my local machine

2. Extract the passphrase hash

3. Crack the passphrase

4. Profit!


We got Root!
Thanks for taking the time to read my blog - if you have any advice on how I could have improved my workflow, please feel free to comment below.