When it comes the security industry around WordPress unfortunately there are many people that either don’t know what they are talking about or are intentionally peddling bad information to push products and services that provide little to no protection, while making things harder for companies that are actually doing the hard work to actually improve security.
We often run into examples of this even when we aren’t looking for them. We ran into another example just the other day when we went to look around for some information while working on a post about running into a problem with contact form due to WordPress’ REST API being disabled. That lead us to an example of someone at best not knowing what they are talking about when it comes to the basics of WordPress security while being the developer a security plugin, Cerber Security, Antispam & Malware Scan, that currently has 90,000+ active installs according to WordPress.org.
A big tell that developer doesn’t have a basic clue as to security surrounding WordPress is that a main feature of their plugin is blocking brute force attacks despite the fact that those are not happening. They also make this brute force related claim in the marketing materials for plugin:
By default, WordPress allows unlimited login attempts through the login form, XML-RPC or by sending special cookies. This allows passwords to be cracked with relative ease via brute force attack.
Saying that brute force attacks could crack a password relative ease is belied by the number of login attempts needed to actually test out all of the password combinations. Here is what we wrote about that previously:
To understand how you can tell that these brute force attacks are not happening, it helps to start by looking at what a brute force attack involves. A brute force attack does not refer to just any malicious login attempt, it involves trying to login by trying all possible passwords until the correct one is found, hence the “brute force” portion of the name. To give you an idea how many login attempts that would take, let’s use the example of a password made up of numbers and letters (upper case and lower case), but no special characters. Below are the number of possible passwords with passwords of various lengths:
- 6 characters long: Over 56 billion possible combinations (or exactly 56,800,235,584)
- 8 characters long: Over 218 trillion possible combinations (218,340,105,584,896)
- 10 characters long: Over 839 quadrillion possible combinations (839,299,365,868,340,224)
- 12 characters long: Over 3 sextillion possible combinations (3,226,266,762,397,899,821,056)
The post that we had run across was “Why it’s important to restrict access to the WP REST API”. The post is riddled with errors, for example citing someone as having discovered a vulnerability they didn’t.
The general problem was that they were suggesting disabling the REST API, which not at all coincidentally they touted their plugin did, because there could be security issues with it since it is new. But that is true of anything. In reality the vulnerability they discussed in the post actually showed how WordPress does a good job in handling security in one important way, since the auto update mechanism that has been in WordPress 3.7 allows the vast majority of WordPress website to be updated to a new security release in a very short time. Normally WordPress checks for updates every 12 hours and that can be shortened when a security update is being released, so most of the websites would likely have been updated in around 12 hours. With this vulnerability there was no evidence of it being exploited until after it was disclosed that it had been fixed a week after the version that fixed it was released (while the information on this vulnerability was held back for a week, other security updates were mentioned when it was released).
The developer though put forward a very different impression:
Unfortunately, the REST API bug had not yet been fixed. That leaves unprotected millions of websites around the world. It’s hard to believe but updating WordPress on shared hostings may take up to several weeks. How many websites have been hacked and infected?
That it may take several weeks to for WordPress on shared hosting to update is actually hard to believe, since it doesn’t appear to be true and no evidence was presented to back up a claim even they claim is counter-intuitive. The developer provides no evidence that any websites were hacked before the vulnerability was disclosed as having been fixed a week before, which as far as we are aware they couldn’t have since it doesn’t appear any were. That all probably shouldn’t be surprising since the developer apparently had never checked to see if brute force attacks were actually happening before building a plugin to protect against that.
For website where the auto update mechanism was disabled or didn’t work they did get mildy hacked due to this vulnerability, but that is the only vulnerability in more than a decade that we are aware of where there was any sizable number of websites hacked (in that time outdated WordPress installation have been frequently falsely blamed for the hacking of websites by security companies that either didn’t know what they were talking about or intentionally lying to get themselves press coverage). So disabling the REST API subsequent to this vulnerability being fixed has not actually improve the security of websites in any meaningful way.
There also was the issue of the developer conflating bugs and security vulnerabilities, which is important since having a lot of bugs fixed in something doesn’t mean that there was security risk.
The downside of disabling the REST API can be seen in that, like with the other plugin we mentioned in the post from earlier this week, this plugin can cause Contact Form 7 based forms to stop functioning. This exactly the kind of downside that often isn’t considered when people indiscriminately use WordPress security plugins and services without finding out first if there is any evidence that they provide effective protection. In this case what makes this stand out more to us is that our Plugin Vulnerabilities plugin, which is designed to help protect against a real issue, is much less popular than this plugin. It could be worse though, as another security plugin just designed to protect against brute force attacks has 2+ million active installs according to wordpress.org and it not only doesn’t protect against a real threat, but contains a security vulnerability of its own.