WordPress Security Plugins Provide Little to No Protection Against Recently Discovered Persistent XSS Vulnerability

In the past few months we have done several one off tests of WordPress security plugins to see if they could prevent exploitation of a vulnerability in a plugin. We tested an extraordinary claim by Wordfence that their plugin could prevent persistent cross-site scripting (XSS) and found that it failed both with a vulnerability that required authentication and one that didn’t. We also tested the iThemes Security security plugin against an arbitrary file upload vulnerability that we have found was being exploited in another plugin by one that plugin’s developers and it also failed to prevent exploitation.

That these plugins failed to prevent these vulnerabilities from being exploited wasn’t all that surprising considering the poor state of the security community overall and in particular the one surrounding WordPress. Whether it is security companies making up threats, not understanding the difference between vulnerabilities, or spreading false information about WordPress installations being vulnerable due to not understanding how WordPress handles security updates, it is clear that there isn’t a good understanding of security by the people and companies in the security community.

To get a better understanding of how security plugins impact the threat of plugin vulnerabilities we thought it would be useful to start testing a wider set of them against real world vulnerabilities to see how much protection they provide.

For the inaugural edition, we tested out a persistent cross-site scripting (XSS) vulnerability that existed in the plugin WP-Piwik prior to 1.0.11. The vulnerability highlights a number of the problems we see surrounding vulnerabilities in WordPress plugins these days. In reviewing one of the outside data sources we use to help detect vulnerabilities being targeted by hackers we found an indication that there was hacker interest in the plugin back in January. In looking over the plugin we found that anyone could change the plugin’s settings (you didn’t need to be logged in to do that) and that could be exploited to run malicious JavaScript code on to the frontend pages of the website. A similar vulnerability in another plugin was exploited on a large scale to serve malware on websites in February of last year, so unlike a lot of vulnerabilities that are not of much concern, this one was.

Once we had found the vulnerability we quickly notified the developer of the details of the issue, suggested they may want to request to have the plugin automatically updated after being fixed, and let them know that if they needed any help in dealing with it, to get back to us. Two weeks went by without any response or the vulnerability being fixed. At that point we disclosed the vulnerability, added it to the data that comes with our service’s companion plugin (so that even those that don’t use the service would get alerted), and notified the Plugin Directory of the issue.

A short time later the plugin was removed from the Plugin Directory, which protected those not already using the plugin from being exposed to the issue. Those already using the plugin were left in the dark since WordPress continues to refuse to alert them in such a situation.

Two days later the plugin returned the Plugin Directory with a new version, 1.0.10, that was supposed to fixed the vulnerability, but didn’t. Plugins returning to the Plugin Directory without actually being fixed is continuing problem. After noticing that we contacted the developer again to notify the vulnerability still existed and to provide suggestions on properly fixing the vulnerability. We got a response from them a short time later. Two days later the vulnerability was fixed with version 1.0.11.

Seeing as the vulnerability could have been being exploited for months before it was fixed a security plugin that protected against it before them would have provided some real value.

Testing Procedure

For each of the tested plugin we set up a fresh install of WordPress 4.6.1, installed the last vulnerable version of WP-Piwik, and installed the latest version of the security plugin. We tried to enable any feature of the plugin that could possibly have an impact on stopping exploitation of the vulnerability.

We used the proof of concept included in our previous post on the vulnerability with one change. To simulate what a hacker might do, we set it so that the a JavaScript file from another website would be loaded on the website’s page. In a real exploitation that would then server up malicious code. We did it with this format:

We used a real domain that we control instead of example.com for the testing.

The 11 plugins we tested include the security plugins listed in the Popular plugins section of the Plugin Directory and some others that look to intended to prevent this type of situation. If you would like to see an additional plugin included in future testing please leave a comment on the post or contact us.

Results

Only two of the plugins tested, NinjaFirewall (WP Edition) and Wordfence, prevented the vulnerability from being exploited with the original code. But we were able to easily bypass the protection in those two without even looking the at the underlying source code of how their protection works (that source code would be available to anyone looking to exploit them).

For NinjaFirewall (WP Edition) we bypassed the protection first by removing the “</script>” tag from the malicious code, that didn’t impact the malicious code running due to a closing “</script>” existing after the location it is placed when using the WordPress template.

For Wordfence simply changing the beginning of it from “<script” to “<\script” allowed the protection to be bypassed. That had no impacted on the code ultimately served up to users unlike the bypass for NinjaFirewall (WP Edition). After noticing that we realized the same type of bypass could be used on NinjaFirewall (WP Edition), by replacing “</script>” with “</\script”>.

It is interesting to note that one of the two plugin that provide any protection is also tied for the least popular of the plugins tested, with only 10,000+ active installs. That is a good reminder that the popularity of security plugins has little bearing on the protection they provide, instead what matters is what security features are included, in this case a firewall.