19 May 2016

WordPress Plugin Directory Not Responding in Timely Fashion to Exploitation of Vulnerable Plugins

When it comes to getting security vulnerabilities in WordPress plugins fixed far to often it takes having the plugin removed from the Plugin Directory for that to happen. That removal will only happen if the Plugin Directory is made aware of the security vulnerability. From being the ones that have reported many of those vulnerabilities to them, due to our discovery of plenty of vulnerabilities and our monitoring of publicly disclosed vulnerabilities, we have seen that response times are not good. Often it takes them days to process the requests and that means additional days until the problem gets resolved.

For most of those vulnerabilities the chances of them being exploited are pretty small, so the delay in getting them resolved is not a major concern. But what about when a plugin is being actively exploited and there are serious security vulnerabilities in the latest version of the plugin? The response time isn’t better.

In March of last year we found that a vulnerability had returned in a plugin (not a great sign in itself for the security of WordPress plugins). We notified the developer of the plugin about the issue and then several day later we had attempt on our website to exploit it. At that point we notified the Plugin Directory of the issue. That was on Thursday and as of the next Monday the plugin has not been updated or pulled from the plugin directory. At the time the plugin only had 2,000+ active installs, so the amount of vulnerable websites was somewhat limited.

Last week though we ran across a similar issue with a plugin that had 100,000+ active installs. In that case we started seeing requests for a JavaScript file in the plugin on one of our websites, which didn’t use the plugin. That request would seem to be from someone looking for use of the plugin and that would most likely be to attempt to exploit something in it. In the case of the first request for the file a JavaScript file for another plugin that had recently had a publicly disclosed vulnerability was also requested, making it seem more likely that the request was hacking related.

Since we didn’t use the plugin there was no hacking attempt on the website, so we had no way of knowing what they might be trying to exploit in the plugin. We didn’t have any vulnerabilities for this plugin already in our data set, we couldn’t find any public reports of vulnerabilities in it, and the plugin hadn’t been updated in 8 months (which made it unlikely that a hacker was trying to exploit a vulnerability that was recently fixed in the plugin) so that lead us to believe to that the current version must have some vulnerability that a hacker is attempting to exploit.

After reviewing the plugin for a few minutes we identified that the any logged in user (even at the Subscriber level) would be able upload to arbitrary files to or edit existing files on the website if the plugin was installed. So any website that has open user registration and used the plugin would be incredible exposed to being hacked. At that point we contacted the Plugin Directory about the situation, explaining that evidence of hacking attempts and the vulnerabilities present. We hoped there would be a quick response.

Our email to them had been sent at approximately 5PM MDT. By the next morning since there had been no response and the plugin was still in the directory we disclosed the vulnerabilities and added them to the data set of this service as well as adding it to the data to included to the companion Plugin Vulnerabilities plugin, so that even those not using our service would start getting notified if they were vulnerable. At that point we thought it would be a good idea to try to notify the developer, even though the plugin hadn’t been 8 months. They quickly responded and fixes for the vulnerabilities were released in the early hours of the next day. So the Plugin Directory left plugin that looks to be actively exploited and was to known to contain exploitable vulnerabilities was still available for around 30 hours. If the developer wasn’t still around who knows how much longer it would have taken for something to be done about this.

Leave a Reply

Your email address will not be published.