The WPScan tool is “black box WordPress Security Scanner written in Ruby which attempts to find known security weaknesses within WordPress installations”, which is described as being intended “for security professionals or WordPress administrators to asses the security posture of their WordPress installations.” We find that claim somewhat odd since it scans a WordPress website from the outside of the website, which not only isn’t necessary if you have admin access to the website (which anyone involved with the security of website should have), but is also an inefficient way of doing a security scan when you have that access. While doing some research for another post we identified another problem that makes the tool bad for use by a security professional: their data indicates that plugin vulnerabilities have been fixed as of versions of the plugin that still in fact contain the vulnerabilities. Since this gets to a larger problem we have been seeing, we though it would make sense to take a look at this.
In WPScan’s vulnerability data for a a vulnerability in a plugin named Ajax Search Lite it says that the vulnerability impacted versions at or below 3.1 and that the vulnerability was “fixed in version 3.11″. The first claim is wrong and the second claim was wrong as of the date their data was last updated, March 21. We know this because we help to get the plugin fixed after that.
As part of the process of adding WordPress plugin vulnerabilities to our Plugin Vulnerabilities plugin, we check to make sure the claimed vulnerabilities actually exist (which they sometimes don’t) and we try to determine all of the version that are vulnerable. Knowing what versions are vulnerable is important when trying to determine how a WordPress website was hacked (as we do when cleaning up Hacked WordPress websites), as you can rule out a plugin’s vulnerability if the installed versions is not vulnerable. In adding data for over 225 vulnerabilities to our plugin so far, we have found that while some vulnerabilities have existed in every version of a plugin, many impact less versions, in some cases only one version has been impacted. What has been more surprising in working on the plugin is how often we find that even though a vulnerability has been listed as fixed, it hasn’t been. That was the case with Ajax Search Lite.
When we starting looking into the security advisory for Ajax Search Lite we figured that the vulnerability had probably been fixed in version 3.11 of the plugin based on the changelog entry for that version, “A possible security issue fix”, and the release date. After confirming that vulnerability existed in the prior version, 3.1, we checked to make sure it was fixed in 3.11, but it wasn’t. Looking at the changes between 3.1 and 3.11 we didn’t see anything that looked like the security fix. We then took a look at another plugin from the same developer Related Posts Lite that was reported to have the same issue. In that case the vulnerability had been fixed, so it looked to as if the developer simply forgot to include the fix in Ajax Search Lite. We notified the developer on March 26 of the issue; they then promptly responded and fixed the vulnerability. They still haven’t increased the version number so that anyone who got version 3.11 before that happened is still vulnerable. Because WPScan doesn’t do what we do, with their tool you wouldn’t know that you could still be running an insecure version.
What has made the issue of unfixed vulnerabilities even more surprising to us is that organizations that would think would be careful about this sort of thing, haven’t been. Take for instance another vulnerability we looked at recently. High-Tech Bridge, a security services provider, put out a security advisory for a vulnerability in the Easing Slider plugin. In it they stated that the vulnerability was “Fixed by Vendor” and indicated that the fix occurred in version 2.2.0.7. When we went to check on the vulnerability we found that it still existed in that version. In the changelog for that version it was listed that “Fixed some $_GET input validation security issues.”, which would appear to relate to the security issue identified, but they had not in fact done that to inputs that were the root of this vulnerability. It appears that High Tech Bridge didn’t actually test out their sample exploit in the new version, since it was obvious that it wasn’t fixed if you did that. We alerted the developer to the issue and the locations of the vulnerable code, which lead to the vulnerability actually being fixed in version 2.2.1. Once again if you are relying on WPScan you would be in trouble since they indicate the vulnerability impacted versions at or below 2.2.0.6 and that the vulnerability was “fixed in version 2.2.0.7″.
While this highlights the problem of relying on WPScan for security purposes, it also points to any area where the security of WordPress plugin could be improved. If WordPress provided a process where a plugin is reviewed after a security vulnerability is supposed to have been fixed then these types of issues could be quickly caught and fixed. As to who would provide the funding for this, we already have a good idea.