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.

The persistent XSS vulnerability is caused by the fact that when a 404 request, a request for a page that doesn’t exist, the referer sent with the request for the page, which indicates the page the user is coming from, is logged without being sanitized and the output on an admin page without being escaped. So malicious JavaScript code can be included in the referer of a request and then it it will executed on plugin’s 404 Log page in the admin area.

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:

Checking in the admin area of the plugin after that we could see that the attack was successful, as you can see from a screenshot of that page below, as an alert box showing the content’s of the cookies for the website was shown due to the JavaScript code submitted in the referer:

So once again Wordfence didn’t actual prevent a real world persistent XSS vulnerability from being exploited.