As a company that cares about security (something that clearly can’t be said for most security companies) we continually look at how the actions we take impact security. One area that we continue to look at is the disclosure of WordPress plugin vulnerabilities we have found. When we do that currently we include the details of the vulnerability as well a proof of concept on how to exploit the vulnerability when disclosing them.
The obvious concern with that is that it makes it easy for others to exploit the vulnerability, which we will come back to in a moment. But there are upsides to including those details as well. We have often found that plugin vulnerabilities have not actually been fixed at the time they disclosed, despite the report on the vulnerability stating that it has. If a proof of concept available it makes it really easy to double check that it has been fixed and we have often found that once we notice the vulnerability hasn’t been fixed, that we can take actions that get it fixed fairly quickly. We also often found that people reviewing one vulnerability report will often find other vulnerabilities in the same plugin. From our experience having been the ones finding the additional vulnerabilities, having the details makes finding those much easier.
Also lowering the negative impact of providing the details of vulnerabilities is that we have found it to be easy to determine the details of the vulnerability with very little information. We often find vulnerabilities that hackers would exploit in plugins with just the knowledge that hackers are interested in the plugin. And in other cases with just a basic description of the vulnerability and a review of the changes made in the version that fixed the vulnerability we have quickly worked back to how it would be exploited (which we need to know to confirm that vulnerability exists and determine what versions are vulnerable when adding it to our data set). So limiting what information is provided will not in most cases have much impact on someone else being able to discover how to exploit the vulnerability.
Another element that we see is that many of the people trying to hack websites don’t really seem to know much about what they are trying to doing. If you were looking to exploit vulnerabilities in WordPress plugin effectively one thing you would want to do is target vulnerabilities in plugins that are more widely used. The number of active installations is listed on the page for the plugin in the Plugin Directory and if a plugin has been removed old data on that can be found by looking at a cached copy of the page. Based on what we see it doesn’t look like many of the people trying to hack websites through WordPress plugins are doing that, which is a good thing as it leads to less websites being hacked. As example of that, we recently came across a tool described as “WordPress Vertical SlideShow Mass Exploiter”, which try to exploit a vulnerability we disclosed in the Vertical SlideShow plugin (we are not linking to the exploiter as the website it is on is redirecting to fake anti-virus scareware). The plugin being targeted has been removed from the Plugin Directory, so we can’t see how many active installs it has now, but as of a year ago it only had 200+. Considering it hadn’t been updated since January of 2013 it is unlikely to have gained many more since then. So exploiting it on a mass scale would impact at most a few hundred websites.