On multiple occasions the team behind the Wordfence Security plugin have failed to credit us when discussing vulnerabilities we discovered. We are not alone in that it turns out and unfortunately journalists will cover them and not give any credit to other security companies that are actually doing the work to keep ahead hackers (which is how Wordfence falsely markets their Wordfence Premium service of doing).
Among the oddities of the security industry is that so often people seem to be skeptical of the wrong things, as they are more likely to believe that security companies are lying about things where there isn’t a logical reason to do that, while being overly trusting about extraordinary claims being made about security products and services, which often turn out to be false. Last week we touched on the kind of claim that should elicit suspicion, that being that unqualified claim that the Wordfence Security plugin “stops you from getting hacked”. As we found when dealing with a website hacked due to a widely exploited vulnerability it didn’t protect the website (that is far from the first time we have seen it fail to stop a hack).
Making such a claim and not actually accomplishing that looks worse when you go to their homepage and see the first thing shown is an advertisement for them doing hack cleanups: [Read more]
The company behind the Wordfence Security plugin is not by any means an honest company from what we have seen from over the years, so it wasn’t surprising for us torun across them advertising their payed service in a dishonest way. Yesterday we had noted that they appear to have left the public in the dark about an unfixed vulnerability in a WordPress plugin that was being exploited. After viewing Wordfence’s website while looking over that post we started getting re-targeted ads for their Wordfence Premium service and a lot of them.
By a lot, on just one page in one instance we served up five unique ads (plus multiple copies of the unique ads). What seems clearly to be key selling point is something that the security industry frequently uses to mislead people, which is promoting services as being “real-time”: [Read more]
We often find that the information provided about vulnerabilities in WordPress plugins presented by security companies and developers of the plugins is not telling the full story. Take a vulnerability that Wordfence disclosed yesterday. They don’t provide any explanation of how they came across it:
On Friday May 24th, our Threat Intelligence team identified a vulnerability present in Convert Plus, a commercial WordPress plugin with an estimated 100,000 active installs. [Read more]
The people behind the Wordfence Security plugin do some strange stuff. For example, in a recent post they again referred to us as an “unnamed security researcher”:
The file upload vulnerability was initially made public in a report by an unnamed security researcher, which was irresponsibly published on April 23rd without privately notifying the plugin’s author. [Read more]
In our previous post we mentioned how Wordfence was lying about us related to a vulnerability in the plugin Related Posts (Yuzo Related Posts), but they also got something else wrong that is worth noting. One section of their post titled “is_admin() Strikes Again”. In that they write this:
Developers often mistakenly use is_admin() to check if a piece of code that requires administrative privileges should be run, but as the WordPress documentation points out, that isn’t how the function should be used. In this scenario self::_ini_() is called on any request to an administrative interface page, including /wp-admin/options-general.php and /wp-admin/admin-post.php, which allows a POST request to those pages to be processed by self::save_options(); later in the code. [Read more]
Here’s a timeline of the recent situation with the WordPress plugin Related Posts (Yuzo Related Posts):
- March 30 – The plugin was closed on the WordPress Plugin Directory.
- March 30 – We notice the closure and find that the plugin contains an exploitable vulnerability.
- March 30 – We put out post warning about that vulnerability and pointed out the problem with closing plugins with undisclosed vulnerabilities.
- March 30 – We notify the developer of the plugin about the vulnerability through the WordPress Support Forum.
- April 2 – Developer submits new version of plugin that appears to be intended to fix a different vulnerability and seemingly unintentionally fixes another one.
- Approximately April 9 or 10 – Vulnerability we warned about is widely exploited.
When we announced a protest of the continued inappropriate behavior of the WordPress Support Forum moderators, one of the changes we suggested to resolve that was:
Don’t post on things they don’t understand. This really ties into the last item since you often have moderators providing people incorrect information and then they appear to not be able to handle that someone provides information that disputes that, leading to accurate information being deleted. [Read more]
When it comes to trying to improve security surrounding WordPress two of the big problems are inaccurate information being spread by security companies and journalists, and often they are combined. As an example of that, an article popped up the other day for the Google News alert we have set to keep track of coverage of plugin vulnerabilities (which we previously mentioned in the context of another inaccurate claim, that 90 percent of websites hacked last year were running WordPress). Part of that article, which quotes someone from the company behind the most popular WordPress security plugin, Wordfence Security is as follows:
All new plugins are checked by WordPress before being added to the public repository, but the same doesn’t apply to updates. [Read more]
Over at our main business we have a steady stream of people contacting us to ask if we offer a service that will stop their websites from being hacked, a not insignificant number of them mention that they are currently using a service that claimed to do that and there website got hacked anyway. That second item obviously tells you that these service don’t necessarily work, but what seems more relevant to the poor state of security is that even when one of these doesn’t work these people are often sure that they can and do work, just the one they used didn’t. That probably goes a long way to explaining why the complete lack of evidence that these services are effective at all hasn’t been an impediment to people using them. The problem with that is not only do they end up not working well or at all, but the money spent on them could have been spent on services that actually improve security of these websites (and everyone else’s website if there services is anything like ours), but are not sold on false promises.
Seeing as there are lots of people that still haven’t gotten the message about these services should be avoided if there isn’t evidence that shows effectiveness, we thought it would be worth emphasizing and expanding on something we mentioned in a post yesterday where websites could have been protected by doing one of the basics of security, keeping WordPress plugins up to date, while a security service failed to protect them while being promoted as being able to do that. [Read more]