Recently we have been doing tests of WordPress security plugins and the results haven’t been good for those that believe that these plugins actually provide much protection. In one of the tests most of the plugins provided no protection and the protection the others provided was easily bypassed. In another the plugins provide no protection what so ever. In only one test did a single plugin provided protection that wasn’t easily bypassed and that came with the tradeoff that protection as limits file uploading to Administrator level users.

One of the causes of this type of result is that people behind security products and services have little understanding of what hackers are actually doing and therefore what would actually provide protection against that. We often see that when we are hired to re-clean hacked websites after another company cleaned them and then they go re-hacked. The first thing we always ask in that situation is if the previous company determined how the website was hacked, since if the issue isn’t fixed then that could allow it to be hacked again. The answer is almost always that determining how the website was hacked didn’t even come up. That doesn’t just seem to be recollection issue as we have seen a number of major web security companies discussing their clean up process and they make no mention of doing that. Making that more confounding is that these same companies claim that services they offer will protect websites from being hacked, despite them not actually knowing what is leading to websites being hacked in the first place.

That brings us to report on a persistent cross-site vulnerability discovered in the security plugin iThemes Security (which has failed to provide protecting in any of our tests of security plugins) by the developer of another security plugin. After going through the details of the vulnerability the finish the post with a paragraph full of inaccurate and unhelpful advice. It starts this way:

In situations like this one, most probably this attack vector already is added on the automated systems that lure from the anonymous network sources.

The opposite is actually true. We haven’t seen any evidence of hackers targeting a persistent cross-site scripting (XSS) vulnerabilites that would allow for placing malicious code on an admin page in WordPress. That is based on monitoring hacking attempts of websites as well as dealing with numerous hacked WordPress websites. It appears the claim is simply there to set up promoting their plugin.

Next up the say:

This means that you must to update your iThemes Security plugin to the latest version.

We really can’t emphasize enough how bad this type of advice is (and we see it a lot), as you need to keep all of your plugins up to date all of the time. Trying to rely on security company’s blog posts or changelogs is going to leave you vulnerable. A week ago we discussed an arbitrary file upload vulnerability, which is probably the most exploited type of vulnerability, that existed in older versions of a plugin. We came across the vulnerability because it looks like a hacker had been trying to exploit it. The changelog for the version it was fixed in only included one entry, “Bugfix: .zip file created on some Windows systems did not extract correctly”, which relates to something else that was fixed in that version. We also couldn’t find any prior disclosure of a security fix in the release (and it occurred almost 8 months ago). So if you were relying on those things to alert you that you need to update you would have been unaware and possibly still vulnerable to something that hackers are actually targeting.

Finally the paragraph end with this:

Also more than good measure to prevent 0 days like this one, is having https://wordpress.org/plugins/pike-firewall/, will filter/block most requests from anonymous sources and there is possibility to make distinction between human and bot traffic.

We haven’t tested the plugin to check their claims, so we can’t comment on that. There is one thing we can comment on, which is that there is no evidence that this was a zero-day vulnerability. A zero-day vulnerability refers to a vulnerability that is being exploited before the developer has become aware of it. That obviously is serious situation, unfortunately we have found that security companies and the press are often using the term to refer to less serious vulnerabilities. In this case, the post provides no evidence of the vulnerability being exploited by hackers, much less it occurring before the developer was made aware of the issue.