Beating the Bad Guys

I am running WordPress v6.2 on my AWS instance (the latest version at the time of writing). I can see the administrator dashboard login on the following URL (which I'm confident WPScan will find immediately, so I don't need to add any other options):

https://hostname.tld/wp-login.php

I use the Docker Engine command in Listing 2 to launch a scan. Note that I'm not using the API token in Listing 2.

$ docker run -it --rm wpscanteam/wpscan --url https://hostname.tld --enumerate ap,at,cb
Unable to find image 'wpscanteam/wpscan:latest' locally
latest: Pulling from wpscanteam/wpscan
97518928ae5f: Pull complete
d879f3f43643: Pull complete
[...snip?]

Figure 2 shows the beginning of the resulting lengthy output. The well-formatted information shown here helps point you to the salient security threat findings.

Figure 2: And so it begins. The initial output from the start of a scan.

For the enumerate option, I've included all plugins, all themes, and configuration backups. If you find the output from the scan is too verbose, I recommend reducing output to just vp for vulnerable plugins to get the most valuable information and then follow up with another vt scan for vulnerable themes.

The, frankly, unbelievable levels of detail that the WPScan tool produces is far too plentiful to show here (and I don't want to breach any of their terms by showing vulnerability data). I can however walk through some of the findings in even the most basic scan. By basic, I mean that I purposely have not enabled any plugins (and only enabled one theme) on my WordPress installation. I also haven't added the API token option to the scan to give detailed vulnerability information.

The scan queried a number of useful external WordPress settings (that attackers would be able to see without any credentials). Firstly, the results reported that XML-RPC appeared to be enabled. According to a blog post on the topic [16], XML-RPC can be vulnerable to brute-force login attempts. It should go without saying that the findings may not actually indicate a security issue, but the findings should certainly be investigated by a human to ensure the WordPress build isn't vulnerable. WPScan offers confidence levels (XML-RPC hit 100 percent), as well as multiple URL references accompanying the findings, which is helpful.

Another finding showed that the WordPress upload directory had directory listing enabled. If you are penetration testing or attacking a site, then enumerating useful assets on a web server is your first port of call (e.g., probably the best case for an attacker would be finding a password list). As a result, having the directory listing option enabled can be dangerous if lots of users are uploading documents and other data to a website.

WPScan promptly identified the version of WordPress correctly. It also mentioned that WP-Cron was enabled, which may be prone to Denial-of-Service (DoS) attacks. This seems a little contentious (having read the reference URLs), but it's certainly educational to learn more about potential threats like this.

The scan also correctly revealed I had activated the Twenty Twenty-Two WordPress theme, and it appeared to be using Cascading Style Sheets (CSS) content and other publicly available information to find additional issues with varying degrees of confidence.

Needless to say, even the very latest version of WordPress (with no active plugins) offered some food for thought that would be useful if I were attacking the web server.

Full Fat

Now I'll run the scan with the API token included (redacted because my API token should only be used by me). This time, I will enable two plugins within WordPress to offer a greater attack surface for WPScan to enumerate.

I've added the Duplicate Page plugin (chosen arbitrarily because it was updated three months prior and not as recently as others). This plugin lets you easily duplicate posts, pages, and custom posts with a single click.

I also enabled the WordPress gallery plugin, NextGEN Gallery (again because it hadn't been updated for three months). NextGEN Gallery claims to be the most popular gallery plugin with over 31 million downloads. That's a lot of downloads!

Two plugins, Akismet Anti-Spam (a blogging spam blocker) and Hello Dolly (which amusingly lets admins see random lyrics from Louis Armstrong's "Hello, Dolly" displayed in the upper right corner of the admin screen) were preloaded but not activated in the WordPress installation, so I activated them. While I did click activate, I didn't configure the plugins, which may skew the scans a little. For example, the Akismet plugin needed me to register with a spam service for it to fully work. Figure 3 shows the enabled plugins, four in total.

Figure 3: I added two plugins to WordPress, as well as activating two that were already there.

I'll use the same Docker Engine options as before for WPScan but add --api-token XXXXXXXX as an option (where the Xs are my API key from the WPScan website; note the actual token is much longer than the redacted version).

Having run the scan, the good news is that the scan didn't find anything relating to CVEs or flagged threats in these plugins.

Without betraying the confidences of WPScan's findings, a Proof of Concept (PoC) exploit was identified, and WPScan lit up with alarming red text for that section. It seems there isn't a vendor fix available for the issue yet, but from the levels of detail written about it expertly online, this seems like a threat that shouldn't be dismissed easily. Possibly, it can be mitigated.

When enumerating the themes, WPScan really went to town and spent over 12 minutes enumerating all plugins (using passive and aggressive scanning methods). It crawled the WordPress URLs for tens of thousands of locations to look for known themes (which are ostensibly obfuscated but still publicly reachable when installed, even though they are deactivated).

As a result of this scan, I would recommend registering for an API token to get the most out of WPScan.

Getting Wordy

If you install WPScan from the Ruby gem, then your command lines will look like Listing 3 (a little simpler, without the Docker Engine commands prepended). During Capture The Flag (CTF) exercises in the past, I've used WPScan to attempt to brute-force logins in WordPress.

$ wpscan --url https://hostname.tld/wp-login.php --enumerate u -U names.txt --passwords /directory-name/wordlists/1000-common-passwds.txt

Looking at Listing 3, I'll briefly dissect the new information. The -U option showing names.txt is for a text file that contains usernames that I discovered during the enumeration of various assets on a WordPress site. It may only contain a handful of usernames (possibly partly discovered from users who submitted posts on the blog sites) plus obvious users like admin, wp-admin, and wpadmin.

The --enumerate u option only looks for users (not plugins, etc.), so the scan is very focused.

The --passwords option is pointing at a downloaded file, which is one of a number of word lists that you can find online. As the name suggests, this list is only a thousand entries long, so it will iterate relatively quickly to see if any of the usernames match the passwords supplied. Brute-forcing WordPress like this can be done relatively quickly if there's no rate-limiting on the WordPress web server, if there are no hardware constraints (e.g., a busy website already consuming a portion of the server's resources), and the connectivity is adequate. The vast majority of cloud servers complete a scan within a few minutes for a handful of usernames checked against a thousand passwords.