When it comes to security companies in general we don’t think to highly of them, while the company Wordfence isn’t an excerption. There are not as bad as, say, SiteLock, but we keep bumping in to bad stuff involving them. Like a month ago when we noticed them again falsely flagging plugins for suspected malware due to a quite bad false positive. The latest incident involves their security research, which now twice we have found putting websites at risks either seemingly because of the lack of expertise or from trying to profit off of exposing vulnerabilities.

Missed Vulnerabilities

This began about three weeks ago when they had released partial details of a fairly minor vulnerability in the plugin Yoast SEO. The vulnerability would allow Subscriber level and above users on a website to export the plugin’s settings and some other data. While reviewing this report to add the vulnerability to our data set we noticed several issues.

The first being that their security researcher was someone that we had found just two months before had released a false report of a vulnerability in a fairly popular plugin.

That makes the next problem even bigger, Wordfence did not released a proof of concept to test out the vulnerability. Having that is important for us to double check that the vulnerability has actually been fixed, which is something that we seem to be the only ones doing and if we don’t then many vulnerabilities remain in plugins (which obviously is a bad thing). Making our job harder puts lots of websites at risk, but it also make it harder to double check if the vulnerability actually exists or if Wordfence is continuing with their security researcher’s past of putting out a false report. The reason for not providing this seems to be try to get you buy their service, based on the disclosure procedure the included with the post:

Wordfence Standard Disclosure Procedure

At Wordfence the security of our customers and the greater WordPress community is of paramount importance to us. With this in mind we have developed standard disclosure procedures when we discover a vulnerability that are as follows:

1. One of our research team discovers a vulnerability and shares it with the rest of the team who verifies the vulnerability.

2. We develop a Firewall rule to protect our customers. This rule is obfuscated to prevent reverse engineering.

3. We notify the vendor and simultaneously release a firewall rule to protect our premium customers via the Threat Defense Feed. Customer sites are updated immediately with the rule and no customer action is required.

4. Vendor releases a fix, usually after several days and we announce the existence of the vulnerability at the same time to encourage the community to upgrade.

5. Wordfence community (free) customers receive the firewall rule 30 days after the initial release to Premium customers.

6. At a future date we may release a PoC so that other firewall providers can create rules to protect their customers too.

The claim that the “security of … the greater WordPress community is of paramount importance to us” doesn’t match up with their actions mentioned throughout this post. Also, if they want to use vulnerabilities to try sell their service that’s their choice, but the way they are doing isn’t compatible with the security of the greater WordPress community. By comparison when we discover a vulnerability in a plugin we publicly release the details of the vulnerability to the public at the same time as our customers start getting notified.

Since we didn’t have a proof of concept to work with to check on this vulnerability we needed to come up with one on our own. When we started working on that we discovered that the Wordfence people had missed part of the vulnerability, the vulnerability could also be exploited through cross-site request forgery (CSRF). If we could spot that then you can be sure others could and if this were a more serious vulnerability it would be much more likely to be exploited after Wordfence’s disclosure of the related vulnerability. By providing full details it would be much easier someone without malicious intent to spot such a situation and make sure it gets fixed quickly.

It turned out that wasn’t the only issue. The setting’s export file generated by Yoast SEO is stored in an easily guessable location. If it was generated this month it is stored at:

/wp-content/uploads/2016/05/settings.zip

Last month it was saved at:

/wp-content/uploads/2016/04/settings.zip

It is hard to understand how the Wordfence people missed that, but by disclosing the other issue, others are likely to notice that as well.

Right after we noticed those issues we reported them to the Yoast SEO developers, unfortunately nearly three weeks after we notified them of the issues they have still not fixed them.

At least with all of that you can blame ignorance, but yesterday they knowingly released partial information on a vulnerability that gave user of the plugin a false sense of security.

Wordfence Telling People They Are Secure When They Are Not

Yesterday Wordfence released information on vulnerabilities in two plugins, one of them being WP Fastest Cache. Looking over that there is lot of information missing, a big one being the important caveats that make these vulnerabilities a lot less concerning than Wordfence makes them sound (we are pretty sure the lack of caveats is intentional considering Wordfence’s track record around that type of thing).

Another important item missing was any information on what versions are vulnerable, which would have been important since it turns out that the then current version was vulnerable. You wouldn’t actually know that from reading their post’s “What to do” section:

What to do

If you are running the Premium version of Wordfence and have the firewall enabled you are already protected because we added protection for both vulnerabilities yesterday.

Free Wordfence users running this plugin should update the vulnerable plugin immediately. Paid Wordfence users who have the firewall disabled should also update the vulnerable plugin immediately. The author released a fix within an hour of our notifying him of this vulnerability.

Once you get past the promotion for their service they say that you should update the plugin, which won’t do anything for you if you are good about doing manual updates or if you use something like our Automatic Plugin Updates plugin to have them done automatically since you would already have been running the latest version of the plugin, 0.8.5.7. This fact would be pretty obvious if they had provided full details because the vulnerabilities existed in version 0.8.5.7, which was the current version of the plugin at the time. The developer did fix them, but didn’t bump the version number, so updating won’t do any good unless you are still running an older version of the plugin. Providing all of the details would have made that obvious and easy for someone to double check.

It was only after others contacted the developer with questions about this that a new version was released.

Our Attempt To Mitigate Some of The Damage They Could Cause

To help protect against more issues like this we are going to start releasing the details of the vulnerabilities that Wordfence are partially disclosing so that others have a chance to properly reviewed them (since Wordfence can’t be bothered to do that). That way we can also expose their attempts to embellish the threat of this vulnerabilities, which is also harmful to properly addressing the real security issues surrounding WordPress plugins and working to improve the situation.