Word Alert

When software becomes uber-popular, attackers spend much more time trying to find security holes. WordPress [1], an extremely popular content management system (CMS), is built on the PHP [2] language. WordPress also hooks into a relatively small database back end, such as MariaDB. I always advise very large commercial organizations to avoid using WordPress due to the constant battle of patching and checking for security issues, even when using some of the excellent automation which is now provided. Smaller businesses might be tempted to use WordPress because of its simplicity, but they need to be vigilant about staying up to date.

In a previous article [3], I introduced WPScan [4] and described how an attacker can use the powerful service to look for vulnerabilities in a WordPress website. The good news is that WordPress webmasters can also use WPScan to close any gaps before an intruder finds them.

Start at the Beginning

Security professionals have spent a long time trying to make life easier for those running WordPress sites. WPScan, in particular, has excelled and created a genuinely invaluable tool to check your site's security. WPScan helps users find every possible (currently) known issue present on a WordPress site in a fully automated fashion.

The open source WPScan has an impressive arsenal and boasts an ever-growing database that contains an eye-watering number of vulnerabilities to reference. Its own website states: "The WPScan CLI tool is a free, for non-commercial use, black box WordPress security scanner written for security professionals and blog maintainers to test the security of their sites. The WPScan CLI tool uses our database of 38,997 WordPress vulnerabilities" [4].

If you want to use the tool for commercial sites, there's a link that takes you to a WordPress plugin called Jetpack Protect [5], which WPscan works in partnership with. The premise is that your administrator's WordPress dashboard will light up like a Christmas tree if Jetpack Protect finds malware or security threats within your WordPress plugins, themes, or WordPress core system files. There's a pricing page [6] with packages that seem very reasonably priced, considering the potential loss of revenue and damage to a business's reputation.

Without further ado, I will show you what the venerable WPScan finds on the latest version of WordPress, which I have running on an AWS instance for testing. If you have never installed WordPress, the Ubuntu Linux site [7] provides useful configuration and installation instructions. Because my AWS instance is running Debian Linux 11 ("bullseye"), I'll use that guide [8]. The installation process essentially involves installing the Apache web server, the PHP language, and then the MariaDB database server. Finally, before some configuration, the last task is downloading WordPress [9].

Contain Your Stuff

I'll use the Docker container route to get WPScan up and running. (Make sure that you have permission to scan the sites where you are running WPScan. It is extremely thorough and other users and admins may notice the scans.) There's also a simple Ruby gem installation route [10].

To get the WordPress scanner running as a container, you need to use the following Docker Engine command:

$ docker run -it --rm wpscanteam/wpscan--url http://XXX.XXX.XXX.XXX/--enumerate ap,at,cb

(If your Ubuntu Linux or other Debian Linux derivative doesn't have Docker Engine installed, you need to use the apt install docker.io command.)

The XXXs in the example are the AWS instance's IP address. Later on, having used Let's Encrypt [11] to generate a TLS certificate, the eagle-eyed among you will notice that I replace the IP address and http with https://hostname.tld. (If you want to do this, the instructions are in the WordPress on Debian installation instructions [8]).

Hopefully, the rest of the Docker Engine command is self-explanatory. However, note the importance of the enumerate flag (abbreviated to -e if you like). Table 1 shows the enumerate options.

If you want to save the scan output, then you need to create a volume for the container (called a bind mount); otherwise, the output file gets written inside the scanner container, which then gets destroyed after running the scan. I start with creating a local filesystem directory (on my laptop in this case), followed by a long and somewhat unwieldy Docker Engine command shown in Listing 1 (admittedly I haven't tested this, so refer to the docs if you need help):

$ mkdir ~/docker-bind
$ docker run --rm --mount type=bind,source=$HOME/docker-bind,target=/output wpscanteam/wpscan:latest -o /output/wpscan-output.txt --url 'http://XXX.XXX.XXX.XXX'

One final switch to mention: If you're faced with Web Application Firewalls (WAFs) that do clever, sophisticated sifting of incoming traffic, you need to address this before putting WPScan to work. To help mitigate WAF responses, you can add this option:

--random-user-agent

which alters how the scans are perceived from a WAF's point of view.

Where's It Gone?

It's not uncommon to struggle a little to find where WordPress is hiding on a web server, even though it's dynamically generating website content. In other words, if an admin has done the right thing by obfuscating the location of the admin dashboard login page, you may need to add options like --wp-content-dir or --wp-plugins-dir to point WPScan in the right direction.

To get WPScan working on steroids (to get full-fat information about discovered vulnerabilities in the output), the WPScan team asks you to create an API token. You can do this without logging in, by selecting For developers | API details. At the bottom of the page [13], under For Developers, you click on a link to register as a user, which asks for your name, email, a password, and optional billing information.

On this page, you'll also find vulnerability statistics. For instance, in the first half of October 2023, a staggering 117 new WordPress vulnerabilities were discovered (Figure 1) and presumably then added directly to the WPScan database. If you run a WordPress website and you don't think you need to worry about your site's security, Figure 1 may change your mind.

Figure 1: In October 2023, 117 new WordPress security issues were identified (Source: https://wpscan.com/api).

The API details page also provides an insightful yearly graph of WordPress security threats. A whopping 1,974 issues were discovered in 2022 alone. More worryingly, the year-on-year increases are steady with the last two years showing the largest yearly rises.

In order to gauge the quality and professionalism of the WPScan service, I would highly recommend reading the API details page [13], as well as the rest of WPScan website. The site explains that WPScan is a CVE Numbering Authority [14], which permits WPScan to directly register discovered Common Vulnerabilities and Exposures (CVEs), and this results in a security expert manually updating WPScan's vulnerabilities database (to ensure its integrity). (Each vulnerability considered to be of consequence is allocated a unique CVE number.)

There are also important API terms to abide by – such as only having one API token per organization and the prohibition against permanent storage of vulnerability data, among a number of other criteria – before using the API token. For WPScan's API reference, see the official Swagger page [15]. Once you register and log in, you will be able to regenerate your API token (or just make a copy of it initially). You will also be informed of the 75-per-day API call limit with the free subscription.