in

How to Use WPScan to Find Security Vulnerabilities on WordPress Sites

default image

As a technology geek and data analyst, I am fascinated by the inner workings of complex systems like WordPress. With great power comes great responsibility, so securing our WordPress sites should be a top priority.

In this comprehensive 4000+ word guide, we’ll dig deep into how to effectively use WPScan to identify security flaws in your WordPress install before the bad guys can exploit them. I‘ll share my insights as an ethical hacking enthusiast to help fellow geeks lock down their sites.

Why WordPress Security Matters

With over 60% market share among CMS platforms, WordPress dominates the web landscape. This meteoric rise has also attracted cybercriminals seeking to infect vulnerable sites with malware for illegal botnets, cryptomining, and other nefarious purposes.

According to Sucuri, over 2 million legitimate WordPress sites get hacked every year. The ways hackers gain access include:

  • Exploiting vulnerable, outdated software like WordPress core, plugins and themes. This accounts for 63% of hacked sites!
  • Guessing or cracking weak admin passwords. 15% of breaches.
  • Uploading backdoored plugin and theme files. 11% of incidents.

WordPress security must clearly be taken seriously. Preventing your site from becoming part of a botnet or crypto mining operation starts with regularly scanning for and resolving any vulnerabilities.

This is exactly why WPScan exists! Next we‘ll dive into what this invaluable open source tool does.

What WPScan Does

WPScan automates auditing WordPress installs for known security flaws and misconfigurations. It was created by the respected white hat hacking team WPScan Team and continues to be maintained and improved.

Specifically, WPScan can:

  • Detect outdated, vulnerable WordPress core files
  • Check plugins and themes against vulnerability databases
  • Look for insecure settings and permissions
  • Find registered and default admin users
  • Brute force password guess admin accounts
  • Identify database exports, backups and sensitive files
  • And much more!

It uses both passive checks like header analysis and aggressive checks like brute forcing paths and folders. This balanced approach allows discovering issues without actively exploiting them.

The result is an at-a-glance security assessment highlighting areas needing improvement. Regularly running WPScan is a best practice to identify threats before hackers do!

Next let‘s get WPScan installed so we can start reaping the benefits.

Installing WPScan on Linux

Since WPScan is written in Ruby, we need a proper Ruby environment to run it. The recommended way is installing the WPScan gem which can then be invoked anywhere.

Here are the steps to get WPScan gem installed on Linux:

  1. Ensure Ruby is installed, otherwise install it:

     sudo apt install ruby-full
  2. Install some dependencies required for native extensions:

     sudo apt install build-essential libcurl4-openssl-dev libxml2 libxml2-dev libxslt1-dev libffi-dev 
  3. Install Bundler which helps manage Ruby gems:

     gem install bundler
  4. Use Bundler to grab WPScan and dependencies:

     bundle config set path ‘vendor/bundle‘
     bundle install
  5. Verify everything worked:

     wpscan --version

With those simple steps complete, we now have the wpscan command available to start assessing our sites!

The WPScan GitHub repository has details for getting it running on other operating systems like Windows and macOS. The general installation process is similar.

Now let‘s start putting WPScan to work!

Scanning a Site with WPScan

The basic command for scanning a WordPress site with WPScan is:

wpscan --url <target-url>

For example:

wpscan --url https://example.com

This performs a scan with the default options, including:

  • Mixed passive and aggressive checks
  • Lookup vulnerabilities in WPScan databases
  • Allow maximum 5 simultaneous connections
  • Follow redirects from homepage
  • Save found vulnerabilities in local cache

You can also provide multiple URLs separated by commas:

wpscan --url https://example.com,https://example2.com  

This will sequentially scan each URL provided.

Now that we have a simple scan up and running, let‘s look at customizing the scan behavior using some of the powerful available options.

WPScan Options

One of the great things about WPScan is its extensive set of options for controlling scan scope, selecting specific checks, performance tuning, output formats, and much more.

Here are some of the most useful options:

Scope and Target Options

  • –url – The WordPress URL to scan. Allows http:// and https://.
  • –force – Proceed with scanning even if the site doesn‘t look like WordPress.
  • –detection-mode – Set whether to use passive, aggressive or mixed checks.
  • –enumerate – Select specific enumeration checks like plugins, themes, timthumbs.
  • -e – Shorthand for enumerate.

Authentication and Access Options

  • –usernames – Specific username list for password brute forcing.
  • –passwords – Password list for brute forcing accounts.
  • –username – Single username for single password brute force attempt.
  • –password – Single password to check against provided usernames.
  • –http-auth – HTTP basic auth in format username:password.
  • –cookie – Specify cookie string to use in requests.
  • –random-user-agent – Use random user-agents. Helpful for evading detection.
  • –user-agent – Specify a custom user agent string.
  • –proxy – Use an HTTP or SOCKS proxy for scanning requests.

Optimization and Performance Options

  • -t – Number of simultaneous threads to use for faster scanning.
  • –throttle – Milliseconds of delay between requests. Helpful for reducing load.
  • –rate-limit – Maximum requests per minute to respect remote server limits.
  • –rua – Shorthand for random-user-agent.
  • –disable-tls-checks – Disables SSL/TLS certificate verification.
  • –request-timeout – Sets a timeout for HTTP requests in seconds.
  • –connect-timeout – Sets HTTP connection timeout in seconds.
  • –cache-ttl – Sets cache time to live in seconds, the duration vulnerabilities are locally cached.
  • –cache-dir – Customize the cache directory location.

Output Options

  • -o – Write output to a file.
  • -f – Specify output format like JSON, CLI, XML, etc.
  • –formatter – Alternative to -f for setting output format.
  • -v – Verbose output in the terminal.
  • –no-banner – Omit printing the WPScan banner.
  • –log – Log all requests to a file.
  • –no-color – Disable colored output.

There are additional advanced options including toggling detailed debug output, supplying custom wp-content paths, specifying urls to ping for vulnerabilities, and more.

Run wpscan -h to see the full options list. Tweaking these allows focusing on specific tests, avoiding detection, adjusting performance, and customizing output.

Now let‘s take a look at some example WPScan usage in action.

WPScan Usage Examples

Running WPScan with all defaults is great for a quick general scan. But the options available allow extensive customization for your specific needs and environment.

Here are some examples that demonstrate practical WPScan usage:

Example 1: Full Default Scan

This performs a full default scan using mixed passive and aggressive checks:

wpscan --url https://example.com 

Mixed mode is a good balance for most users, providing decent coverage without excessive noise.

Example 2: Passive Scan for Stealth

To fly under the radar and avoid detection, stick to passive checks only:

wpscan --url https://example.com --detection-mode passive

This is slower but ideal if actively checking paths and files could get flagged as an attack.

Example 3: Aggressive Deep Dive

Do an exhaustive scan leveraging aggressive techniques like file/folder brute forcing:

wpscan --url https://example.com --detection-mode aggressive 

The trade off is potentially tripping protective filters like Web Application Firewalls.

Example 4: Scan Specify Plugin

Target just a specific plugin you‘re concerned about:

wpscan --url https://example.com --enumerate p

Here we use p to enumerate only popular plugins.

Example 5: Full Enumeration

Perform all enumeration checks in mixed mode:

wpscan --url https://example.com --enumerate vp,vt,tt,cb,dbe,u,m

This tests everything: vulnerable plugins, themes, timthumbs, config backups, db exports, users, and media.

Example 6: Increase Speed

Boost the speed of large scans by increasing simultaneous threads:

wpscan --url https://example.com -t 10 

Here we set 10 threads. The higher the value, the faster the scan but greater the load on the target.

Example 7: Weekly Scheduled Scan

Run a weekly cron scan on Sunday at 1 AM and email results:

0 1 * * 0 wpscan --url https://example.com --email [email protected]

Scheduled scans are a best practice to apply WPScan continuously versus sporadically.

These examples demonstrate just a subset of the powerful options available for tailoring WPScan to your environment. Take time to review the full options list and tweak them to best suit your needs.

Next let‘s take a look at interpreting the scan results.

Understanding WPScan Output

A key skill is interpreting WPScan results to separate the actionable issues from the noise. The output produced provides extensive detail that can at first seem overwhelming.

Here is an example snippet:

[i] WordPress version 4.5.2 identified from advanced fingerprinting (Aggressive Detection)
 | Found By: Rss Generator (Passive Detection) 
 |  - https://example.com/feed/, <generator>https://wordpress.org/?v=4.5.2</generator>
 |  - https://example.com/comments/feed/, <generator>https://wordpress.org/?v=4.5.2</generator>
 |
 | [!] 4 vulnerabilities identified:
 |
 | [!] Title: WordPress 2.3-4.7.1 - Host Header Injection in Password Reset
 |     Fixed in: 4.7.2 
 |     References:     
 |      - https://wpvulndb.com/vulnerabilities/8807
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8295
 |  
 | [!] Title: WordPress 2.9.2-4.7.1 - Open Redirect
 |     Fixed in: 4.7.2
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/8806 
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8296
 |  
 | [!] Title: WordPress 3.7-4.7.1 - Path Disclosure in Customizer
 |     Fixed in: 4.7.2
 |     References:     
 |      - https://wpvulndb.com/vulnerabilities/8765
 |  
 | [!] Title: WordPress 4.4-4.7.1 - Authenticated Attachment Name Stored XSS 
 |     Fixed in: 4.7.2
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/8766
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9062 

This reveals:

  • The detected WordPress version – 4.5.2.
  • 4 specific vulnerabilities present in that version.
  • References and fixed versions provided.

The key things to look for are the vulnerability title, references, and fixed version. Make note of any issues that require you to upgrade WordPress, plugins or themes.

WPScan cross-references findings with the WPScan Vulnerability Database to pull in useful metadata like references. This helps you research and understand the issue.

Here is another example detecting outdated software:

[!] The version is out of date, the latest version is 1.3 
 | Location: https://example.com/wp-content/themes/twentysixteen/
 | Last Updated: 2016-06-02T00:00:00.000Z
 | Readme: https://example.com/wp-content/themes/twentysixteen/readme.txt
 | [!] Only available from wordpress.org 
 | Style URL: https://example.com/wp-content/themes/twentysixteen/style.css
 | Style Name: Twenty Sixteen 
 | Description: Twenty Sixteen is a modernized take on an ever-popular WordPress layout — ...
 | Author: the WordPress team
 | Author URI: https://wordpress.org/
 |
 | Found By: Known Locations (Aggressive Detection)

This shows the Twenty Sixteen theme is outdated and needs to be updated to the latest version.

In general, pay close attention to any warnings called out in red/yellow. Make note of the associated details so you can address the vulnerabilities.

Now let‘s look at how to fix the issues that WPScan identifies.

Remediating WPScan Vulnerabilities

Once a WPScan scan completes, you‘ll likely have a list of discovered vulnerabilities and misconfigurations to address. Here are some tips on remediating common problems:

  • WordPress Core – Always keep WordPress completely updated. If a vulnerable version is reported, upgrade as soon as possible. Enable auto-updates if available.

  • Plugins – Upgrade any outdated plugins. Remove inactive/unused plugins which bloat attack surface. Replace vulnerable plugins with alternatives.

  • Themes – Upgrade outdated themes. Use reputable themes from wordpress.org versus third-parties. Modify locally rather than using editor which can be risky.

  • Users – Change any weak admin passwords reported. Remove unused accounts. Limit admin users.

  • Config – Update permissions on sensitive files and folders identified. Disable XMLRPC if not needed. Enable SFTP if available.

  • Backups – Remove any backups or database exports found. Consider disabling XMLRPC. Implement backups for your site regularly in case you ever need to restore or recover from issues.

For specific vulnerabilities, review the provided references and links to understand how to patch. You may need to dig deeper or consult with your developer for remediation guidance.

For major complex vulnerabilities, it may be advisable to seek help from managed WordPress hosting providers or specialized security consultants.

The key is resolving discovered problems quickly to deny attackers an opportunity to exploit them. WPScan gives you the powerful data needed to start strengthening your site proactively.

Continuously Monitoring WordPress Security

WPScan provides an excellent foundation for auditing your WordPress site security. But running it periodically only gives you a snapshot versus an ongoing view.

That‘s why the best practice is to incorporate WPScan into a continuous scanning workflow. Here are two ways to achieve this:

Scheduled Cron Scans

Use cron jobs on Linux/Unix or scheduled tasks on Windows to automate running WPScan on a routine basis.

For example, scheduling it to scan daily or weekly means you don‘t have to remember to manually trigger it.

Here is a simple cron example to run a scan daily at 1 AM and email the results:

0 1 * * * wpscan --url https://example.com --email [email protected]

Frequent scheduled scans help detect issues emerging over time sooner.

Integrating with SIEMs

For large WordPress deployments, feed WPScan findings into a SIEM like Splunk or ELK Stack.

This allows establishing continuous monitoring with dashboards and alerts powered by the daily/hourly scans.

WPScan can output to JSON which simplifies ingestion. SIEM integration takes more work but is worth it for visibility across many sites.

Wrapping Up

I hope this guide has given you a comprehensive overview of WPScan‘s capabilities and how to utilize it for auditing WordPress installs. The key takeaways are:

  • Install WPScan via RubyGems for easy access system-wide.
  • Perform scans using wpscan --url <url> for basic assessments.
  • Customize behavior using options like --enumerate and --detection-mode.
  • Review findings and remediate any vulnerabilities or misconfigurations.
  • Schedule regular scans using cron for continuous monitoring.
  • For large deployments, feed findings into a central SIEM.

WPScan is a fantastic free tool for WordPress site owners, admins and developers seeking to audit their security posture.

By regularly scanning and resolving any problems found, you can gain ongoing confidence that your site is locked down tightly against the latest threats.

So try integrating WPScan into your WordPress security workflow today! I‘m happy to answer any other questions you may have about using WPScan effectively.

Written by