At the end of last month we wrote a post about our finding that despite Wordfence’s unqualified claim that their plugin’s firewall protects against stored XSS (or what we refer to as persistent cross-site scripting (XSS)) that it did not protect against a real world vulnerability. After we posted that we though that maybe the vulnerability we used for the test wasn’t totally fair, since it required the exploiter to be logged in (or authenticated) to WordPress. Wordfence doesn’t seem to think that matters much, seeing as how the have frequently left out the detail that a vulnerability is only exploitable when logged in when disclosing them. But seeing as it severely limits the amount of website that are impacted (since many don’t allow people that are not trusted to have account), we wanted to run another test on a vulnerability that didn’t have that limitation.
The same day we put up that post, we notified the developer the security plugin Total Security that we had found a persistent cross-site scripting (XSS) vulnerability in their plugin. In the case of this vulnerability you do not need to be logged in to exploit the vulnerability, the only limitation is that the 404 Log feature needs to be enabled. Due to another security vulnerability in that plugin, anyone can change the plugin’s settings, so they could enable that feature themselves and then exploit the other vulnerability.
After notifying the developer of the vulnerabilities we tested it out the persistent XSS vulnerability against Wordfence. We wanted to release the results of that test after the vulnerability had been fixed, but the developer of the plugin doesn’t seem to be real interested in fixing them, seeing as a new version of it was released yesterday, without any attempt to fix the issues included. At that point we decided to disclose the vulnerabilities and notified the Plugin Directory of them, which usually leads to a vulnerability being pulled from the Plugin Directory pending a fix. Unfortunately that often times is the only thing that gets vulnerabilities fixed.
For this test, we set up a new WordPress installation, installed the Wordfence and Total Security plugins, enabled the firewall (with the Enabled and Protecting status), and then tried to exploit the vulnerability based on the proof of concept included in our report on the vulnerability.
When making the exploit attempt we got the normal 404 page back:
So once again Wordfence didn’t actual prevent a real world persistent XSS vulnerability from being exploited.