WordPress is one of the most well known and most used pieces of web technology on earth. It also happens to be a bit of a mess from a security perspective, as it relates to the plugin ecosystem specifically. The core application also has had many vulnerabilities over the year, so even it has not escaped unscathed.
In the security world, WordPress is seen largely as a joke from a security perspective. As a result, it falls in a weird middle ground between what web application security DAST scanners focus on, and what network scanning technologies focus on. DAST scanners do not find value in going after WordPress because it is not a custom application, and therefore it is difficult to show the real value of a DAST scan. Meanwhile, network scanners look at it as a web application and tend to ignore it for the most part. Yet, as mentioned, it is almost a joke in the security community due to how bad it has been historically. So, why aren’t we focused on it more?
When analyzing the ecosystem of vulnerable CMSs, the first thing that should be done is to simply dump out the version numbers of the various CMSs and sort them. It may sound simple, but this is an incredibly useful way to analyze which applications are running and the version numbers without spending a ton of time and energy to understand what that means.
Without doing any meaningful amount of work and just by glancing at the version numbers, you can easily tell that the three assets above belonging to a single domain are not running the same versions. At the time of this writing, the current version of WordPress was 5.6, so we know exactly one of them is currently maintained and patched, whereas the other two are languishing on older versions. From this we know two things:
- In the example above, we can tell that the company in question does not centrally manage their WordPress installs, otherwise they would all be on the same version. It may be an older version that they standardize on, but it should all be the same version if it were managed by a central team. In fact, it is probable that the company either does not manage the three versions using the same people or those people have long ago stopped maintaining the older blogs entirely.
- We know that the company is likely uncompliant with any policy that would mandate being up to date with all software – especially Internet-facing software.
With a little more information, it is easy to know how these applications came to be. The first site’s subdomain is “test” and the second is named after an employee and therefore also likely a test site. Two test sites that were little known and probably long ago forgotten.
Once you add an additional layer of information, including WPScan information, you can now see which vulnerabilities exist in either the core application or the plugins. WPScan is a lightweight scanner that allows companies to know what CMS vulnerabilities they have in WordPress and is perfectly suited to this type of analysis, because it gives the company detailed vulnerability information without being intrusive.
This obviously can be used for both red and blue teams. This makes the red teamer’s job a breeze because they no longer must download and run scanners on their own;, they can simply take advantage of the existing information that bubbles to the surface naturally. In the case of blue teamers, it also makes it much easier to identify the sites that are problematic and get someone working on the dangerously out-of-date and insecure applications in order.
